Monday, 5 September 2016

Pre-Stage SVM-DR Relation pre 7 to C Cutover

If you’ve got big volumes to transition from 7 to C, and want SVM-DR functionality almost on the button post 7 to C cutover (i.e. it’s not acceptable to have to wait for the entire SVM to SnapMirror across to DR), it’s possible to pre-stage the SVM-DR relation. Here’s an example to show how:

Note: cDOT version here is 8.3.2. 7MTT version is 2.3.1.

1) Create the initial baseline data copy from 7-Mode to cDOT.

Image: 7-Mode volume baselined to cDOT

1b) Extra Belt and Braces Step

Create a snapshot on the 7-Mode source volume(s) "snap create VOLNAME SNAPNAME", and perform an update with 7MTT. The success of the SVM-DR resync depends upon having an in-common 7-Mode snapshot.

2) Stop the 7MTT service on the 7MTT box:

Via DOS/PowerShell>

net stop "Transition Tool"

3) On source cluster (clu1), we break the 7 to C SnapMirror, and remove volume transition protect:


clu1::>

snapmirror break -destination-path FAS101_clu1:TVOL001
set -c off; set d
volume transition-protect -vserver FAS101_clu1 -volume TVOL001 -is-enabled off


4) On the DR cluster (clu2), we create the SVM-DR vserver, vserver peer, and then accept the vserver peer on clu1:


clu2::>

vserver create -vserver FAS101_clu2 -subtype dp-destination
vserver peer create -vserver FAS101_clu2 -peer-cluster clu1 -peer-vserver FAS101_clu1 -applications snapmirror

clu1::>

vserver peer accept -vserver FAS101_clu1 -peer-vserver FAS101_clu2


5) We create the SVM-DR relation, initialize, and wait for initialization to complete:


clu2::>

snapmirror create -source-path FAS101_clu1: -destination-path FAS101_clu2: -identity-preserve true
snapmirror initialize -destination-path FAS101_clu2:
snapmirror show -destination-path FAS101_clu2:


6) Once the SVM-DR relation is initialized, we break and delete it:


clu2::>

snapmirror break -destination-path FAS101_clu2:
snapmirror delete -destination-path FAS101_clu2:


7) Then we release the SVM-DR relation on the source cluster, and resync the 7 to C SnapMirror:


clu1::>

snapmirror release -destination-path FAS101_clu2:TVOL001
snapmirror resync -destination-path FAS101_clu1:TVOL001


Note: You have to do the delete and release, otherwise the 7 to C resync errors with "Destination ... cannot be the source of another SnapMirror relationship"

8) Restart the 7MTT service on the 7MTT box:

Via DOS/PowerShell>

net start "Transition Tool"

And add in the credentials to the 7-Mode Controllers and ONTAP systems.

9) {When the time comes...*} Complete the Transition via 7MTT!

Image: Completed 7 to C Transition

*You don’t want this to be too long after you’ve seeded SVM-DR since the in-common Snapshots may be lost.

10) Use sync-cron.ps1 from the following link to ensure cron schedules are in sync from source to DR clusters:


11) Re-create the SVM-DR relation and resync:


clu2::>

snapmirror create -source-path FAS101_clu1: -destination-path FAS101_clu2: -identity-preserve true
snapmirror resync -destination-path FAS101_clu2:


IMPORTANT: If you are considering using this method, please test thoroughly in your environment first.

APPENDIX: Event wafl.snaprestore.revert

Of course, for the SVM-DR resync to work, there’s got to be in-common snapshots (otherwise it’s a full baseline resync again.) You might see events like the below when the volume SnapRestore reverts to the common (previous) Snapshot copy:


clu2::> event log show -event wafl.snaprestore.revert* -instance

Node: clu2n1
Sequence#: 11211
Time: 9/6/2016 00:16:02
Severity: INFORMATIONAL
Source: config_async_0
Message Name: wafl.snaprestore.revert
Event: wafl.snaprestore.revert: Reverting volume TVOL001@vserver:8d16297e-7364-11e6-b6c8-000c29a5823e to a previous Snapshot copy with snapid 1.
Corrective Action: (NONE)
Description: This message occurs during volume initialization when the system reverts to a previous Snapshot(TM) copy.


1 comment:

  1. I am a huge fan of yours.. I have done the transition with out of box methodologies.. Whenever I needed help, your blog was there

    ReplyDelete