Designing Disaster Recovery Clusters using Metroclusters and Continentalclusters, Reprinted October 2011 (5900-1881)

9. Deport the disk group.
# vxdg deport logdata
Repeat steps 4 through 9 on all nodes in the cluster that require access to this disk group.
10. Resynchronize the Continuous Access pair device.
# pairresync -g devicegroupname -c 15
Configuring Legacy Packages for Disaster Recovery
When you have completed the following steps, packages will be able to fail over to an alternate
node in another data center and still have access to the data that they need in order to operate.
This procedure must be repeated on all the cluster nodes for each Serviceguard package so the
application can fail over to any of the nodes in the cluster. Customizations include editing an
environment file to set environment variables, and customizing the package control script to include
customer-defined run and halt commands, as appropriate. The package control script must also
be customized for the particular application software that it will control. Consult the Managing
Serviceguard user’s guide for more detailed instructions on how to start, halt, and move packages
and their services between nodes in a cluster. For ease of troubleshooting, you can configure and
test one package at a time.
1. Create a directory /etc/cmcluster/pkgname for each package.
# mkdir /etc/cmcluster/pkgname
2. Create a package configuration file.
# cd /etc/cmcluster/pkgname
# cmmakepkg -p pkgname.config
Customize the package configuration file as appropriate to your application. Be sure to include
the pathname of the control script (/etc/cmcluster/pkgname/pkgname.cntl) for the
RUN_SCRIPT and HALT_SCRIPT parameters.
3. In the <pkgname>.config file, list the node names in the order in which you want the
package to fail over. It is recommended for performance reasons, to have the package fail
over locally first, then to the remote data center.
Set the value of RUN_SCRIPT_TIMEOUT in the package configuration file to NO_TIMEOUT
or to a large enough value to take into consideration the extra startup time required to obtain
status from the P9000 or XP Series disk array.
If you are using a fence level of ASYNC, then the RUN_SCRIPT_TIMEOUT should be greater
than the value of HORCTIMEOUT in the package environment file (see step 7h below).
NOTE: If you are using the EMS disk monitor as a package resource, you must not use
NO_TIMEOUT. Otherwise, package shutdown will hang if there is no access from the host to
the package disks.
This toolkit may increase package startup time by 5 minutes or more. Packages with many
disk devices will take longer to start up than those with fewer devices due to the time needed
to get device status from the P9000 or XP Series disk array. Clusters with multiple packages
that use devices on the P9000 or XP Series disk array will all cause package startup time to
increase when more than one package is starting at the same time.
4. Create a package control script.
# cmmakepkg -s pkgname.cntl
Customize the control script as appropriate to your application using the guidelines in
Managing Serviceguard. Standard Serviceguard package customizations include modifying
the VG, LV, FS, IP, SUBNET, SERVICE_NAME, SERVICE_CMD and SERVICE_RESTART
parameters. Be sure to set LV_UMOUNT_COUNT to 1 or greater.
Configuring Legacy Packages for Disaster Recovery 179