Example Setup:
srcfiler is at primary site
dstfiler at secondary site
vcenter1 is at primary site
vcenter2 is at secondary site
datastore is a volume on srcfiler
datastore is replicated to rep_datastore on dstfiler
datastore contains an iSCSI LUN attached to vcenter1
vcenter1 has an SRM protection group that protects datastore
vcenter2 has a corresponding SRM recovery group
filer> monospace text refers to CLI (telnet) commands on filer
Precedent:
SRM Failover (not test) of Recovery Group on vcenter2
Failback Procedure:
1. Reverse direction of replication
- srcfiler> snapmirror resync -S dstfiler:rep_datastore srcfiler:datastore
-
Answer yes (y) to “Are you sure you want to resync this volume”
2. Wait for sync to finish
- srcfiler> snapmirror status
-
Wait until state of rep_datastore to datastore is Snapmirrored
3. Shutdown all VMs running on rep_datastore
4. Update replication
-
srcfiler> snapmirror update -S dstfiler:rep_datastore datastore
5. Remove original VM from inventory on vcenter1
6. Create reverse protection plan on vcenter2 and recovery group on vcenter1
7. Run failover of new recovery plan
-
Failover test will not work, since flexclone is not licensed on srcfiler
8. Restart VMs if necessary
9. Re-establish replication in correct direction
- dstfiler> snapmirror resync rep_datastore
10. Clean up extra replication snapshots
- dstfiler> snapmirror release rep_datastore srcfiler:datastore
- dstfiler> snapmirror update rep_datastore
-
srcfiler> snap list datastore
- Make note of all snapshots of named
- Make note of all snapshots of named
srcfiler(systemid)_datastore.# They should NOT be followed by
the designation (snapmirror)
-
srcfiler> snap delete srcfiler(systemid)_datastore.#
-
Be careful not to delete the wrong snapshots. Do NOT delete any snapshot that is followed by the designation (snapmirror), it is in use by replication and will require re-baselining if deleted.
-
- dstfiler> snapmirror update rep_datastore
-
Verify that snapmirror status datastore on both sides shows replication going in only one direction, from srcfiler to dstfiler
11. Unset fs_sized_fixed on datastore
- This option gets automatically added to replica destination volumes
- IMPORTANT: If you don’t do this, autosize won’t work (can break thin provisioning & snapshots)
- srcfiler> vol options datastore fs_size_fixed off
Post Failback:
SRM resignatures the volume when it fails it over, and then again when it fails it back.
This causes minor inconsistencies.
- On vcenter1, rename datastore (remove snap-sig- prefix)
- If datastore is backed up with SMVI, destroy and recreate scheduled tasks, so that
they refer to the new signature
News Tags:
- ,netapp srm failback,snapmirror failback,srm failback,netapp reverse snapmirror,netapp snapmirror failback,snapmirror reverse sync,netapp srm failback plugin,SRM test snap datastore not removed,srm netapp failback,netapp failback,snapmirror reverse,snapmirror resync reverse,netapp snapmirror reversed,snapmirror srm failback,netapp snapmirror failover and failback,netapp reverse resync,netapp resync snapmirror,netapp ifgrp failover failback,snapmirror reverse resync,reverse snapmirror,netapp snapmirror reverse sync,netapp failback command,snapmirror resync,snapmirror release resync,snapmirror procedures,snapmirror resync failback,snapmirror resync -S,snapmirror failover and failback guide,snapmirror automated failback,snapmirror and srm
No related posts.