Migrating replication for disaster recovery to use partitions

Existing configurations that use replication for disaster recovery without storage partitions can be migrated into a storage partition by using the CLI. This allows an existing 2-site DR configuration to be extended to a 3-site HA+DR configuration while continuing to support disaster recovery operations and without requiring resynchronization of the recovery copy.

This procedure requires all the volume groups that are to be migrated to the same partition to replicate in the same direction.

Using the command-line interface

  1. On each system:
    1. Use mkpartition -draft -name <partition_name> to create a new draft partition.
      Note: If appropriate for your environment, consider naming the partitions differently to allow easier identification of which partition is typically used for disaster recovery during normal running.
    2. Use chvolumegroup -draftpartition <partition> <volumegroup> to move the volume groups to be migrated into the new draft partition.
      Note: Moving an object into a draft partition may automatically add associated objects to the partition too. Review the complete set of objects in the draft partition before you publish it.
    3. Publish the partition by using: chpartition -publish <partition>
  2. On the system with the recovery volume groups:
    1. Identify the uuid value of the partition that will be used for recovery by using: lspartition <recovery_partition>
  3. On the system with the production volume groups:
    1. Configure a link for disaster recovery between the partitions by using: chpartition -makedrlink -remotedrlinkedpartitionuuid <recovery_partition_uuid> -remotesystem <recovery_system_id/name> <production_partition_id/name>
      Note: The remote partition being linked to must contain all of the associated remote volume groups for all disaster recovery volume groups in the local partition.
    2. For each 2-site-async-dr policy that needs to be replaced, create and assign a new replication policy with topology ‘async-dr’ in the partition:
      1. Use the lsvolumegroupreplication command to identify the current replication policy assigned to each volume group to be migrated.
      2. Use the lsreplicationpolicy command to identify the RPO alert value for each policy.
      3. Create the new replication policy by using: mkreplicationpolicy -name <name> -topology async-dr -partition <production_partition_id/name> -rpoalert <rpoalert>
      4. Assign the appropriate new replication policy to each volume group by using: chvolumegroup -replicationpolicy <policy> <volumegroup>
      5. Optionally, any unused 2-site-async-dr policies can now be removed by using: rmreplicationpolicy <policy>

After the CLI procedure above has been completed, further management and monitoring can be performed using the GUI, the CLI, or the REST API.