How to setup a SVM DR in CDOT 8.3.1 including all configuration and data

With Data ONTAP 8.3.1 NetApp introduced the long expected SVM-DR. With the new feature you can easily build up a disaster recovery solution for your SVMs. In this post I’m going to show you how you can setup a SVM-DR relation between two different ONTAP clusters. It will be a SVM-DR where all information’s including CIFS, NFS and IP-Addresses are replicated to the destination cluster. There is also a possibility to perform some kind of advanced configuration for subnet and interface mapping if required.

We will look into the steps performed on source and destination cluster to setup the SVM-DR, perform a Failover test, rollback to source and resync after failback. Before you start please make sure that the two ONTAP cluster are peered already and your source SVM is up and running. Please note that in this sample we are working with CIFS and NFS only. SVM DR can also be configured for iSCSI and FC but therefore you need to perform more steps regarding interfaces and iGroups. Please have a look to the NetApp documentation for advanced setup. All steps are done by CLI only. Right now there is now integration into the system manager.

As every time, no warranty for the scripts. You need to change the SVM and cluster names to make it working for you. We are working on a SVM lever here.

Initial Setup:
First we will have a look into how an initial SVM-DR relation is configured.

On the destination cluster:
1. Create your new DR SVM on the destination cluster. The important thing here is to set the subtype to dp-destination:

vserver create -vserver SVMDR02 -subtype dp-destination

2. Create a peer relationship between your destination SVM the source SVM:

vserver peer create -vserver SVMDR02 -peer-vserver SVMDR -peer-cluster RLPEDGE01 -applications snapmirror

On the source cluster:
3. Accept the peer relationship on the source cluster for the source SVM:

vserver peer accept -vserver SVMDR -peer-vserver SVMDR02

On the destination cluster:
4. Create a new snapmirror relationship between your source and destination SVM. Setting the identity-preserve to true means that all configuration and data will be transferred. The schedule is set to hourly in our case. If you want to change the schedule you can create your own and set it afterwards.

snapmirror create -source-vserver SVMDR -destination-vserver SVMDR02 -type DP -throttle unlimited -policy DPDefault -schedule hourly -identity-preserve true

5. Initialize your relationship

snapmirror initialize -destination-path SVMDR02:

The initial setup is now done and the SVM-DR is mirroring according to your schedule. You can even see the destination SVM in the system manager as a powered off SVM.
2015-12-23 13_36_57-Settings

Failover to secondary SVM (DR Test):
Next step is to perform a failover to our secondary SVM. Attention: This means you will have some downtime of your data. Only perform this if you are sure that you want to test to failover. Again, no warranty for any outage or failures in your data center.

On the source cluster:
1. First you have to stop you running SVM on the source cluster:

vserver stop -vserver SVMDR

On the destination cluster:
2. Before we failover we update the snapmirror relationship to get the latest version of the source data and configuration:

snapmirror update -destination-path SVMDR02:

3. After the update is finished (please check with snapmirror show) we quiesce the relationship to make sure there is no task running:

snapmirror quiesce -destination-path SVMDR02:

4. After the quiesce is finished (please check with snapmirror show) we can break the snapmirror to make the destination writeable:

snapmirror break -destination-path SVMDR02:

5. After the break is finished (please check with snapmirror show) we can start the secondary SVM:

vserver start -vserver SVMDR02

The Failover is now completed and you should be able to ping and access all you data.

Failback to source (After DR Test):
After a successful failover and tests we are ready to failback to the source SVM. In case you had a disaster and the source SVM is no longer available you have to create a new one. Please refer to the NetApp guides on how to proceed here.

On the source cluster:
1. First we have to create a new snapmirror relationship from the DR SVM to the source SVM:

snapmirror create -source-path SVMDR02: -destination-path SVMDR: -type DP -throttle unlimited -identity-preserve true

As soon as the relationship is created we can perform a resync to sync the changed data back to the source SVM:

snapmirror resync -destination-path SVMDR:

On the destination cluster:
3. After the resync is done (please check with snapmirror show) we can shut down the DR SVM. Attention, this means downtime:

vserver stop -vserver SVMDR02 -foreground true

On the source cluster:
4. After the DR SVM is done (please check with SVM show) we can update the snapmirror relation:

snapmirror update -destination-path SVMDR:

5. After the update is done (please check with snapmirror show) we can quiesce the relation:

snapmirror quiesce -destination-path SVMDR:

6. After the quiesce is done (please check with snapmirror show) we can break to relation to make the source writable:

snapmirror break -destination-path SVMDR:

7. After the break is done (please check with snapmirror show) we can now boot up the original source SVM:

vserver start -vserver SVMDR

Your source SVM is now back online and can be used.

Resync after Failback:
After a successful failback we now want to have the original state back. Meaning the source SVM should proceed with replicating to the destination SVM. Therefore we have to resync the original SnapMirror relation.

On the destination Cluster:
1. To resync the original SnapMirror relation please execute the following:

snapmirror resync -destination-path SVMDR02:

On the source cluster:
2. After everything is done you can delete the SnapMirror relation which was used to resync back to source.

snapmirror delete -destination-path SVMDR:

Named as VMware vExpert 2016

Last Friday VMware announced the new vExperts for 2016. And I’m luckily one of them.


What is VMware vExpert? (official info)
The VMware vExpert program is VMware’s global evangelism and advocacy program. The program is designed to put VMware’s marketing resources towards your advocacy efforts. Promotion of your articles, exposure at our global events, co-op advertising, traffic analysis, and early access to beta programs and VMware’s roadmap.

You can find more information’s here.