Migrating a secondary storage system to a newer DS8000

You can migrate a secondary storage system to a newer storage system in several ways, including the use of an external application. Use the information in this topic to migrate a secondary storage system to a newer DS8000® by using DS8000 copy services. You do not require a Copy Services Manager license as the migration can be done by using the preinstalled version of Copy Services Manager.

About this task

The following steps are used to migrate a secondary storage system to a newer DS8000 storage system. Migration works whether Copy Services Manager, DSCLI, or GDPS is managing the relationships.

The information in this topic can be used to migrate Global Copy, Metro Mirror, and Global Mirror targets, including when the relationship is a multi-target relationship. The information in this topic is not supported for cascaded Metro Global Mirror solution. You can convert the cascaded solution into a multi-target solution by using Copy Services Manager to use the following procedure to migrate the secondary volumes.

Note: This feature uses the Copy Services Manager Migration session type and can be used on the preinstalled version of Copy Services Manager on the DS8000 HMC, without the need for a Copy Services Manager license.
You need to complete the following steps before you start the migration.
  • All the old and the new storage systems must be added to the Copy Services Manager server that performs the migration. For more information, see Adding a storage connection.
  • All the target volumes must be created on the new storage system, otherwise the volumes cannot be added to the migration session. The target volumes must have identical size as the source volumes. While identical size is not enforced by the Migration session, the final replication topology requires all the volumes to have identical sizes.
  • Fibre Channel Protocol (FCP) links need to be configured for the copy services migration:
    1. Old secondary to new secondary storage system, used as temporary links for the migration.
    2. Primary to new secondary storage system, used as permanent new links during and after migration.
  • PPRC paths must be established for the migration. Copy Services Manager can do that automatically, but it uses only one path on one of the links per logical subsystem pair. To use more and dedicated FCP link port pairs for the PPRC path, update the DS8000 Port Pairing CSV file with both the temporary and new permanent PPRC link port pairs. For more information, see Adding logical paths by using a CSV file.
  • Validate that the new links can be used to establish PPRC paths. For more information, see Viewing logical paths. Establish logical path across all the new PPRC links for at least one logical subsystem pair each. If required, the remaining paths are automatically established by Copy Services Manager by using the DS8000 Port Pairing definitions.

Procedure

  1. Create a Migration session with the H1 volumes same as the targets for an existing Global Copy/Metro Mirror relationship that is managed by Copy Services Manager or GDPS. For more information about how to create a Migration session, see Creating a Migration session and adding copy sets.
  2. From the Session Actions list, select Commands and issue the StartGC H1->H2 command. This command creates a cascaded relationship from the existing Global Copy/Metro Mirror targets to the new set of target volumes on the new secondary storage system.
  3. Optional: From the Session Actions list, select Commands and issue the Validate for Secondary Migration command after you set up the Migration session and before starting the migration.
    • This step is highly recommended to validate that all the H1 volumes in the Migration session that is created in step 1 are targets to existing Global Copy/Metro Mirror relationships. The relationships must be in an active state and not in a suspended or failed over state.
    • After you issue this command, Copy Services Manager will query the hardware to determine whether all the H1 volumes in the Migration session are targets of a Global Copy/Metro Mirror relationship on the hardware. If any of the H1 volumes are not active targets, the command fails and the session remains in the same state. If the command fails, determine which H1 volumes are not active targets, and remove them from the session or add additional copy sets to the session and retry the command.
  4. When you are ready to perform the migration and more than 99% of the data has been copied to the new cascaded secondary volumes, from the Session Actions list, select Commands and issue the Prepare for Secondary Migration command. Internally the command performs the following actions:
    1. The session again queries the hardware to ensure that all the H1 volumes are targets of an existing Global Copy/Metro Mirror relationship as it did when the Validate for Secondary Migration command was issued. If any error is detected, the command fails and the session remains in the same state.
    2. If all the existing Global Copy/Metro Mirror pairs are not managed by an active Copy Services Manager session on the same server, a new Copy Services Manager Migration session is created to manage the existing pairs. The new session is named as migrate_from_<migration session name>, where <migration session name> is the name of the Migration session that is created in step 1. If a Copy Services Manager session is managing the existing Global Copy/Metro Mirror pairs on the same server, then that session is internally associated to the Migration session created in step 1.
    3. A new Migration session is automatically created and copy sets are added with the H1 volumes as sources of the existing discovered pairs and the H2 volumes as the H2 volumes in the Migration session created in step 1. The new session is named as migrate_to_<migration session name>, where the <migration session name> is either the Copy Services Manager session name that is managing the existing pairs or the session name that is prefixed by migrate_from_ that was created to manage the existing pairs. This new Migration session is internally associated to the Migration session created in step 1.
    4. The source to old target volume relationship is reestablished to prepare for an incremental resynchronization from the source to the new target volumes by tracking changes on the source volume.
      Note: This reestablish operation does not involve any extra data copy on the existing pairs.
    5. The Migration Session that is created in step 1 goes into a Ready to Migrate state.
  5. If the existing relationships are Metro Mirror pairs with HyperSwap® enabled, you must disable HyperSwap before proceeding with the following steps. In addition, before performing the migration to the new secondary volumes, you can consistently suspend the existing source to target relationships by using either Copy Services Manager or the management software that is managing the relationships. A consistent suspend is not necessary to perform the migration, but it is recommended so that:
    • If an issue occurs during the migration, then current target volumes have a consistent copy of the data.
    • To prevent undesired freeze impacts during the next migrations steps if the existing pairs are Metro Mirror pairs that are managed by either another Copy Services Manager or GDPS. If the existing Metro Mirror pairs are managed with a freeze and Stop policy, make sure to Release I/O to prevent the production source volumes from being impacted by Extended Long Busy or SCSI Queue Full conditions.
  6. When the session is in the Ready to Migrate state, from the Session Actions list, select Commands and issue the Migrate Secondary command on the Migration session that is created in step 1. Internally the command performs the following actions:
    1. If the existing Global Copy/Metro Mirror relationships are not suspended by step 5, then the relationships are suspended.
      Important: This can trigger freeze events if the active Metro Mirror pairs are managed by another Copy Services Manager, GDPS, or HyperSwap solution.
    2. Once the Migration session determines that the progress is 100% synchronized indicating that all the data is drained to the new cascaded target volumes, all the pairs in the Migration session are suspended followed by a failover.
    3. An incremental resynchronization establish is issued from the sources to the new targets. The pairs are managed by migrate_to_ session and are running in Global Copy mode. The migrate_to_ session remains in a Preparing state that is indicated by a yellow Warning state.
      Note: When an incremental resynchronization establish is complete, the relationships from the sources to the old target volumes no longer exist on the hardware. If the old pairs were managed by another Copy Services Manager or GDPS solution, the solution might report that the original pairs were deleted unexpectedly. This is not an issue as the source volumes are now replicating to the new targets that are not yet configured in the existing solution.
    4. The Migration session that is created in step 1 goes into a Target Available and Severe state.
      Note: The Migration session is in a Severe state because the pairs were not suspended on the session using a hardware freeze command. This is not an issue as the targets are now targets of a new relationship.
    5. Handling errors during Migrate Secondary command: If errors occur during the Migrate Secondary command, and if the session remains in the Ready to Migrate state, then the issue can be resolved and the Migrate Secondary command can be reissued.
      Trouble: If resolving the issue takes time, perform the following steps before performing the migration:
      1. If already not suspend, suspend the existing source and target relationships by using the management software that is managing the pairs.
      2. Reestablish the existing source and target relationships by using the management software that is managing the pairs.
        Note: The steps 6.e.i and 6.e.ii are necessary to reset the change recording to prevent the new establish from having to replicate more data.
      3. From the Session Actions list, select Commands and issue the Stop command to the Migration session. This causes the session to go into a Suspended state and removes the migrate_to_ session to restart the migration process.
      4. From the Session Actions list, select Commands and issue the StartGC H1->H2 command to the Migration session to restart the replication.
      5. Wait until the Migration session is resynchronized (a progress of 99% or greater), and then repeat the migration steps.
  7. The migration is now complete and the new relationships need to be set up in the existing management solution. You can manage the copy sets as follows:
    • If migrated pairs are managed by GDPS, you can remove the copy sets from the migrate_to_ and migrate_from_ sessions and choose to keep the base relationship on the hardware. For more information, see Removing copy sets. Then, update the GDPS configuration so that it can start managing the new Global Copy pairs and convert them into the Metro Mirror or Global Mirror mode.
    • If migrated pairs are managed by Copy Services Manager, you can export the copy sets and import into the correct session type to manage or clean up the original session. For more information, see Exporting copy set data and Importing copy set data. After the export and import of copy sets is completed, you can remove the copy sets from the migrate_to_ and migrate_from_ sessions and choose to keep the base relationship on the hardware. For more information, see Removing copy sets. Finally, start the new or updated session to assimilate the existing Global Copy pairs and convert them into the Metro Mirror or Global Mirror mode.
    • If HyperSwap was originally enabled on the old pairs, it can now be enabled on the new pairs after the pairs are converted into Metro Mirror Full Duplex state.
  8. After the migration is completed, from the Session Actions list, select Commands and issue the Terminate command to the Migration session that is created in step 1 to clean up the relationships.
  9. From the Session Actions list, select Remove Session to remove the Migration session that is created in step 1.
  10. Click Yes to confirm that you want to remove the Migration session that is created in step 1
  11. Repeat step 9 and step 10 to remove the empty, inactive migrate_to_ session, and if needed remove migrate_from_ sessions.
  12. Optional: After the migration, if the old PPRC paths from or to the old secondary storage system are no longer needed, you can remove them. For more information, see Removing logical paths.