2012-11-20 10:16 PM - edited 2015-12-18 02:58 AM
I have a situation where we have a FAS3240 configured as an OSSV secondary to 20 or so remote Windows file servers running OSSV. Everything is generally running well, with the exception that the existing secondary/destination paths are both obscurely named and limited to around 1TB of data. I presume this is a historical thing, based on previous OnTAP limits. For example, I have:
SERVERA:E:/ -> FAS3240:/vol/vol1/SERVERA_E__
SERVERB:E:/ -> FAS3240:/vol/vol1/SERVERB_E__
SERVERC:E:/ -> FAS3240:/vol/vol2/SERVERC_E__
SERVERD:E:/ -> FAS3240:/vol/vol2/SERVERD_E__
The desire is to both get some better naming involved (overall across all vol/qtree/shares) and co-locate everything into a single Volume allowing for better DeDupe/Compression at the destination.
So something like:
SERVERA:E:/ -> FAS3240:/vol/VOL_OSSV/SERVERA_E__
SERVERB:E:/ -> FAS3240:/vol/VOL_OSSV/SERVERB_E__
SERVERC:E:/ -> FAS3240:/vol/VOL_OSSV/SERVERC_E__
SERVERD:E:/ -> FAS3240:/vol/VOL_OSSV/SERVERD_E__
How can I do this without either re-baselining (600GB across 10mbit WAN is not great), or resorting to LREP. Also, the replication is being handled by DFM 18.104.22.16850 (4.0.1D5), if that matters at all.
NetApp support has pointed me here: https://kb.netapp.com/support/index?page=content&id=1010804 but this seems very much related to a Primary/Secondary SV vs a Windows/Secondary OSSV relationship. I've been trying the steps in simulators and on a lab unit, and am not having much luck.
2012-11-21 12:35 AM
The KB is OK. But there is also a detailed description in the OSSV Manual.
I've done this for OSSV a couple of times and it works, without rebaselining the relationship.
Where did your sim test exactly fail?
2012-11-21 06:11 AM
Thanks for the reply, it at least lets me know I'll find a way. I have to be honest, I'm new to NetApp in the last 6 months, and I've done a little button mashing to get to where I have gotten. Some of the issues I've had were:
* As I'm on a single unit, without a Pri/Sec, the sequence of commands in the KB article are uncertain to me. It is not clear if the Pri is also the Sec in my use case, or if it the Pri specifically refers to the Windows OSSV host.
* At this point, by making some assumptions I managed to get past it not wanting to let me do a QSM of the original location (I believe that was telling me it wasn't possible with that type of source - I assume because it was not properly converted from SV or because it was showing as a VSM relationship in System Manager and not a QSM, and it was a limitation on a OSSV -> QT -> VSM -> QSM type of cascade
* Currently, I got the data to QSM to the new location. When I try to update the OSSV relationship, it tells me it did so, but when I try an actual replication, I get "Transfer aborted: the qtree is not the source for the replication destination."
I'm going to clean up my mess, start fresh with a new test and take some better notes. I'm also going to check for the OSSV manual, I know I've been through the Best Practices one, but as there are many, I suspect I'm just not looking in the one most appropriate to this. If you have a document and page number or a sample of what you've done, I'd be appreciative, but don't think I won't go getting off my duff to try to find the answer on my own I'll be back tomorrow.....
2012-11-21 06:21 AM
Looks like page 159 of the Installation and Administration Guide at http://support.netapp.com/documentation/docweb/index.html?productID=61031. I get it at a high level, will need to give it a try. However, and I may be over thinking it, this refers to relocating the volume in their original states, to new aggregates as I understand it. So in my case, isntead of ending up with my 4 QTree destinations in a new common volume, I'd still end up with 2 destination volumes, with 2 QTree's each, just on a new aggregate. For now, I'd settle for that, as it would clean up some old disk. I'll give it a shot and see if it works just as well if I'm going to a net new volume. My assumption is that it is doing a VSM vs a QSM, and I won't be able to merge two volumes. Knock on wood....
2012-11-21 08:11 AM
PRI is in this case always the OSSV client. SEC is always the NetApp System.
You can get everything in ONE volume, just do not forget to "start" the relationship again (snapvault start -S ...." this is the key to success...
Hope this helps,
2012-11-21 10:32 PM
So I've given it a retry, with the advice you provided and tried to use the two documents to try to get a better triangulation on what either or both wanted, and try a few different things.
I'm near the end but what i have is:
NW-FAS2020A*> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
NW-WSUS1:C:/ NW-FAS2020A:/vol/VOL_OSSV_01/NW-WSUS1_C__ Broken-off 01:03:55 Idle
NW-FAS2020A:/vol/VOL_OSSV_01/NW-WSUS1_C__ NW-FAS2020A:/vol/VOL_OSSV_02/NW-WSUS1_C__ Broken-off 00:44:36 Idle
The first line showed up after doing the "Before executing the recipe, enter the following commands:" from the KB article, to convert the SnapVault path to a SnapMirror, which makes sense. Then after creating the QSM of the original VOL (VOL_OSSV_01) to the new VOL (VOL_OSSV_02), I get the second one. Both documentation tells me I want to quiesce then break the SnapMirror, which ends up with me in a Broken-off state.
If I then try to convert the new path to a SnapVault:
NW-FAS2020A*> snapvault convert /vol/VOL_OSSV_02/NW-WSUS1_C__
Error converting qtree: destination is not in snapmirrored state
If I trye to either modify or start the SnapVault relationship, I get errors that I wasn't neccesarily expecting, but upon reading, they do make sense.
NW-FAS2020A*> snapvault modify -S NW-WSUS1:C:/ NW-FAS2020A:/vol/VOL_OSSV_02/NW-WSUS1_C__
The qtree /vol/VOL_OSSV_02/NW-WSUS1_C__ is not configured in snapvault.
Configure first with the 'snapvault start' command.
NW-FAS2020A*> snapvault start -S NW-WSUS1:C:/ NW-FAS2020A:/vol/VOL_OSSV_02/NW-WSUS1_C__
Qtree /vol/VOL_OSSV_02/NW-WSUS1_C__ already exists and is not a replica.
So it seems like I am very close. Just need to get over this last hump. Any suggestions?
Thanks in advance.
2012-11-21 11:20 PM
With a little button mashing, I was able to get the VOL_OSSV_01 and VOL_OSSV_02 QSM resynced, which then allowed me to do the snapvault convert. I was then able to do the snapvault modify, and a snapvault status show it on the secondary properly.
NW-FAS2020A> snapvault update -w NW-FAS2020A:/vol/VOL_OSSV_02/NW-WSUS1_C__
Thu Nov 22 06:50:12 GMT [replication.dst.err:error]: SnapVault: destination transfer from NW-WSUS1:C:/ to /vol/VOL_OSSV_02/NW-WSUS1_C__ : the qtree is not the source for the replication destination.
Transfer aborted: the qtree is not the source for the replication destination.
This is I guess where I'm stuck for tonight.
2012-11-28 06:06 AM
I had tried a number of snapvault <options> after that, I was never able to get beyond the "qtree is not the source". OnTAP support came back and told me that it was not possible, and unfortunately closed my ticket. Looks like I'm buying hard drives and doing LREP's
2012-11-28 08:07 AM
As you're new to NetApp and it can be a bit overwhelming if you're diving into SnapVault and OSSV, check out the Data ONTAP 8.1 7-mode simulator. (Search the communities site for "simulator") You can install the simulators on your laptop or a spare PC and use them to experiment with OSSV, SnapVault, SnapMirror or just about anything else. The simulators do about 95% of what a real NetApp controller can do.
As an example, I've got VMware workstation on my laptop. I'm running two 8.1 7-mode simulators, OnCommand 5.1 (a.k.a DFM) and a Linux client running OSSV. I use this to experiment with Protection Manager, OSSV backups, complex SM/SV relationships and doing customer demos. Its a fantastic learning tool that avoids the risk of a live production system.