Building Disaster Recovery Serviceguard Solutions Using Metrocluster with EMC SRDF

3. Distribute the Metrocluster EMC SRDF configuration changes.
# cmapplyconf -P pkgconfig
4. Restore the logical SRDF links for the package. In the pre.cmquery script, replace the device
group name with the device group in your environment.
# /opt/cmcluster/toolkit/SGSRDF/Samples/post.cmapply
5. Start the package with the appropriate Serviceguard command.
# cmmodpkg -e pkgname
The status of the SA/FA ports is not verified. It is assumed that at least one PVLink is functional.
Otherwise, the Volume Group activation fails.
Planned maintenance is treated the same as a failure by the cluster. If the node is brought down
for maintenance, package failover and quorum calculation is based on the remaining nodes.
Ensure that the nodes are brought down evenly at each site, and enough nodes remain on-line to
form a quorum if a failure occurs.
Managing Business Continuity Volumes (BCV)
The use of BCV is recommended with all implementations of Metrocluster with EMC SRDF, and it
is required with M by N configurations, which employ consistency groups. These BCV devices
provide a good copy of the data when it is necessary to recover from a rolling disaster—a second
failure that occurs while attempting to recover from the first failure.
Protecting against rolling disasters
The following is an example of a rolling disaster with Metrocluster with EMC SRDF.
At time T0, all the SRDF links go down. The application continues to run on the R1 side. At time
T1, the SRDF links are restored, and at T2 a manual resynchronization is started to resync new
data from the R1 to the R2 side. At time T3, while resynchronization is in progress, the R1 site
fails, and the application starts up on the R2 side. The resynchronization did not complete when
there was a failure on the R1 side. Therefore, the data on the R2 side is corrupt.
Using the BCV in resynchronization
In the case described above, you use the business continuity volumes, which protect against a
rolling disaster. First split off a consistent copy of the data at the recovery site, and then perform
the re-synchronization. After the re-synchronization is complete, re-establish the BCV mirroring. To
protect data consistency on R2 in rolling disaster, use the following procedure:
1. Before starting the re-synchronization from R1 to R2 side, it is necessary to disable the package
switch capability to prevent the package automatically fail over to R2 if a new disaster occurs
when the re-sync is still in progress. Disable the package switching on the R2 nodes.
# cmmodpkg -d pkgname -n node_name
2. Split the BCV in the secondary Symmetrix from the mirror group to save a good copy of the
data from the nodes on the R2 side.
# symmir -g dgname split
Alternatively, from the node on R1 side.
# symmir -g dgname split -rdf
3. Begin to resynchronize the data from R1 to R2 devices.
# symrdf -g dgname est
62 Administering Metrocluster