ONTAP Discussions

Relocate OSSV Secondary to new Vol/QTree

AWOROCH2012
8,612 Views

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__

<etc>

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 4.0.1.7550 (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. 

Any suggestions?

Thanks!

13 REPLIES 13

peter_lehmann
8,570 Views

Hi Avram

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?

Peter

AWOROCH2012
8,570 Views

Peter:

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.....

Avram

AWOROCH2012
8,570 Views

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....

peter_lehmann
8,570 Views

Hi Avram

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,

Peter

AWOROCH2012
8,570 Views

Peter:

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.

AWOROCH2012
8,571 Views

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. 

peter_lehmann
8,571 Views

Looks like it needs one last "snapvault start -S" to get the thing properly registered in Ontap... Then the "snapvault update" should work again.

AWOROCH2012
8,572 Views

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  

reide
8,570 Views

Avram,

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.

Reid

AWOROCH2012
6,112 Views

I've actually got an older FAS2020 (anyone know where I can get a replacement battery? ) to poke around with, but have the simulators.  I really should consider a larger test environment on my laptop, right now it's just a virtual vSphere environment.  Sigh, need a 32gb laptop, looks like

reide
6,112 Views

I'm running on a laptop with 16 GB of RAM and I've got plenty left over for Outlook and other apps running the background.   The simulators are nice because they're hardware independent, they consume very little power (unlike the FAS2020's power draw), they make no noise (unlike the FAS2020's power supplies and fans) and they're portable. I use USB 2.0 external 2.5" hard drives for my simulators so that I'm not contending for I/O with my laptop's internal HDD and I have plenty of capacity to give to my sims.  Works great.

reide
6,112 Views

Avram,

To answer your original question:

  • You can relocate and even rename your existing SV secondary volumes.  Other people have posted details on how to accomplish that.
  • Protection Manager even has a built-in utility that will automatically migrate secondary volumes to different aggregates or controllers.  Check out "Secondary Space Management" in the Protection manager on-line help.
  • To the best of my knowledge, you cannot consolidate qtrees on multiple volumes into a single SV secondary volume without re-baselining some of those relationships.

It sounds like you're going to start-over and try again.  Here is a tip:

  • Protection Manager has a Fan-in ratio setting that controlls how many Primary volumes & qtrees you can fan-into a single secondary volume.  It sounds like you want to fan-in, so check the "dpMaxFanInRatio" setting on your DFM server.  If it is set to 1, try increasing this to 4.
  • C:\> dfm option list | grep dpMaxFanInRatio   (to see what it's currently set-to)
  • C:\> dfm option set dpMaxFanInRatio=4   (to force Protection Manager to fan-in to a SV secondary volume)

Reid

AWOROCH2012
6,112 Views

Reid:

That is kind of what I'm understanding as well.  That one can relocate the VOLUME, but one cannot relocate just the QSM relationship.  Has to do with cascading and that an OSSV is simialr to a QSM and can't have two QSM's in a SV relationship or something.  I'm mashing together concepts in my mind, but that's the general takeway I got.

So I can have:

SERVERA:E:/ -> FAS3240:aggr1/vol/vol1/SERVERA_E__

SERVERB:E:/ -> FAS3240:aggr1/vol/vol1/SERVERB_E__

SERVERC:E:/ -> FAS3240:aggr2/vol/vol2/SERVERC_E__

SERVERD:E:/ -> FAS3240:aggr2/vol/vol2/SERVERD_E__

Become

SERVERA:E:/ -> FAS3240:aggr3/vol/vol1/SERVERA_E__

SERVERB:E:/ -> FAS3240:aggr3/vol/vol1/SERVERB_E__

SERVERC:E:/ -> FAS3240:aggr3/vol/vol2/SERVERC_E__

SERVERD:E:/ -> FAS3240:aggr3/vol/vol2/SERVERD_E__

With no issues. 

I cannot, however, have:

SERVERA:E:/ -> FAS3240:aggr3/vol/vol3/SERVERA_E__

SERVERB:E:/ -> FAS3240:aggr3/vol/vol3/SERVERB_E__

SERVERC:E:/ -> FAS3240:aggr3/vol/vol3/SERVERC_E__

SERVERD:E:/ -> FAS3240:aggr3/vol/vol3/SERVERD_E__

As I am relocating the QSM/OSSV qtree at that point.  The NetApp KB even mentions something about it "Due to the use of SnapMirror on the primary system, qtrees SnapVaulted from OSSV hosts are not supported." but it is unclear if that is only on a situation where you are migrating from an OldSecondary to NewSecondary NetApp, and how it affects OSSV.  The KB article seems well suited to NetApp <-> NetApp Pri/Sec relationships, but seems to only cover OSSV anecdotally.  For example, while there is a snapvault.exe for OSSV on the OSSV host, there is no snapmirror.exe nor a provision to create a common snapshot.  My understanding is that this doesn't work mostly becuase that common checkpoint snapshot is done at the VOL level not QTREE and thus, when the QSM move happens to the new VOL, that common snapshot is lost, forcing a re-baseline.  This would be why a VSM works, as the snapshots follow the volume container.

Oh well.  At this point, as time consuming as the LREP's will be, it will be less time than trying to figure out how to do it the fancy way, which is very unfortunate.

Public