NetApp and SRM Failback Procedure

by julio on

 

 

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

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:

Bookmark and Share

No related posts.

Leave a Comment

Comment moderation is enabled. Your comment may take some time to appear.

Previous post:

Next post: