| United States-English |
|
|
|
![]() |
Designing Disaster Tolerant High Availability Clusters: > Chapter 4 Building a Metropolitan Cluster Using
MetroCluster/SRDFR1/R2 Swapping |
|
This section shows how the R1/R2 swapping can be done via MetroCluster/SRDF package and manual procedures. Each of these allow you to swap the SRDF personality for each device designations of a specified devicegroup, where each source R1 device(s) becomes a target R2 device(s) and a target R1 device(s) becomes a source R1 device(s). The MetroCluster/SRDF package can be configured to automatically do R1/R2 swapping upon package failover. To enable R1/R2 swapping in the package, set the environment variable AUTOSWAPR2 in the <package_name>_srdf.env file to 1. Since the swap is done automatically upon package start up, the MetroCluster/SRDF software will only do 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 are successful, the devices will have their personalities switched, and the data replication will continue from the new R1 devices to the new R2 devices. Note that when failing over a package with R1/R2 swapping, the package startup time will be longer than without swapping. You can also do R1/R2 swapping manually. There are two scenarios where manual swapping is supported by MetroCluster/SRDF. Scenario 1: In this scenario, the package failover is due to host failure or due to planned downtime maintenance. The SRDF links and the Symmetrix frames are still up and running. Because the package startup time will be longer if the swapping is done automatically, the user can choose not to have the swapping done by the package and then 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 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, 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, the user can leave the application running in the secondary data center, and 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 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
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||