Reverse Resync SnapMirror workflow

Goal

The Reverse Resync SnapMirror workflow is one of several workflows that enable you to carry out disaster recovery tasks in event of data storage disruption. This workflow enables you to generate from a broken SnapMirror-based protection relationship a reversed SnapMirror relationship in which the former SnapMirror destination volume that provided data protection and is now serving data becomes the SnapMirror source volume and the former SnapMirror source volume becomes the destination volume with its current data mirrored from the former destination volume.

Prerequisites

 

·         You must be running Data ONTAP 8.2 or later on the affected cluster or clusters.

·         A SnapMirror based protection relationship between source and destination volumes must already exist.

·         The SnapMirror protection relationship must already be broken.

·         The broken protection relationship must be a SnapMirror relationship, not a SnapVault relationship.

·         Both the source volume and destination volume must be online.

·         The intended destination volume (the original source volume) must not also be the destination in another data protection relationship.

About this workflow

·         The Reverse Resync SnapMirror workflow is typically executed under the following circumstances:

 

o    A disaster event has disabled and taken offline the data serving source volume in a SnapMirror-based protection relationship.

o    In response to that event the SnapMirror relationship is broken, and the original SnapMirror destination volume is converted from a data protection volume to a read/write volume, replacing the original source volume at serving data while you repair or replace the original source.

o    After you bring back the original source volume online, your intent is to continue SnapMirror protection, but with the former source volume now functioning as the destination volume providing data protection and the former destination volume now functioning as the source volume while continuing in its new data serving capacity.

 

·         Additional characteristics of this workflow include the following:

 

o    When this workflow is executed, data on the intended destination volume that is newer than the data on the common Snapshot copy is deleted.

o    When this workflow is executed, the policy and schedule created on the reversed SnapMirror relationship are the same as those on the original protection relationship. If a policy or schedule does not exist, they are created.

WFA user actions

 

1.       Click Portal > Data Protection > Reverse Resync SnapMirror to display the Execute Workflow dialog box for the Reverse Resync SnapMirror workflow.

2.       Specify the following inputs:

·         Destination Cluster – The name of the cluster where the intended source volume (the original destination volume) resides

·         Destination Storage Virtual Machine – The name of the Storage Virtual Machine (SVM) where the intended source volume (the original source volume) resides

·         Destination Volume – The name of the intended source volume

3.       Click Execute.

Workflow sequence

 

When completing the Reverse Resync SnapMirror workflow, WFA executes the following sequence of tasks:

 

1.       Search for relationship. WFA calls the No-Op Cluster-Mode command to search the WFA cache to confirm that the SnapMirror relationship between the former source volume and the former destination volume is broken.

 

2.       Check source volume is not SnapMirror destination of another volume. WFA calls the No-Op Cluster-Mode command to verify that the former source volume (intended destination volume) is not the destination of any other source volume.

 

3.       Search for schedule on source cluster. WFA calls the No-Op Cluster-Mode command to check whether the cluster on which the intended destination volume resides has the SnapMirror transfer schedule that is attached to the broken relationship. 

 

4.       Create schedule. If no schedule exists on the cluster on which the intended destination volume resides, WFA calls the Create schedule – Perl command to create a SnapMirror transfer schedule on it.

 

5.       Create SnapMirror policy. If the SVM where the intended destination resides has no SnapMirror policy of the same name as the policy for the broken SnapMirror relationship, WFA calls the Create SnapMirror policy – Perl command to create such a policy.

 

6.       Create SnapMirror. WFA calls the Create SnapMirror command to generate a new reversed SnapMirror relationship in which the former destination volume is the source volume and the former source volume is the destination volume.

 

7.       Resync SnapMirror. WFA calls the Resync SnapMirror command to start the SnapMirror transfer of data from the former destination volume (now the source volume) to the former source volume (now the destination volume)

Result

 

After the final task in the Reverse Resync SnapMirror workflow is successfully completed, the former source volume and former destination volume of a broken SnapMirror relationship are partners in a newly-generated reversed SnapMirror relationship with the source volume and destination volume roles reversed. The newly-designated destination volume is updated with newer data transferred from the newly-designated source volume.

Workflow customizations

 

Cleanup of the broken SnapMirror relationship

 

You can customize the default Reverse Resync SnapMirror workflow to clean up the original broken SnapMirror relationship.

 

Because, depending on the amount of data to be resynchronized, the resynchronization operation between the newly-designated source volume and the newly-designated destination volume might require several hours or days to complete, the default Reverse Resync SnapMirror workflow ends after starting but not completing the resynchronization process between the source volume and the destination volume.  As a result, at the end of the default Reverse Resync SnapMirror workflow, the original broken SnapMirror relationship, though no longer active or operable, remains in existence. 

 

If you want to customize the Reverse Resync SnapMirror workflow to clean up the broken relationship, you can complete the following steps:

 

1.       Add a task to the workflow that contains a Wait for SnapMirror Resync command to monitor the resync operation and wait for it to finish. Though no such specific WFA command is supplied for this purpose, you can create one by using the WFA command editing function to clone the current Wait for SnapMirror Initialization command and customize the clone to monitor the progress of a SnapMirror resync operation. 

 

2.       Add a broken relationship cleanup task to the workflow and include the Remove SnapMirror – Perl command.