HP Serviceguard Metrocluster with EMC SRDF for Linux B.01.00.00

R1/R2 swapping
This section describes how the R1/R2 swapping can be done via the Metrocluster package and
manual procedures. Each of these methods allow swapping the SRDF personality for each device
designation of a specified device group. When swapped, every source R2 device becomes a
target R2 device, and a target R1 device becomes a source R1 device.
R1/R2 swapping using Metrocluster with EMC SRDF for Linux
The Metrocluster SRDF package is always configured to automatically carry out the R1/R2 swapping
upon package failover whenever possible. During a start up, the Metrocluster SRDF software
performs the swap if the Symmetrix frames and the SRDF links between them are working properly.
That is, the SRDF state of the device group is in Synchronized state. If the failover and swap
operations succeed, then the device personalities are switched, and the data replication continues
from the new R1 devices to the new R2 devices.
Before Metrocluster performing an R1/R2 swap, if the failover operation fails, the package is not
automatically started. If the failover operation succeeds, but R1/R2 swapping fails, package is
still started but replication might not be established.
NOTE: When failing over a package with R1/R2 swapping, the package startup time is longer
than without the swapping.
R1/R2 swapping using manual procedures
It is also possible to manually perform the R1/R2 swapping. In two scenarios Metrocluster with
EMC SRDF for Linux supports manual swapping.
Scenario 1: In this scenario, the package failover is because of host failure or because of planned
downtime maintenance. The SRDF links and the Symmetrix frames are still up and running. Because
the package startup time is longer when the swapping is done automatically, you can choose not
to have the swapping done by the package, and later manually execute the swapping after the
package is up and running on the R2 side. Following is the manual procedure to swap the devices
personalities and change the direction of the data replication.
On the host that connects to the R2 side, use the following steps:
1. Swap the personalities of the devices and mark the old R1 devices to refresh from the old R2
devices.
# symrdf -g <Device Group Name> swap -refresh R1
2. After swapping is completed, the devices are in Suspended state. Establish the device group
for data replication from the new R1 devices to the new R2 devices.
# symrdf -g <Device Group Name> 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 though Metrocluster tries to automatically swap roles, it may not succeed. Hence, the
package does not carry out the R1/R2 swapping.
After the host in the primary data center and the SRDF links are fixed then 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, 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 refresh from the old R2
devices.
# symrdf -g <device_group> swap -refresh R1
2. After swapping is completed, the devices are in a suspended state. Establish the device groups
for data replication from the new R1 devices to the new R2 devices.
36 Administering Metrocluster