Designing Disaster Recovery Clusters using Metroclusters and Continentalclusters, Reprinted October 2011 (5900-1881)

Consistency Group
An important property of asynchronous mode volumes is the Consistency Group (CT group). A CT
group is a grouping of LUNs that need to be treated the same from the perspective of data
consistency (I/O ordering). A CT group is equal to a device group in the Raid Manager
configuration file. A consistency group ID (CTGID) is assigned automatically during pair creation.
NOTE: Different P9000 and XP models support different maximum numbers of Consistency
Groups. For details check the P9000 or XP user’s guide.
Limitations of Asynchronous Mode
The following are restrictions for an asynchronous CT group in a Raid Manager configuration file:
Asynchronous device groups cannot be defined to extend across multiple XP Series disk arrays.
When making paired volumes, the Raid Manager registers a CTGID to the XP Series disk
array automatically at paircreate time, and the device group in the configuration file is
mapped to a CTGID. Efforts to create a CTGID with a higher number will be terminated with
a return value of EX_ENOCTG.
Metrocluster/Continuous Access supports only one consistency group per package. This is
based on the number of packages, in a metropolitan cluster, that can be configured to use a
consistency group.
Furthermore, the number of packages that can be configured to use a consistency group is
limited by either; the maximum number of consistency groups that are supported by the XP
model in the configuration, or the maximum number of packages in the cluster (whichever is
smaller).
Other Considerations on Asynchronous Mode
The following are some additional considerations when using asynchronous mode:
When adding a new volume to an existing device group, the new volume state is SMPL. The
XP disk array controller (DKC) is smart enough to do the paircreate only on the new volume.
If the device group has mixed volume states like PAIR and SMPL, the pairvolchk returns
EX_ENQVOL, and horctakeover will fail.
If you change the LDEV number associated with a given target/LUN, you must restart all the
Raid Manager instances even though the Raid Manager configuration file is not modified.
Any firmware update, cache expansion, or board change, requires a restart of all Raid
Manager instances.
pairsplit for asynchronous mode may take a long time depending on how long the
synchronization takes. there is a potential for the Continuous Access link to fail while
pairsplit is in progress. If this happens, pairsplit will fail with a return code of EX_EWSUSE.
In most cases, Metrocluster/Continuous Access in asynchronous mode will behave the same
as when the fence level is set to NEVER in synchronous mode.
RAID Manager Instance
HP StorageWorks P9000 or XP RAID Manager (P9000 or XP RAID Manager) is a software that
enables you to configure and control data replication and data protection on P9000 or XP disk
arrays. The P9000 or XP RAID Manager lets you issue P9000 or XP Business Copy software and
P9000 or XP Continuous Access software commands from a host. Each execution of P9000 or XP
RAID Manager is known as a RAID Manager instance.
RAID Manager instances running on the local nodes communicate with the RAID Manager instances
running on the remote nodes to get the status of the device group pair.
Overview of Continuous Access P9000 and XP Concepts 157