Home > Storage > PowerMax and VMAX > Storage Admin > Dell PowerMax: Data Mobility Best Practices and Operational Guide > Walkthrough pre-copy with Metro Based Non-Disruptive Migration
In this section we will walk through the steps to perform a migration using the precopy option, this section will show screenshots from Unisphere for PowerMax. This example will migrate an application with all of its devices in the storage group named “PreCopy-Migrate-SG” on Array 00297600841 to array 000120200287.
Prior to executing the migration create it is important to ensure a migration environment has been created between the two arrays. To do this refer to section Creating an NDM Environment with Unisphere for PowerMax.
Creating the migration session is done through the extended menu from the Storage Groups dashboard in Unisphere.
After clicking Migrate, the Create Migration wizard launches, presenting you with an opportunity to select the target array. In this instance, the user has selected array “000120200287”, a PowerMax 8500 array.
The UI automatically determines the underlying migration technology based on the arrays selected. In this case it uses Metro with Precopy. The wizard presents a review of the masking, giving the opportunity to make changes to the migration, with the final option to run the migration.
At this point data is copying between the two arrays just like a regular SRDF session, the devices are in adaptive copy mode ensuring no performance penalty is incurred on the source array during a potentially large data transfer. The following figure shows the SRDF Pair state of devices involved in the Migration Precopy,
Selecting the Data Protection tab on the left task bar and selecting Migrations in the drop-down menu, the storage groups currently involved in an NDM session are highlighted along with the current State and details on the source and target arrays. Since Pass-Through NDM Cutover operation.
From the expanded menu in this example, the precopy is now 100% completed.
Once an adequate amount of data has been copied to the target array to negate the potential impact on the application host the target array can be made ready to the host.
When the ready target operation begins the RDF relationship changes to Metro from adaptive copy and the masking view is created. Running a host rescan the extra paths will become available for host I/O use:
Once the ready target has been issued, we will move from a precopy state to a migrating state and eventually to a synchronized state.
At this point, the storage administrator runs a host rescan to allow the multipathing software to configure the new paths created as a result of the new masking configuration on the target array created by issuing the Ready Target command.
Select Storage Groups from the Data Protection tab and SRDF from the window to display the SRDF relationship. In this case, we are in ActiveBias as there is no witness between the arrays. From a system standpoint, we are now processing I/Os in a Metro active/active mode with our target array being read/write to the host also.
When the data copy is completed and the devices are synchronized, the migration can be committed. The Commit operation completes the migration by removing the migrated application resources from the source array and releases system resources used for the migration. Once the commit is completed the replication relationship between the source and target devices are removed, the masking view on the source is removed and the source devices take the native (internal) WWN of the target LUN as its effective (external) WWN.
Before issuing the commit, a quick search on Unipshere shows that the storage group PreCopy-Migrate-SG exists on both the source and target array.
Committing the Migration Session with Unisphere 10.1 and higher gives the user the option of selecting a cleanup action as shown in the following figure.
Once the commit is run, the cleanup operation also deletes the volumes and storage group on the source array.
The number of paths that will be available for host access following the commit depends on how many paths have been zoned to the ports in the port group on the target array.
Carrying out a Rescan operation on the host removes the dead paths to the original source array, retaining only the paths from the new array front end ports to the target devices.