Partnership migration

You can migrate existing remote copy partnerships and relationships when you change the type of connections between the two systems.

It is possible to migrate existing remote copy relationships and partnerships from Fibre Channel to native IP, from native IP to Fibre Channel, from IPv4 to IPv6 deployments, and from one Ethernet speed link to a different Ethernet speed link.

Migrate the existing remote-copy relationships and partnerships from Fibre Channel to native IP

Complete the following procedure:

If the two systems are in Fibre Channel partnerships on pre-7.2.0 code, update both systems by using your defined update schedule.
If the two systems are in Fibre Channel partnerships, and the control enclosures are using pre-7.2.0 code, update both systems by using your defined update schedule so all components in the two systems are at the same code level.
After both systems are on 7.2.0 or later code, complete the following steps:
1. Schedule a downtime and stop host I/O while relationships are still active.
  Note: To ensure that all cached data on the host is flushed to the volumes, make sure that any file systems that are mounted on replicated Fibre Channel volumes are unmounted first. This process must be done for all Fibre Channel relationships. It must be done on all hosts if the same volume is used by multiple hosts (for example, using clustered file systems like VMFS). If you are using other applications, you must ensure that you synchronize all cached data from application to disk. The procedure might be application-specific as well. For example, Oracle, DB2, and so on might need to be stopped, while for some applications you might need to run synchronization on the host.
2. If there are Global Mirror change volumes (remote-copy relationships), complete the following steps. If not, go to the next step.
  1. Stop the relationship and change to noncycling Global Mirror.
  2. Start the relationship.
    Note: Make sure the relationship changes to consistent_synchronized (or else wait until the relationship's state is consistent_synchronized).
3. Stop the relationships without -access flag and verify that the status for each relationship is in_sync.
4. Delete the remote-copy relationships.
5. After all remote-copy relationships are deleted, stop and delete the partnerships from both systems.
6. Remove/delete the zoning between the two sites so that the two systems are not listed as available systems when you run lspartnershipcandidate.
7. Configure the IP ports by using cfgportip and establish IP Partnerships. Additionally, configure CHAP if required.
8. Create the remote-copy relationships with the -sync flag for Metro Mirror, Global Mirror, or Global Mirror change volumes with the original master and auxiliary volumes (previously used in the Fibre Channel partnerships) on respective sites.
9. Add the change volumes to the respective relationships.
10. Start the remote-copy relationships.

This completes the migration of remote-copy relationships from Fibre Channel to native IP.

Migrate the existing remote-copy relationships and partnerships from native IP to Fibre Channel

This procedure applies to two systems that are in IP partnership on 7.2.0 or later code.

Complete the following procedure:

Schedule a downtime and stop host I/O while relationships are still active.
Note: Ensure that any file systems that are mounted on replicated Fibre Channel volumes are unmounted first so that all cached data on the host is flushed to the volumes. This must be done for all Fibre Channel relationships. It must be done on all hosts if the same volume is used by multiple hosts (example: using clustered file systems like VMFS). If you are using other applications, you must ensure that you sync all cached data from application to disk. The procedure might be application-specific as well. For example, Oracle, DB2, and so on might need to be stopped, while for some applications, you might need to run synchronization on the host.
If there are Global Mirror change volumes (remote-copy relationships), complete the following steps. If not, go to the next step.
1. Stop the relationship and change to noncycling Global Mirror.
2. Start the relationship.
  Note: Make sure the relationship changes to consistent_synchronized (or else wait until the relationship's state is consistent_synchronized).
Stop the relationships without the -access flag and verify that the status for each relationship is in_sync.
Delete the remote-copy relationships.
After all remote-copy relationships are deleted, stop and delete the partnerships from both systems.
Unconfigure the ports in the remote copy port groups (set them to 0) on both systems.
Create the zones between the two sites so that the two systems are listed as available systems when you run lspartnershipcandidate and lsfabric.
Create the remote-copy relationships with the -sync flag for Metro Mirror, Global Mirror, or Global Mirror change volumes with the original master and auxiliary volumes (previously used in the IP partnerships) on respective sites.
Add the change volumes to the respective relationships.
Start the remote-copy relationships.

This procedure completes the migration of remote-copy relationships from native IP to Fibre Channel.

Migrate the existing remote-copy relationships and partnerships from IPv4 to IPv6 deployments

To migrate from IPv4 to IPv6, the following requirements must be met:

System IPs have IPv6 addresses configured
Datapath IPs (IPs configured by using cfgportip) have IPv6 addresses
Note: You can assign IPv6 addresses to ports while IP partnerships are active. However, you cannot add them to remote-copy port groups.

This procedure applies to two systems that are in IP partnership over IPv4 on 7.2.0 or later code.

Complete the following procedure:

Stop the relationships without the -access flag and verify that the status for each relationship is in_sync.
After all remote-copy relationships are stopped, stop the IP partnership on both systems.
1. On system C1: #svctask chpartnership-stop <systemid C2>
  - The command lspartnership reports as fully_configured_stopped on system C1.
  - The command lspartnership reports as fully_configured_remote_stopped on system C2.
2. On system C2 :#svctask chpartnership-stop <systemid C1>
  - The command lspartnership reports as fully_configured_stopped on system C1.
  - The command lspartnership also reports as fully_configured_stopped on system C2.
Add the IPv6 IP addresses, which are configured on Datapath IP Ports (by using cfgportip), in respective remote copy port groups.
- On system C1: #svctask cfgportip-node <node_id> -remotecopy_6 <portgrp_id_1_or_2> <port_no>
- On system C2: #svctask cfgportip-node <node_id> -remotecopy_6 <portgrp_id_1_or_2> <port_no>
Note: This step causes your remote-copy status to be listed as unused from used since discovery for the new paths on new IP addresses has not yet happened.
Modify the IP partnerships to do discovery over IPv6 addresses.
- On system C1: #svctask chpartnership-type ipv6-clusterip <ipv6_ipaddr_of_cluster_c2> <systemid C2>
- On system C2: #svctask chpartnership-type ipv6-clusterip <ipv6_ipaddr_of_cluster_c1> <systemid C1>
- On system C1: #svctask chpartnership-start <systemid C2>
- On system C2: #svctask chpartnership-start <systemid C1>
  Note: Since new data paths over IPv6 addresses are now available, partnership will first change to not_present, and then to fully_configured. If it remains in not_present, monitor the node error/DMP if it is getting triggered and check the appropriate DMP in the troubleshooting section.
Start the remote-copy relationships.

This procedure completes the migration of remote-copy relationships from IPv4 to IPv6. This same procedure can be applied when you migrate from IPv6 to IPv4 by applying suitable substitutes for IPv4 instead of IPv6.

Migrate the existing remote-copy relationships and partnerships to new IP addresses

When you change one or both system and datapath IP addresses of the system, replication needs to be temporarily stopped during the procedure. However, host I/O can continue. After the procedure is complete, the relationships need to resynchronize only the host write operations that are submitted during the procedure.

This procedure applies to two systems that are in an IP partnership on version 7.2.0 or later code.

Complete the following procedure:

Stop the IP partnership on both systems.
1. On system C1: #svctask chpartnership-stop <systemid C2>
  - The command lspartnership reports as fully_configured_stopped on system C1.
  - The command lspartnership reports as fully_configured_remote_stopped on system C2.
2. On system C2: #svctask chpartnership-stop <systemid C1>
  - The command lspartnership reports as fully_configured_stopped on system C1.
  - The command lspartnership also reports as fully_configured_stopped on system C2.
Reconfigure the IP addresses on one or both systems by using the following commands:
chsystemip-clusterip <new ip> -port <ethernet port number>

cfgportip-node <node id> -ip <new ip address> -netmask <new netmask> -gw <new gateway>
For each reconfigured system IP, reconfigure the partnership on the remote system:
If system IP changed on system C1, then on system C2: #svctask chpartnership-clusterip <system IP of system C1> <systemid C1>

If system IP changed on system C2, then on system C1: #svctask chpartnership-clusterip <system IP of system C2> <systemid C2>
Restart the partnerships:
On system C1: #svctask chpartnership-start <systemid C2>

On system C2: #svctask chpartnership-start <systemid C1>
Restart any stopped relationships.

Migrate the existing remote-copy relationships and partnerships from 1 Gbps links to 10 Gbps links (vice versa)

Before you attempt to migrate existing deployments from 1 Gbps links to 10 Gbps links, refer to the limitations and considerations requirements in the IP partnership configuration topic.

Note: You cannot mix link speeds. For example, if there are two links, both links should either be 10 Gbps links or both should be 1 Gbps links.

This procedure applies to two systems that are in IP partnership with each other over two 1 Gbps links on 7.2.0 or later code.

Complete the following procedure:

Stop the relationships without the -access flag and verify that the status for each relationship is in_sync.
After all remote-copy relationships are stopped, stop the IP partnership on both systems.
1. On system C1: #svctask chpartnership-stop <systemid C2>
  - The command lspartnership reports as fully_configured_stopped on system C1.
  - The command lspartnership reports as fully_configured_remote_stopped on system C2.
2. On system C2 :#svctask chpartnership-stop <systemid C1>
  - The command lspartnership reports as fully_configured_stopped on system C1.
  - The command lspartnership also reports as fully_configured_stopped on system C2.
Add the IP addresses, which are configured on Datapath IP Ports (by using cfgportip), on 10 Gbps links in respective remote copy port groups.
- On system C1: #svctask cfgportip-node <node_id> -remotecopy <portgrp_id_1_or_2> <port_no_3/port_no_4>
- Remove the existing the 1 Gbps ports from the remote-copy group by using the following command:
  #svctask cfgportip-node <node_id> -remotecopy 0 <port_no_1/port_no_2>
- On system C2: #svctask cfgportip-node <node_id> -remotecopy <portgrp_id> <port_no_3/port_no_4>
- Remove the existing the 1 Gbps ports from the remote-copy group by using the following command:
  #svctask cfgportip-node <node_id> -remotecopy 0 <port_no_1/port_no_2>
Note: This step causes your remote-copy status to be listed as unused from used since discovery for the new paths on new IP addresses has not yet happened.
Start the IP partnerships.
- On system C1: #svctask chpartnership-start <systemid C2>
- On system C2: #svctask chpartnership-start <systemid C1>
  Note: Since new data paths over IPv6 addresses are now available, partnership will first change to not_present, and then to fully_configured. If it remains in not_present, monitor the node error/DMP if it is getting triggered and check the appropriate DMP in the troubleshooting section.
Start the remote-copy relationships.

This procedure completes the migration from 1 Gbps links to 10 Gbps links. This same procedure can be applied to migrate from 10 Gbps to 1 Gbps by applying suitable substitutes for 1 Gbps ports instead of 10 Gbps ports.