Independent relationships

Remote-copy relationships define the relationship between two volumes: a master volume and an auxiliary volume. HyperSwap relationships are created automatically when a HyperSwap volume is created in either the management GUI or the command-line interface on systems that support HyperSwap topology.

Typically, a volume contains the master copy of the data and is the volume that the application normally accesses. The auxiliary volume typically contains a backup copy of the data and is used for disaster recovery.

The master and auxiliary volumes are defined when the relationship is created, and these attributes never change. However, either volume can operate in the primary or secondary role as necessary. The primary volume contains a valid copy of the application data and receives updates from the host application, analogous to a source volume. The secondary volume receives a copy of any updates to the primary volume because these updates are all transmitted across the mirror link. Therefore, the secondary volume is analogous to a continuously updated target volume. When a relationship is created, the master volume is assigned the role of primary volume and the auxiliary volume is assigned the role of secondary volume. Therefore, the initial copying direction is from production to auxiliary. When the relationship is in a consistent state, you can reverse the copy direction.

Usually, the two volumes in a relationship must be the same size. However, in some cases, the volume size can be changed. For more information, see Expanding volumes. When the two volumes are in the same system, they must be in the same I/O group.

If change volumes are defined, they must be the same size and in the same I/O group as the associated master volume or auxiliary volume.

For ease of application management, a relationship can be added to a consistency group.

Note: Membership of a consistency group is an attribute of the relationship, not the consistency group. Use the chrcrelationship command to add a relationship to, or remove a relationship from, a consistency group.

Remote-copy types

The remote-copy function supports several types of remote-copy operations. Each of these remote-copy types provides copies between volumes and systems for migration, high availability, and disaster recovery.

The following remote-copy types are used to replicate data for high availability and disaster recovery uses cases. These remote-copy types are defined within remote-copy relationships. When you create a new remote-copy relationship, you specify the copy type and the production and auxiliary volumes within the relationship. If a remote-copy relationship is added to a consistency group, all additional relationships that are added need to have the same copy type. Depending on your system model, a Remote Mirroring license can be required to use these remote-copy types. The system supports the following remote-copy types for replication:

Metro Mirror

This remote-copy type creates a synchronous copy of data from a master volume to an auxiliary volume. An auxiliary volume can either be on the same system or on another system. Metro Mirror can be used between volumes that are separated by distances up to 300 km.

With synchronous copies, host applications write to the master volume but do not receive confirmation that the write operation completes until the data is written to the secondary volume. With synchronous copies, both the volumes have identical data when the copy operation completes. After the initial copy operation completes, the Metro Mirror copy type maintains a fully synchronized copy of the source data at the target site.

For disaster recovery purposes, Metro Mirror provides the simplest way to maintain an identical copy on both the primary and secondary volumes. However, like with all synchronous copies over remote distances, performance on host applications can be impacted. This performance impact is related to the distance between primary and secondary volumes and depending on application requirements, its use might be limited based on the distance between sites.

Global Mirror without cycling (cycling mode set to None)

The Global Mirror remote-copy type provides an asynchronous copy process. When a host writes to the primary volume, confirmation of I/O completion is received before the write operation completes for the copy on the secondary volume.

If a failover operation is initiated, the application must recover and apply any updates that were not committed to the auxiliary volume. If I/O operations on the primary volume are paused for a small length of time, the auxiliary volume can become an exact match of the primary volume. This function is comparable to a continuous backup process in which the last few updates are always missing. When you use Global Mirror for disaster recovery, you must consider how you want to handle these missing updates.

To use the Global Mirror function, all components in the network must sustain the workload that is generated by application hosts and the Global Mirror background copy process. If all of the components in the network cannot sustain the workload, the Global Mirror relationships are automatically stopped to protect your application hosts from increased response times.

When Global Mirror operates without cycling, write operations are applied to the auxiliary volume as soon as possible after they are applied to the primary volume. The auxiliary volume is generally less than 1 second behind the primary volume, which minimizes the amount of data that must be recovered if a failover occurs. However, a high-bandwidth link must be provisioned between the sites.

Global Mirror with change volumes (cycling mode set to Multiple)

Global Mirror with change volumes provides the same basic function of asynchronous copy operations between source and target volumes for disaster recovery. However, a separate volume is created to track changes and copy-on-write technology is used to maintain the consistent image of the primary volume for the background copy process to read.

If you are using Global Mirror with change volume, the copying process is similar to Metro Mirror and standard Global Mirror. Change volumes must be configured for both the primary and auxiliary volumes in each relationship. A copy is taken of the primary volume in the relationship that uses the change volume that is specified when the Global Mirror relationship with change volumes is created. The background copy process reads data from the stable and consistent change volume, copying the data to the auxiliary volume in the relationship. Copy-on-write technology is used to maintain the consistent image of the primary volume for the background copy process to read. The changes that took place while the background copy process was active are also tracked. The change volume for the auxiliary volume can also be used to maintain a consistent image of the auxiliary volume while the background copy process is active. Global Mirror with change volumes help eliminate the missing updates that can occur when you use Global Mirror without change volumes.

Change volumes can be used in a number of cases. Global Mirror relationships with cycling mode set to Multiple must always be configured with change volumes. Global Mirror relationship with cycling mode set to None can optionally be configured with change volumes, which can be used to maintain a consistent secondary image.

You can also use remote-copy function to migrate data from one system to another non-disruptively. You can create specific remote-copy relationship that copies data from source volumes on a system that you are decommissioning to auxiliary volumes that are located on another system. The following remote-copy type is available for migration:

Non-Disruptive System Migration: Select this option to migrate volume data between systems by creating a remote-copy relationship. Non-Disruptive System Migration does not require a Remote Mirroring license, but certain remote-copy functions are restricted, such as creating consistency groups. Before you can migrate data with Non-Disruptive System Migration, a partnership between both systems must be created. For more information, see Migrating data between systems non-disruptively.

Relationship states

When a Metro Mirror or Global Mirror relationship is created with two volumes in different systems, the distinction between the connected and disconnected states is important. These states apply to systems, the relationships, and the consistency groups.

To review the state of the relationships, you can use the management GUI or issue the lsrcrelationship command. The following relationship states are possible:

Table 1 describes the remote-copy consistency group states.

Table 1. Remote-copy relationship states
Management GUI icon	State	Description
	Inconsistent Stopped	The primary volumes are accessible for read and write I/O operations, but the secondary volumes are not accessible for either operation. A copy process must be started to make the secondary volumes consistent.
	Inconsistent copying	The primary volumes are accessible for read and write I/O operations, but the secondary volumes are not accessible for either operation. This state is entered when the relationship is started when the relationship is in the Inconsistent stopped state. This state is also entered when the relationship is started with the force option when the relationship is in either the Idling or Consistent stopped states.
	Consistent stopped	The secondary volumes contain a consistent image, but it might be out-of-date with the primary volume. This state can occur when a relationship was in the Consistent synchronized state and experiences an error that forces a freeze of the relationship. This state can occur while in the Consistent Synchronized or Consistent Copying state when the relationship is stopped. The state can also occur when a relationship between two volumes is created and the volumes are already synchronized.
	Consistent copying	The primary volumes are accessible for read and write I/O operations. The secondary volumes contain a consistent image, but it might be out of date with the primary volume. This state applies to consistency groups that contain relationships with multiple-cycling.
	Consistent synchronized	The primary volumes are accessible for read and write I/O operations. The secondary volumes are accessible for read-only I/O operations.
	Idling	The primary volumes and the secondary volumes are both operating in the primary role. The volumes are accessible for write I/O operations.
	Idling disconnected	The volumes in this half of the relationship are all operating in the primary role and can accept read or write I/O operations.
	Inconsistent disconnected	The volumes in this half of the relationship are all operating in the primary role and can accept read or write I/O operations.
	Consistent disconnected	The volumes in this half of the relationship are all operating in the secondary role and cannot accept read or write I/O operations.

Note: Volume copies are synchronized when their contents are consistent. If write operations take place on either the primary or secondary volume after a consistent (stopped) or idling state occurs, they might no longer be synchronized.

Volume status in relationships

The system also provides additional information about the status of the volume relationships. To view the status, issue the lsrcconsistgrp or lsrcrelationship command.

Online: All volumes in the relationship are online and accessible. If the state of the relationship is Consistent synchronized, Consistent copying, or Inconsistent copying, the volumes can replicate the host I/O write operations that are received on the primary volume.
Primary offline: The primary volume of the relationship is offline, which prevents additional host I/O operations. Synchronization is paused until the primary volume is online again.
Secondary offline: The secondary volume of the relationship is offline. For Global Mirror relationships without change volumes in Consistent Synchronized state and Metro Mirror relationships, more I/O write operations to the primary volume stop the relationship.
I/O channel offline: The remote system is not accessible. For regular Global Mirror relationships in Consistent synchronized state (that is, Global Mirror without change volumes) and Metro Mirror relationships, more I/O write operations to the primary volume stop the relationship.
Primary change offline: The primary change volume of the relationship is offline. For Global Mirror with change volumes relationships, the current I/O cycle ends; a new I/O cycle begins when the primary change volume goes online again.
Secondary change offline: The secondary change volume of the relationship is offline. For Global Mirror with change volumes relationships, the current I/O cycle is paused; when the secondary change volume goes online again, the I/O cycle resumes.
Change volumes needed: For Global Mirror with change volumes relationships, at least one change volume is not yet configured. In this status, replication is prevented.