SVM-DR/SnapMirror for SVM Super (Short) Express Guide (8.3.1)

The following is a super (short) express guide for SVM-DR/SnapMirror for SVM setup, failover, and failback.

*Note that no consideration of Data LIFs, CIFS servers, protocols ... is in this post, it's purely an exercise in understanding how the SnapMirror side of it works. Please read the official guides for the necessary details to get a successful SnapMirror for SVM setup!


1) Establishing SnapMirror for SVM

## Preparation ##

BOTH::> cluster peer show
BOTH::> system license show
BOTH::> job schedule cron show # IMPORTANT: Create the same custom schedules on the destination cluster!
BOTH::> storage aggregate show

## Creating a destination SVM ##

CLU2::> vserver create -vserver SVM1-DR -subtype dp-destination
CLU2::> vserver show -vserver SVM1-DR

## Create the SVM peer relationship ##

CLU2::> vserver peer create -vserver SVM1-DR -peer-vserver SVM1 -applications snapmirror -peer-cluster CLU1
CLU1::> vserver peer accept -vserver SVM1 -peer-vserver SVM1-DR
BOTH::> vserver peer show

## Creating a SnapMirror Relationship ##

CLU2::> snapmirror create -source-vserver SVM1 -destination-vserver SVM1-DR -type DP -throttle unlimited -policy DPDefault -schedule hourly -identity-preserve false
CLU2::> snapmirror show -destination-vserver SVM1-DR
CLU2::> snapmirror initialize -destination-vserver SVM1-DR
CLU2::> snapmirror show -destination-vserver SVM1-DR


And that’s it, SVM-DR configured!*

2) Failing over to the DP-Destination SVM

## Failing over the dp-destination SVM ##

CLU1::> vserver stop -vserver SVM1
CLU1::> vserver show -vserver SVM1

CLU2::> snapmirror update -destination-vserver SVM1-DR
CLU2::> snapmirror show -destination-vserver SVM1-DR
CLU2::> snapmirror quiesce -destination-vserver SVM1-DR
CLU2::> snapmirror show -destination-vserver SVM1-DR
CLU2::> snapmirror break -destination-vserver SVM1-DR
CLU2::> snapmirror show -destination-vserver SVM1-DR
CLU2::> vserver start -vserver SVM1-DR
CLU2::> vserver show -vserver SVM1-DR

# Note: Notice that the dp-destination SVM’s subtype is now default!

3) Failing Back to the Source SVM

## Reactivating the Source SVM ##

CLU1::> snapmirror create -source-vserver SVM1-DR -destination-vserver SVM1 -type DP -throttle unlimited -policy DPDefault -schedule hourly -identity-preserve false
CLU1::> snapmirror show -destination-vserver SVM1
CLU1::> snapmirror resync -destination-vserver SVM1
CLU1::> snapmirror show -destination-vserver SVM1

CLU2::> vserver stop -vserver SVM1-DR
CLU2::> vserver show -vserver SVM1-DR

CLU1::> snapmirror update -destination-vserver SVM1
CLU1::> snapmirror show -destination-vserver SVM1
CLU1::> snapmirror quiesce -destination-vserver SVM1
CLU1::> snapmirror show -destination-vserver SVM1
CLU1::> snapmirror break -destination-vserver SVM1
CLU1::> snapmirror show -destination-vserver SVM1
CLU1::> vserver start -vserver SVM1

## Resynchronizing the destination SVM from the source SVM ##

CLU2::> snapmirror resync -destination-vserver SVM1-DR
CLU2::> snapmirror show -destination-vserver SVM1-DR

## Tidy up ##

CLU1::> snapmirror delete -destination-vserver SVM1
CLU2::> snapmirror release -destination-vserver SVM1


Q: Could an existing pair of SVM’s with existing SnapMirrors be converted into an SVM-DR relation?

This was actually the point of the lab test, to see if it might be possible. And I did try, effectively picking up from the “Failing Back to the Source SVM” workflow. The problem is that SVM-DR detects volumes on the destination, and complains when trying to resync the SVM-DR relation:

Error: command failed: The following volumes "rootvol,vol1,vol2,vol3" on the destination Vserver are new volumes and do not correspond with the volumes on the source Vserver. Delete them using the (privilege: advanced) "volume delete -force" command. When this command completes successfully, try the operation again.

Of course the volumes do correspond, but I guess there’s a database somewhere that says they don’t …


Comments

  1. vCosonok - Does reverse resync work in the SVM DR, what is the best solution to put back the orginal source from destination.

    ReplyDelete
    Replies
    1. Hi Mahendra, reverse resync does work. Really, it's not reverse resync, just standard resync with a new "SnapMirror for SVM" in the reverse direction. Cheers VC

      Delete
  2. Does it work if source SVM is on mirrored aggr

    ReplyDelete
    Replies
    1. This would not be possible.

      Delete
    2. What if I have spare 10gb spare non-root non-mirrored aggr space on both the nodes

      Would SVM snapmirror work ?
      Would volume snapmirror work ?

      Delete
    3. Apologies, I might have been mistaking the question being regards MetroCluster - I'm pretty certain that MetroCluster does not support being source or destination for SVM-DR. If this is not a MetroCluster setup then yes to both questions - you can snapmirror to and from a syncmirror aggregate (not sure how snapmirror for SVM would work in this situation - try it out and see.)

      Delete
    4. I tried it does allow , provided you somehow carve out 10gb space aggr on each node

      Delete
    5. Thanks for the update imagegenie - good to know it's allowed. 10gb is very small, are you doing this in a VSIM or ONTAP Select perhaps?

      Delete
  3. And do we need special license for this

    ReplyDelete

Post a Comment