Planning replication for disaster recovery

Before implementing replication for disaster recovery, you must determine your recovery point objectives, application requirements, and consider the connectivity available between locations.

To implement replication for disaster recovery, consider the following:
  • Determine the round-trip time (RTT) between the systems. As the RTT increases, the maximum throughput decreases.
  • Determine the change rate of data for applications storing data on the system. Environments with high change rates and low bandwidth may be unable to achieve low RPOs.
  • The use of replication protects data from a large-scale disaster on the site or storage systems. Consider using safeguarded snapshots in addition to replication to also provide protection against data corruption and cyber attacks.

Replication for disaster recovery requires a partnership to be configured between the systems. Partnerships for asynchronous replication can use any of the supported connectivity types. Partnerships can be configured with up to three other systems for disaster recovery.

IP connectivity is required between systems for management. Use of Network Address Translation (NAT) between systems is not supported. The following TCP ports are required to be accessible on the system management IP address:
  • Ports 6443, 7443, and 443 for REST API and GUI access between systems on the default management IP addresses.
  • Replication setup using the management GUI requires access to both systems from the host where the web browser is running. Ensure that any firewalls between the web browser and storage systems allow inbound traffic to port 443 on the system management IP address.
  • Additionally, IP replication requires inbound and outbound access using port 3260 on the system management IP and port 3265 on the IP addresses for the data path connections.

Policy-based replication for disaster recovery can be used with all host operating systems that are compatible with IBM Storage Virtualize systems.

For more information about host compatibility, see IBM System Storage Interoperation Center (SSIC).

For the best performance, configure the host multipath drivers to use SCSI ALUA or NVMe ANA.

With policy-based replication, you can replicate thin-clones and FlashCopy target volumes to the recovery system.
  • Snapshots cannot be replicated directly. Thin-clones can be refreshed from snapshots and the deltas are copied automatically to the recovery system.
  • FlashCopy maps cannot be started if the FlashCopy target volume is replicated.
The following restrictions apply to policy-based replication for disaster recovery:
  • The name of a volume group, and names of volumes in the volume group can be changed only if all systems are running IBM Storage Virtualize 9.1.0 or later. You can rename an object on the production system only and the changed object name applies to all copies.
  • Policy-based replication cannot be used with volumes that are configured to use Transparent Cloud Tiering (TCT).
  • Image mode volumes with cache disabled can be replicated to import data from external storage. Cache must be enabled after the replica is established. After cache is enabled in read/write mode, it cannot be disabled.
  • A volume in a volume group with a replication policy assigned cannot be:
    • Shrunk. Volume expansion is supported if all systems are running IBM Storage Virtualize 9.1.0 or later.
    • Migrated to image mode, or have an image mode copy added.
    • Moved to a different I/O group.
  • All volumes in a volume group must be in the same I/O group.
  • A volume can be moved between volume groups if the current group and the new group are not both configured with replication for disaster recovery, and if all systems are running IBM Storage Virtualize 9.1.0 or later.