A more significant use arises when the relationships contain volumes with a tight association. A simple example of a tight association is the spread of data for an application across more than one volume. A more complex example is when multiple applications run on different host systems. Each application has data on different volumes, and these applications exchange data with each other. In both examples, specific rules exist as to how the relationships can be updated. These rules ensure that the set of secondary volumes contain usable data. The key property is that these relationships are consistent. Consistency groups help provided that consistent copies are created for all these uses.
Relationships that are not part of a consistency group are called stand-alone relationships. A consistency group can contain zero or more relationships. All relationships in a consistency group must have matching primary (master) and secondary (auxiliary) systems or sites. All relationships in a consistency group must also have the same copy direction and state.
HyperSwap,Metro Mirror or Global Mirror relationships cannot belong to the same consistency group. A copy type is automatically assigned to a consistency group when the first relationship is added to the consistency group. After the consistency group is assigned a copy type, only relationships of that copy type can be added to the consistency group. Global Mirror relationships with different cycling modes cannot belong to the same consistency group.
- Active-active
- This type of relationship is only created for HyperSwap volumes. When HyperSwap is configured on the system, the HyperSwap volumes are located on separate sites and an active-active relationship is automatically configured between them. Updates to the volumes in the relationship are updated simultaneously on both sites to provide disaster recovery solutions for the system.
- Metro Mirror
Metro Mirror is a type of remote copy that creates a synchronous copy of data from a primary volume to a secondary volume. A secondary volume can either be on the same system or on another system.
With synchronous copies, host applications write to the primary volume but do not receive confirmation that the write operation has completed until the data is written to the secondary volume. This ensures that both the volumes have identical data when the copy operation completes. After the initial copy operation completes, the Metro Mirror function maintains a fully synchronized copy of the source data at the target site at all times.
The Metro Mirror function supports copy operations between volumes that are separated by distances up to 300 km. 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, there can be a performance impact to host applications. 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 function 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 secondary volume. If I/O operations on the primary volume are paused for a small length of time, the secondary 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 be capable of sustaining 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 secondary volume as soon as possible after they are applied to the primary volume. The secondary 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 two sites.
- Global Mirror with change volumes (cycling mode set to Multiple)
- Global Mirror with change volumes (cycling mode set to Multiple) provides the same basic function of asynchronous copy operations
between source and target volumes for disaster recovery.
If you are using Global Mirror with cycling mode set to Multiple, the copying process is similar to Metro Mirror and standard Global Mirror. Change volumes must be configured for both the primary and secondary volumes in each relationship. A copy is taken of the primary volume in the relationship using 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 secondary 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 secondary volume can also be used to maintain a consistent image of the secondary volume while the background copy process is active.
Metro Mirror and Global Mirror consistency group states
| Management GUI icon1 | 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 after the startrcconsistgrp command is issued to a consistency group in the InconsistentStopped state. This state is also entered when the startrcconsistgrp command is issued, with the force option, to a consistency group in the Idling or ConsistentStopped state. |
  |
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 ConsistentSynchronized state and experiences an error that forces a freeze of the consistency group. This state can occur while in the ConsistentSynchronized or ConsistentCopying state following a stoprcconsistgrp command. 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 Global Mirror 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 consistency group 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 consistency group 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 consistency group are all operating in the secondary role and cannot accept read or write I/O operations. |
|
Empty | The consistency group does not contain any relationships. |
 |
(No state) | Metro Mirror and Global Mirror relationships that are not in a consistency group. |
1 In rows where two Management GUI icons are shown, the first icon indicates a synchronous-copy Metro Mirror state. The second icon in each row indicates an asynchronous-copy Global Mirror state. |
||
Active-active (HyperSwap) relationship group states
Active-active (HyperSwap) relationship group states describes the active-active (HyperSwap), relationship group states:| Management GUI icon1 | State | Description |
|---|---|---|
|
Inconsistent (stopped) | Both change volumes are not defined in the relationship. |
|
Inconsistent (copying) | The relationship is performing initial synchronization of data to the second copy. |
|
Consistent (stopped) | Either the relationship was created with -sync and both change volumes are not defined or a change volume was force-deleted after the relationship synchronized. |
|
Consistent (copying) | The two copies are different, but resynchronization occurs when it can. During the copy, the status field is online. When the system is unable to copy, the status field shows what is preventing the copy. |
|
Consistent (synchronized) | The two copies both contain all completed host-write operations. The high availability failover and read pass-through options are both available. |
|
Idling | Manual intervention was used to restore access to a historical copy of the relationship. |