PTK snapmirror reverse resync (C.)

[TonyChaffe]

Hi,

I would like to know if it's possible to perform a snapmirror reverse resync on a volume level snapmirror relationship using the PTK.

Example, lets say I have 2 clusters, A and B. A has a volume and is considered the source, B has a volume and is considered the destination of a snapmirror relationship.

All connectivity to A is unavailable, disaster, making it pretty much unusable. I know at this point I can use the Invoke-NcSnapMirrorBreak cmdlet on the relationship, which will make volume B the read/write location, whereby once redirected, users can continue to read and write to the destination.

Now, connectivity is re-established to A, however, users have been writing to volume B for sometime making it the most up to date version of data, whereby the destination is now actually considered the new source.

So, I want to perform a reverse resync of volume B, using the PTK, however, the Invoke-NcSnapMirrorResync cmdlet suggests that this would not only re-establish the snapmirror, but, would have the effect of overwriting all the new data on the volume B, replacing it with the latest snapshot copy from volume A, which at this point, is old.

I suppose what I'm really looking for is an Invoke-NcSnapmirrorReverseResync cmdlet. In the absense of  such a cmdlet, how could you do this with the PTK. I can manage the scaling to multiple snapmirror relationships, but I'm missing how I can script this, it could also be that I've misunderstood the Invoke-NcSnapmirrorResync cmdlet to use it correctly in the above scenario.

Any advice would be greatly appreciated.

Many thanks

[aladd]

Hi@TonyChaffe ,

Which version of ONTAP are your source and destination and with which version of the NetApp PSTK are you working ?

[TonyChaffe]

Hi @aladd 

The Latest ptk, 9.7.1 and OnTap version 9.5P10 for both A and B clusters. basically, I want to be able to do this:

Destination Volume - reverse sync

*Edit* I should add that, once this reverse resync has finished, I know that to get it back to the state it was in before the disaster, I'll need to perform another reverse resync after the initial sync has finished, make A the source and B the destination again, with the data that was accumulated during the outage, effectively putting the relationship back in the state it was in, ready for the next disaster 🙂

*2nd Edit* Sorry, another after thought, the reason I want to use the ptk, is scale. I have quite a few snapmirrors that I would need to perform this on and right clicking each one in the GUI and reverse resyncing, on both clusters, would take sometime.

[aladd · Accepted solution]

The reason that there is no direct command for a reverse mirror is because Snapmirror is a pull operation and would require the PSTK to connect to multiple clusters and differentiate which source and destination you're trying to configure.

The workaround would be to script connections and mirror operations separately to automate mirroring/reverse-mirroring.

[TonyChaffe]

Ahh, ok, so, humour me if you would, I appreciate your attention and I'm exploring the art of the possible.

So, in theory, if the snapmirror relationship is broken, between source A and destination B, if I connect to the A cluster and issue an Invoke-NcSnapmirrorResync -DestinationLocation SVMA:volumeA, then I'm assuming this wouldn't work either, because this relationship doesn't exist, so, I would need to create this relationship?

Hmm, this might work, because both volumes are in a read/write state, the only thing missing is the relationship.

Ok, so, again, in theory and thanks to your guidance, the reverse resync operation in the screenshot, presumably, deletes the snapmirror relationship between A and B and creates a snapmirror relationship between B and A doesn't it? Effectively reversing the relationship, now I think I get it.

So, the flow would look something like this:

Connect to Controller B

Delete snapmirror relationship between Source A and Destination B

Connect to Controller A

Create new snapmirror relationship between Source B and Destination A

Invoke-NcSnapmirrorResync -DestinationLocation SVMA:volumeA

[aladd]

Correct, that is the general idea. However I'm not certain if using this method would require a full baseline or if it would simply mirror the delta.

[bobalon]

Hi there

did you manage to solve this. I have the same issue

at present I try to create a reverse Snapmirror but it fails as both the old source and the new source are RW vols and the destination vol (old source) needs to the a DP type.

I cannot see a way to change a volume from RW to DP so appear stuck

any suggestions?

Thank you

[TonyChaffe]

Hi Bobalon,

Sadly no, due to time-pressures, I was just working out the theory and haven't had the time to revisit, sorry to disappoint. I didn't get that far, but, it's good that you've pointed that out as it's not possible, anyone correct me if I'm wrong, to convert a volume with data into a DP volume, unfortunately.

I would say though, it would definitely be worth gauging the effort in migrating to SVM DR/mirrors as opposed to volume level DR/mirrors, making the need for this kind of activity redundant.

It drastically cuts down on the need to manage volume level snapmirrors. If an SVM is in a snapmirror relationship, any new volumes created on the source svm are automatically mirrored on the svm dr/mirror destination, in addition, depending on set-up/configuration, carefully read the documentation and you'll understand what I mean, all shares, junctions etc are carried over to the destination, so, breaking the SVM mirror relationship and activating the DR SVM means users would likely see very little to no downtime.

[TonyChaffe]

I suppose what would be really helpful to understand from netapp, in collaboration with the ptk team, what operations does the Reverse Resync option perform on a snapmirror relationship, how can that be transposed into powershell cmdlet/s made available in the ptk?

[bobalon]

Tony FWIW

I used the resync CmdLet against an Ontap 9.5simulator and it seemd to reverse the mirror as expected, but when trying against a controller on 9.1 - it fails 

Out of interest what version are you using?

Also agree  - if Netapp can enumerate the steps taken by the oncommand option we could then replicate in Powershell

Thank you

[TonyChaffe]

For sure, or a new cmdlet in the ptk that takes as parameters source and destination controllers, addressing the accepted answer. How do I unaccept an answer 🙂