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.