Moving SnapMirror sources and destinations to a new storage cluster

[SMLocke]

We're looking to migrate from two FAS3250s to AFF FAS8080s that are already in production. In this case, we have two data centers, one two-node FAS3250 at each, SnapMirroring volumes in both directions. Each data center also has a two-node AFF FAS8080, which will eventually be the "home" of all data currently living on the 3250s. The 3250s will be decommed shortly after the migration. All storage clusters in scope are running CDOT 8.3.2P5.

We need to be able to migrate SnapMirror source *and* destination volumes from each 3250 to their new homes on the 8080. We also have to maintain the SnapMirror relationship between the two sites, and be able to fail over to any given snapshot within the retention period after the migration is complete.

Essentially, a crude cave painting of the idea looks something like this:

I've seen this article [https://library.netapp.com/ecmdocs/ECMP1368826/html/GUID-6C850BA4-E522-4F68-841F-D7E273ADE782.html], which talks about moving SnapMirror sources, and it seems to be a great start. However, some of the commands (e.g., editing a snapmirror.conf file) indicate an assumption of 7-mode. Does this command set make sense for CDOT?

It feels like a fairly complex migration, fraught with danger. What other considerations do I need to make? What am I missing?

[colsen]

Hello,

So you're right - that article is 7mode centric.  Is there anyway you can obtain a couple cluster interconnect switches?  If you can, then you can join the AFF8080s to the cluster currently hosted on the FAS3250s (convert the current cluster from switchless to switched) and then you can non-disruptively move the volumes/SVMs/etc onto the AFF8080s.  Once you're done you can decommission the FAS3250s.  This is a lot of work but if zero downtime is a goal then it's taking full advantage of cluster-mode goodness and minimizing the risk to your data and snapmirror relationships.

If switches are out of the question, you can create a 4-way peer between the two swichless clusters and fork your mirror relationships from the sources (i.e. maintain your current snapmirror destination/schedule on each of the 3250s but create a second destination over to the corresponding AFF8080s).  You'll have to figure out a downtime/cutover for making the SVMs/volumes active on the AFF8080s (and re-establishing the data LIFs/etc on the new platform) but you shouldn't be "at risk" per se with regards to losing your data.  It might be interesting to experiment with SVM DR to see if you can also orchestrate the SVM migration as well, but that'd be a pretty involved design...

Hope that helps,

Chris

[DinoBob]

Moving snapmirror relationships to a new pair in CDOT is not difficult. If you have old pair A (prod) and B (DR) and new pair C (prod) and D (DR), you enact the scenario like this: 

Create new DP volume on C

Create new DP volume on D

Initialize A > C

Initialize B > D

Discontinue access to A. 

Create a named snap (i.e. "syncsnap") on A. 

Update A > B using this snap as the -source-snapshot.

Update B > C using this snap as the -source-snapshot.

Update A > D using this snap as the -source-snapshot. 

Break/delete the snapmirror from A > B. 

Break/delete the snapmirror from B > C. 

Break/delete the snapmirror from A > D. 

Create the snapmirror from C > D. 

Resync the snapmirror from C (source) to D (destination), using the named snap (i.e. "syncsnap") as the -source-snapshot. 

The relationship will resync without re-baselining needed. 

Alternately, prior to this, you can update the A > C and B > D relationships using previous snaps as the -source-snapshot parameter, if you want/need to maintain the snapshot chain.