Non-disruptive storage migration between two FlashArrays is one of several ActiveCluster use cases. The migration process is essentially an extension of the base ActiveCluster stretched storage capability for hosts with uniform storage connectivity. Said another way, once a host has uniform storage array connectivity (accessing the same stretched volumes across two FlashArrays) removing one of the two FlashArrays is part of the transparent failover behavior of ActiveCluster. This KB reviews the steps to perform a non-disruptive FlashArray migration.
This KB is intended to provide Pure FlashArray Customers, Partners, Storage Administrators, Solutions Architects, and Pre-Sales Systems Engineers with an understanding of the non-disruptive FlashArray migration (or workload consolidation onto a single FlashArray) process. Individual host operating system and multi-path driver settings are covered in OS-specific connectivity guides and are outside the scope of this article.
FlashArray Migration Using ActiveCluster
Step 1. Move FlashArray volumes to be migrated into a newly created or into an existing (empty) unstretched pod.
Step 2. Connect a second FlashArray via validated IP replication network. The IP replication network requirements, best practices, and validation process is described in the ActiveCluster Requirements and Best Practices KB article.
The following steps assume and refer to the second FlashArray as the 'migration target'.
Step 3. Stretch the pod from Step 1 to the second FlashArray.
Step 4. Wait for the pod synchronization to complete. Pod status will show a green 'online' icon for both FlashArrays when complete.
Step 5. Zone the host to the migration target (new) FlashArray fibre channel ports and then connect the host to the pod volumes that were stretched in Step 3 (using the FlashArray GUI or CLI.)
Step 6. Perform a host OS storage rescan to discover newly added paths.
Step 7. Confirm the host is using the newly added paths. One way to confirm this is to use the 'purehost monitor --balance' command on both FlashArrays.
Confirm the new paths are available and in use before proceeding to the next steps in this procedure.
Output on FlashArray1 (migration source):
pureuser@FlashArray1> purehost monitor --balance Name Time Initiator WWN Initiator IQN Initiator NQN Target Target WWN Failover I/O Count I/O Relative to Max mig-host 2019-10-18 11:25:27 PDT 21:00:00:0E:1E:25:9A:60 - - CT0.FC2 52:4A:93:7B:B2:62:54:02 - 65451 100% 21:00:00:0E:1E:25:9A:60 CT1.FC2 52:4A:93:7B:B2:62:54:12 - 65509 100% 21:00:00:0E:1E:25:9A:61 CT0.FC2 52:4A:93:7B:B2:62:54:02 - 65470 100% 21:00:00:0E:1E:25:9A:61 CT1.FC2 52:4A:93:7B:B2:62:54:12 - 65509 100%
Output on FlashArray2 (migration target):
pureuser@FlashArray2> purehost monitor --balance Name Time Initiator WWN Initiator IQN Initiator NQN Target Target WWN Failover I/O Count I/O Relative to Max mig-host 2019-10-18 11:24:51 PDT 21:00:00:0E:1E:25:9A:60 - - CT0.FC2 52:4A:93:75:6F:E4:00:02 - 66110 100% 21:00:00:0E:1E:25:9A:60 CT1.FC2 52:4A:93:75:6F:E4:00:12 - 65980 100% 21:00:00:0E:1E:25:9A:61 CT0.FC2 52:4A:93:75:6F:E4:00:02 - 66110 100% 21:00:00:0E:1E:25:9A:61 CT1.FC2 52:4A:93:75:6F:E4:00:12 - 65978 100%
Notice the last column on the right shows 100% for all paths for the host named mig-host.
Step 8. Repeat Steps 1, 3 through 5 for all volumes that will be migrated.
If you are constrained due to pod count limits, it may be necessary to complete the migration for the pods that are in use first, then re-use existing pods for any additional migrations.
Step 9. Disconnect the host from the migration source (original) FlashArray volumes.
Do not remove any FlashArray to host zones at this point.
Step 10. Unstretch the pod(s) with the migration volumes into the migration target (new) FlashArray.
Step 11. Move migrated volumes out of the pod. Once all of the volumes are moved out, the pod can either be destroyed be re-used for additional migrations.
This step is non-disruptive.
Step 12. Do not proceed until you've confirmed all volume migrations have been completed. Once completed, use the FlashArray GUI or CLI, to disconnect the migration source (original) FlashArray from the migration (new) target FlashArray.
Step 13. Optional Cleanup: Remove zoning from the host to the migration source (original) FlashArray provided there are no longer any volumes residing there that are being accessed by the host. Any empty unstretched pods can also be destroyed during this optional cleanup step.