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:
- Old secondary to new secondary storage system, used as temporary links for the migration.
- 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
-
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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- The Migration Session that is created in step
1 goes into a
Ready to Migrate state.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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:
- If already not suspend, suspend the existing source and target relationships by
using the management software that is managing the pairs.
- 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.
- 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.
- From the Session Actions list, select Commands and
issue the StartGC H1->H2 command to the Migration session to restart the replication.
- Wait until the Migration session is
resynchronized (a progress of 99% or greater), and then repeat the migration steps.
- 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.
- 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.
- From the Session Actions list, select Remove
Session to remove the Migration session
that is created in step 1.
- Click Yes to confirm that you want to remove the
Migration session that is created in step 1
- Repeat step 9 and step
10 to remove the empty, inactive
migrate_to_ session, and if needed remove migrate_from_ sessions.
- 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.