Skip to main content
Pure Technical Services

ActiveCluster: Non-Disruptive FlashArray Migration Use Case Overview

Currently viewing public documentation. Please login to access the full scope of documentation.

This article describes how to use ActiveCluster to enable non-disruptive storage migrations between two FlashArrays.  It is intended as an overview of the process.


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. 

Screen Shot 2019-10-17 at 10.38.19 AM.png

Step 2. Connect a second FlashArray via validated IP or Fibre Channel replication network.  The 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'.

Screen Shot 2019-10-17 at 10.38.39 AM.png

Step 3. Stretch the pod from Step 1 to the second FlashArray.

Screen Shot 2019-10-17 at 10.38.56 AM.png

Step 4. Wait for the pod synchronization to complete.  Pod status will show a green 'online' icon for both FlashArrays when complete.

Screen Shot 2019-10-17 at 10.39.11 AM.png

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.) 

Screen Shot 2019-10-17 at 10.39.21 AM.png

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. 

Screen Shot 2019-10-17 at 10.39.39 AM.png

Step 10. Unstretch the pod(s) with the migration volumes into the migration target (new) FlashArray. 

Screen Shot 2019-10-17 at 10.39.52 AM.png

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.

Screen Shot 2019-10-17 at 10.40.08 AM.png

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.