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

Metrocluster with SRDF/Asynchronous Multi-Session Consistency Data
Replication
The following sections present the concepts, functionality and requirements for configuring
Metrocluster using SRDF/Asynchronous (SRDF/A) Multi-Session Consistency (MSC) Data Replication.
The topics discussed in this section are as follows:
Overview SRDF/Asynchronous MSC Concepts
Configuring Metrocluster with EMC SRDF using SRDF/Asynchronous Multi Session Consistency
(MSC) Data Replication
Building a Composite Group for SRDF/Asynchronous MSC
Package Configuration using SRDF/Synchronous or SRDF/Asynchronous
Overview of SRDF/Asynchronous MSC Concepts
When a database is spread across multiple Symmetrix arrays and SRDF/A is used for long distance
replication, separate software must be used to manage the coordination of the delta set boundaries
between the participating Symmetrix arrays or RDF groups and to stop replication if any of the
volumes in a Symmetrix array or RDF group cannot replicate for any reason. The software must
ensure that all delta set boundaries on every participating Symmetrix array in the configuration
are coordinated to give a consistent point-in-time image of the data.
RDF-Multi Session Consistency (RDF-MSC) is the new technology that provides consistency across
either multiple RDF groups or multiple Symmetrix arrays. RDF-MSC is supported by an SRDF process
daemon that performs cycle switching and cache recovery operations across all SRDF/A sessions
in the group. This ensures that a dependent write consistent R2 copy of the data exists at the remote
site at all the times.
From a single Symmetrix array perspective, the I/O is processed exactly the same way in SRDF/CG
multi-session mode for SRDF/A, as in a single-session mode. Following is the sequence of tasks
that are completed while processing an I/O:
1. The host writes to cycle N (capture cycle) on the R1 side.
2. SRDF/A transfers cycle N-1 (transmit cycle) from R1 to R2.
3. The receive cycle N-1 on the R2 side receives data from the transmit cycle, and the apply
cycle N-2 restores data to the R2 devices.
During this process, the status and location of the active and inactive cycles are communicated
between the R1 and R2 Symmetrix systems. For example, when R1 finishes sending cycle N–1, it
sends a special indication to R2 to let it know that it has completed the inactive cycle transfer.
Similarly, when R2 finishes restoring cycle N – 2, it sends a special indication to let R1 know that
its active cycle is empty. At this point in the process, (that is, when the transmit cycle on the R1
side is empty and the apply cycle on the R2 side is empty), SRDF/A is ready for a cycle switch.
In a single-session mode, once all the conditions are satisfied, an SRDF/A cycle switch is performed.
However, when using SRDF/A MSC, it indicates switch readiness of the array or the RDF group
to the host which is polling for this condition. The cycle switch command is issued by the host only
when all Symmetrix systems or SDRF groups indicate their switch readiness. Hence, the cycle switch
is coordinated across multiple Symmetrix systems or RDF groups.
SRDF/A enters a multi-session mode after receiving a command from the host. As part of the
command to enter the multi-session mode, and with each subsequent switch command issued, the
host provides a tag to each capture cycle that is retained throughout that cycle life. This cycle tag
is a value that is common across all participating SRDF/A sessions and eliminates the need to
synchronize the cycle numbers across them. The cycle tag is the mechanism by which consistency
is assured.
Multi-session SRDF/A performs a coordinated cycle switch during a very short window of time
when there are no host writes being completed. This time period is referred to as an SRDF/A
Metrocluster with SRDF/Asynchronous Multi-Session Consistency Data Replication 295