User's Guide

1. Swap the personalities of the devices and mark the old R1 devices to be refresh from the old
R2 devices.
# symrdf -g <device_group> swap -refresh R1
2. After swapping is completed, the devices will be in Suspended state. Next establish the device
group for data replication from the new R1 devices to the new R2 devices.
# symrdf -g <device_group> establish
Scenario 2: In this scenario, two failures happen before the package fails over to the secondary
data center. The SRDF link fails; the package continues to run and write data on R1 devices.
Sometime later, the host fails; the package then fails over to the secondary data center. In this
case, even if the AUTOSWAPR2 variable is set to 1 or 2, the package will not do the R1/R2
swapping, which happens after the host in the primary data center and the SRDF links are fixed.
To minimize the application down time, instead of failing the application back to the primary data
center, leave the application running in the secondary data center. Then manually swap the devices
personalities and change the direction of the data replication.
1. Swap the personalities of the devices and mark the old R1 devices to be refresh from the old
R2 devices.
# symrdf -g <device_group> swap -refresh R1
2. After swapping is completed, the devices will be in a suspended state. Next Establish the device
groups for data replication from the new R1 devices to the new R2 devices.
# symrdf -g <device_group> establish
CAUTION: R1/R2 Swapping cannot be used in an M by N Configuration.
Some Further Points
Following are listed some EMC Symmetrix specific requirements:
• R1 and R2 devices have been correctly defined and assigned to the appropriate nodes in the
internal configurations that is downloaded by EMC support staff.
• R1 devices are locally protected (RAID 1 or RAID S); R2 devices are locally protected (RAID
1, RAID S or BCV).
NOTE: It is highly recommended that the R2 device is locally protected with RAID 1 or
RAID S. If the R2 device is protected with BCV, and if it fails and there is a failover, the
package cannot operate on the BCV device. The R2 device has to be fixed, the data has to
be restored from the BCV device to the new R2 device, before the package can start.
• Only synchronous and asynchronous modes are supported; adaptive copy must be disabled.
• Domino Mode enabled is required for M x N configuration to ensure the following:
data currency on all Symmetrix frames◦
◦ there is no possibility of inconsistent data at the R2 side in case of SRDF links failure
If Domino Mode is not enabled and all SRDF links fail, the new data is not replicated to the
R2 side while the application continues to modify the data on the R1 side. This will result in
the R2 side containing a copy of the data only up to the point of the Continuous Access link
failure. If additional failure occurs, such as a system failure before the SRDF link is fixed, it
will cause the application to fail over to the R2 side with only non-current data.
If Domino Mode is not enabled, in the case of a rolling disaster, the data may be inconsistent.
Additional failures may take place before the system has completely recovered from a previous
288 Building Disaster Recovery Serviceguard Solutions Using Metrocluster with EMC SRDF