Primary and DR refresh

[Alireza_D]

Hello Everyone

Need a help with one our storage refresh project . We have a Primary Array (A) and secondary array (B) which currently all volumes in cluster A is replicating to B via snapmirror.

We want to refresh the both A and B with new A1 and B1 clusters , what is the best way to this to have min downtime and also being able to resynch snapmirror from new cluster A1 and B1 after the upgrade instead of initializing snapmirror from the base snapshot again.

I can rehost the volume from old SVM in old Array A to new SVM in Array A1 and resynch the snapmirror with Array B but this needs downtime (vol rehost) , but when I snapmirror volumes from array A to A1 and then try to resynch A1 to B I get error since ontap can't find the common snapshot.

Thanks for your help.  

[aladd]

There are multiple ways to do this, depending on how you're performing the cluster upgrade.

option A, headswap keeping the same storage.
option B, add the new A1 nodes to the existing A cluster and perform vol moves to the aggregates on the A1 storage before decommissioning (cluster unjoin) the old A cluster nodes. Then, follow the same action plan for the B/B1 cluster.

option C, SnapMirror to the new A1/B1 clusters via fan out mirrors, this should still have a common snapshot.

there are several possible issues with resync not being able to find common snapshots, below are a few examples, but I'd be interested in the exact failure you're getting.

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/SnapMirror_resync_fails_with_error%3A_No_common_snapshot_copy...

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/Unable_to_update_or_resync_an_SVM_DR_relationship_No_common_S...

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/Unable_to_update_or_resync_a_volume_SnapMirror_relationship_N...

[Alireza_D]

Thanks for the reply , I don't think if headswap is a good idea for our project because anyway we are upgrading the shelves too and if we do headswap we still need to move the data out of old shelves.

Option B seems much better if we can do it while snapmirror replications are still running . So correct me if I m wrong :

1. We add the new nodes and shelves to the existing cluster ( we may need to upgrade the existing cluster since it's running on 9.3 and new nodes are probably coming with 9.8 or 9.9 )

2. non-disruptively move the volumes to the new aggregates owned by new nodes ( should they be in the same SVM ? )   

3. Resynch the snapmirror ? 

[aladd]

Hello @Alireza_D ,

Option B the resynch shouldn't be necessary and the volume will remain mounted to the same SVM.

The information on the process is below:

https://docs.netapp.com/us-en/ontap/volumes/move-volume-task.html

https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-cmpr-980%2FTOC__volume__move.html