Building Disaster Recovery Serviceguard Solutions Using Metrocluster with EMC SRDF

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> 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> 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 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.
# symrdf -g <device_group> establish
CAUTION: R1/R2 Swapping cannot be used in an M by N Configuration.
Administering the SADTA configuration
This section elaborates the procedures that must be followed to administer a SADTA configuration.
Maintaining a node
To perform maintenance procedures on a cluster node, the node must be removed from the cluster.
Run the cmhaltnode -f command to move the node out of the cluster. This command halts the
complex workload package instance running on the node. As long as there are other nodes in the
site and the Site Controller Package is still running on the site, the site aware disaster tolerant
workload continues to run with one less instance on the same site.
Once the node maintenance procedures are complete, join the node to the cluster using the
cmrunnode command. If the Site Controller package is running on the site that the node belongs
to, the active complex-workload package instances on the site that have the auto_run flag set
to yes, start automatically. If the auto_run flag set to no, then these instances must be manually
started on the restarted node.
Before halting a node in the cluster, the Site Controller Package must be moved to a different node
in the site. For more information about Site Controller Package, see “Moving the Site Controller
package to a node at the local site” (page 65). However, if the node that must be halted in the
cluster is the last surviving node in the site, then the Site Controller packages running on this node
fail over to the other site. In such scenarios, the site aware disaster tolerant workload must be
64 Administering Metrocluster