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

It is required that there be a pool of four additional gatekeeper devices that are NOT associated
with any device group. These gatekeepers would be available for other, non-cluster uses, for
example, the Symmetrix Manager GUI and other EMC Solutions Enabler or SymAPI requests.
After data configuration, each physical device in the Symmetrix has enough space remaining
on it for gatekeeper purposes.
• This toolkit does not support the HP OmniBack Integration with Symmetrix. The OmniBack
Integration with Symmetrix may create certain states that will cause this package to halt if a
failover occurs while the backup is in progress.
• No checking of the status of the SA/FA ports is done. It is assumed that at least one PVLink
is functional. Otherwise, the VG activation will fail.
• This toolkit may increase package startup time by 5 minutes or more. Packages with many
disk devices will take longer to start up than those with fewer devices due to the time needed
to get device status from the Symmetrix. Clusters with multiple packages that use devices on
the Symmetrix will cause package startup time to increase when more than one package is
starting at the same time.
• The value of RUN_SCRIPT_TIMEOUT in the package ASCII file should be set to NO_TIMEOUT
or to a large enough value to account for the extra startup time due to getting status from the
Symmetrix. See the previous paragraph for more information on the extra startup time.
Metrocluster with SRDF/Asynchronous Data Replication
The following sections presents concepts, functionality and requirements for configuring Metrocluster
using SRDF/Asynchronous data replication.
SRDF/Asynchronous delivers asynchronous data replication solutions featuring a consistent and
restartable copy of the production data at the remote side. Metrocluster with EMC SRDF supports
SRDF/Asynchronous to further enhance and protect critical business information. The topics discussed
in this section are as follows:
• Overview of SRDF/Asynchronous Concepts
• Requirements for using SRDF/Asynchronous in a Metrocluster Environment
• Preparing the Cluster for SRDF/Asynchronous Data Replication
• Building a Device Group for SRDF/Asynchronous
• Limitations and Restrictions
Overview of SRDF/Asynchronous Concepts
SRDF/Asynchronous provides a long-distance replication solutions with minimal impact on
performance. This protection level is intended for customers requiring minimal host application
impact, but need to maintain a restartable copy of data at R2 site. Data is transferred from R1 site
to the R2 site in predefined timed cycles called delta sets, which eliminates the redundancy of same
track changes being transferred over the link. In the event of a disaster at the R1 site or if SRDF
links are lost during data transfer, a partial delta set of data is discarded. However, a dependent
write consistent point-in-time copy of data is retained on the target side. Figure 50 depicts the
SRDF/Asynchronous data sets.
• At the R1 site, the capture cycle is collecting all new writes and tagging them as belonging
to cycle N. There is also a transmit cycle (N-1) which is not receiving any new data, but is
transferring the data it has collected when it was the active cycle to the remote side. The
capture cycle switches roles from capture to transmit during the cycle switch process and a
new capture cycle is created.
• At the R2 site, there is a receive cycle (N-1), which is receiving data from the transmit cycle
at R1. The apply cycle (N-2) at the remote site is marking all the tracks from a previous cycle
290 Building Disaster Recovery Serviceguard Solutions Using Metrocluster with EMC SRDF