Questions regarding ‘volume move’ and snapmirror relationships in CDOT

[parkesje1]

I need to migrate multiple volumes(~8PB total) that are in snapmirror relationships. Currently running 8.2.2 for reference.

1.When migrating the ‘source’ volume to a new aggregate will the snapmirror relationship still work after the move has finished? If it does break, what things will I need to do in order to fix it?

Considerations:
-The volume mirrors only once every 3 hours and there should be hardly any changes if any at all.

-All source volumes are served via nfs, but not frequently accessed as this is primary archive data.

 2.) Can I use ‘volume move’ to migrate the ‘destination’ sides of the snapmirror relationship? The replication side is getting higher density disks as well.

 3.) Any known issues involving ‘volume move’ from FAS hardware to E-series?

[JSHACHER11]

1. not a problem. snapmirror will continue without an issue

2. no. you need to break and then move (or clone)

3. impossible (AFAIK). different OS

[parkesje1]

Thank you for the response. So for the E-series hardware I'm planning to add it to the cluster with new 8080 heads and migrate data via 'volume move' to the e-series hardware.  At this point I know that I can add E-series to our cluster with the 'flex array' license'.  However since I've never dealt with this configuration before I'm not clear on what Ontap commands will work with the underlying E-series storage that uses (Santricity OS). The main thing we want though is for snapmirror to work between from FAS -> E-series and hopefully the 'volume move' command for the migrations.

[bobshouseofcards · Accepted solution]

If you are virtualizing the E-series behind the FlexArray license - you don't need to worry about what you can and can't do in Data OnTAP.  The virtualized LUNs from the E-series appear as disks to the Filers, from which you build aggregates.  After that, everything is the same.  That's what FlexArray (f.k.a. V-series controllers) is designed to do.  The fact that the actual physical storage is on a different platform or controlled with a different OS is completely hidden to you once you get to the aggregate level.

There are differences in managing the "disks" themselves between native and virtualized and an aggregate built from virutalized disks is RAID-0 instead of RAID-DP (the backend storage manages the RAID independently) but all the usual stuff - operations/capabilities - is the same.  A volume is a volume on whichever aggregate it is stored.

[USCadmin909]

This was an excellent suggestion