Migrating data between systems non-disruptively
Both the management GUI and command-line interface support migrating volume data between systems non-disruptively. The non-disruptive system migration is a remote-copy relationship type that is dedicated to volume migration between systems.
With non-disruptive system migration, storage administrators can migrate volumes from one IBM Storage Virtualize system to another without any application downtime. This function supports a number of use cases. For example, you can use this function to balance the load between multiple systems or to update and decommission hardware. You can also migrate data between node-based systems and enclosure-based systems. Unlike replication remote-copy types, non-disruptive system migration does not require a Remote Mirroring license before you can configure a remote-copy relationship that is used for migration.
- Stop-with-access is prohibited. The volumes cannot act independently if they are using the same UUID.
- Migration relationships cannot be added to a consistency group.
- You cannot change the relationship to another type of remote-copy relationship.
- Migration relationship cannot be converted into a 3-site relationship.
- Associating change volumes to a migration relationship is prohibited.
- Volumes in migration relationships cannot be resized until the migration is completed or canceled.
- ODX must be disabled on both systems while migrating volumes.
Note: If ODX is disabled, it cannot be re-enabled on the 8.4.2 software. Currently ODX support is not available on 8.4.2.
- Migration of volumes that are mapped to NVMe-attached hosts is not supported.
- Migration of SAN-boot volumes is not supported.
Prerequisites
- Ensure that both systems are running 8.4.2 or later.
- Create either a Fibre Channel or IP partnership between the two systems that you want to migrate volumes between. The maximum supported round-trip time (RTT) between the two systems is 3 milliseconds. Ensure that the partnership has sufficient bandwidth to support the write throughput for all the volume you are migrating. For more information, see mkfcpartnership command for creating Fibre Channel partnerships and mkippartnership command for creating IP partnerships.
- Ensure any hosts that are mapped to volumes that you are migrating are correctly zoned to both systems. Hosts must appear in an online state on both systems. The system supports the following hosts and connection types for non-disruptive system migration:
Supported hosts | Connection types |
---|---|
VMware ESXi 6.x | iSCSI and Fibre Channel |
VMware ESXi 7.x | iSCSI, iSER, and Fibre Channel |
RHEL 7.x, RHEL 8.x | iSCSI and Fibre Channel |
SLES 12.x, SLES 15.x | iSCSI and Fibre Channel |
Solaris 10, Solaris 11 | Fibre Channel |
HP-UX 11iV3 | Fibre Channel |
AIX 7.3 TL1 or later | iSCSI and Fibre Channel |
Using the management GUI
- On the source system, select
Volumes page, identify the volumes that you want to migrate and record of the
volume name and capacity. Note: If applicable, verify the storage tier that is being used to ensure that an appropriate tier is used at the target system.
. On the
- On the target system, select Create Volume. Create the target volume within the appropriate storage tier with the same capacity as the source volume. and select
- To get option, you have to enable it by following .
- On the source system, select .
- Select Independent Relationship.
- Select Create Relationship.
- On the Create Relationship page, select Non-disruptive System Migration.
- Ensure that the auxiliary volume location specifies the system that you want to migrate to, select Next.
- Select the Master and Auxiliary volumes to use in
the relationship.Note: Ensure that both the master and auxiliary volumes have the same capacity.
- Select Yes to start the copy. Click Finish.
- In the management GUI, select Consistent Synchronized state. Attention: Do not proceed until the relationship is in the Consistent Synchronized state.
. Verify that the migration relationship that you created
displays the
- Create host mappings to the auxiliary volumes on the remote system. Ensure that all auxiliary volumes are mapped to the same hosts that were previously mapped to the master volumes on the older system.
- Ensure that the HBAs in all hosts that are mapped to the volume are rescanned to ensure that all
new paths are detected to the auxiliary volumes. Record the current path states on any connected
hosts. Identify the WWPNs used for the active and standby (ghost) paths.Attention: Do not proceed if the additional standby paths are not visible on the host. Standby paths might be listed under a different name on the host, such as "ghost" paths. Data access can be impacted if all standby paths are not visible to the hosts when the direction is switched on the relationship.
- In the management GUI, select Switch Direction. This action reverses the copy direction of the relationship and switches the active and standby paths, which result in all host I/O being directed to the new volume. . Right-click the migration relationship and select
- Validate that all hosts are using the new paths to the volume by verifying that the paths previously reporting as standby (or ghost) are now reporting active. Verify that all previously active paths are now reporting standby (or ghost).
- Validate that all hosts are using the target volume for I/O and verify that no issues exist.
- On the original source system that was used in the migration, select the Unmap Volumes. Verify the number of volumes that are being unmapped and select Unmap. . Right-click the hosts and select
- On the original source system, select Delete. Verify the number of volumes that are being deleted and select Continue. . Right-click the volumes and select
- The volume migration process is complete.
Using the command-line interface (CLI)
- On the source system, enter the following command to determine all the volumes that you want to
migrate to the target system:
In the results, record the name, ID, and capacity for each volume that you want to migrate to the target system.lsvdisk
- On the target system, create volumes for each volume that you want to migrate, ensuring that you
create the volume with the same capacity as the source volume. For
example:
mkvolume -pool 0 -size 1000 -unit gb
- On the source system, enter the following command to create a relationship for
migration:
where sourcevolume is the name or ID of the master volume on the source system and targetvolume is the name or ID of the auxiliary volume that you created on the target system. The -migration flag indicates that the remote copy relationship can only be used to migrate data between the two systems defined in the partnership. Optionally you can specify a name with the -name parameter. In this example, migrationrc is the name of the relationship. If no name is specified, an identifier is assigned to the relationship.mkrcrelationship -master sourcevolume -aux targetvolume -cluster system2 -migration -name migrationrc
- On the source system, start the relationship by entering the following
command:
where migrationrc is the name of the relationship.startrcrelationship migrationrc
Note: The -clean flag cannot be used on migration relationships. - Verify that the state of the relationship is consistent_synchronized, by
entering the following command:
where migrationrc is the name of the relationship. In the results that display, ensure that the state is consistent_synchronized.lsrcrelationship migrationrc
Attention: Do not proceed until the relationship is in the consistent_synchronized state. Depending on the amount of data that is being migrated, the process can take some time. - After the relationship is in the consistent_synchronized state, create host
mappings to the auxiliary volumes on the target system by entering the following
command:
where targetvolume is the name of the auxiliary volume on the target system. Ensure that all auxiliary volumes are mapped to the same hosts that were previously mapped to the master volumes on the source system.mkvdiskhostmap -host host1 targetvolume
- On all hosts, ensure that the HBAs are mapped to the volume are rescanned to ensure that all new
paths are detected to the auxiliary volumes. Record the current path states on any connected hosts.
Identify the WWPNs used for the active and standby (ghost) paths.Attention: Do not proceed if the additional standby paths are not visible on the host. Standby paths might be listed under a different name on the host, such as "ghost" paths. Data access can be impacted if all standby paths are not visible to the hosts when the direction is switched on the relationship.
- Switch the direction of the relationship so the auxiliary volume on the target system becomes
the primary source for host I/O operations be entering the following
command:
where migrationrc indicates the name of the relationship. This command reverses the copy direction of the relationship and switches the active and standby paths, which result in all host I/O being directed to the auxiliary volume.switchrcrelationship -primary aux migrationrc
- Validate that all hosts are using the new paths to the volume by verifying that the paths previously reporting as standby (or ghost) are now reporting active. Verify that all previously active paths are now reporting standby (or ghost).
- Validate that all hosts are using the target volume for I/O and verify there are no issues.
- On the original source system, unmap hosts from the original volumes by entering this
command:
where sourcevolume is the name of the original volume that was migrated.rmvdiskhostmap -host host1 sourcevolume
- On the original source system, delete the original source volumes by entering the following
command.
where sourcevolume is the name of the original volume that was migrated.rmvolume sourcevolume
- The migration process is complete.