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 <package_name>.config file, list the node names in the order in which you want the package to fail over. It is recommended for performance reasons, that you have the package fail over locally first, then to the remote data center.

The failover_policy parameter for a Metrocluster package can be set to

site_preferred. This value implies that during a Metrocluster package failover, while selecting nodes from the list of the node_name entries, the Metrocluster package will first fail over to the nodes that belong to the site of the node it last ran on, rather than the nodes that belong to the other site. To use this policy the underlying cluster must be configured with sites and each cluster nodes should be associated to a site. For information on configuring the failover policy to site_preferred, see “Site Aware Failover Configuration” (page 26).

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 EVA.

NOTE: If using the EMS disk monitor as a package resource, do 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 EVA. Clusters with multiple packages that use devices on the EVA 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 <package_name>.cntl

Customize the control script as appropriate to your application using the guidelines in the Managing Serviceguard user’s guide. Standard Serviceguard package customizations include modifying the VG, LV, FS, IP, SUBNET, SERVICE_NAME, SERVICE_CMD and SERVICE_RESTART parameters. Be sure to set FS_UMOUNT_COUNT to 1.

5.Add customer-defined run and halt commands in the appropriate places according to the needs of the application. Refer to the Managing Serviceguard user’s guide for more detailed information on these functions.

6.Copy the environment file template/opt/cmcluster/toolkit/SGCAEVA/caeva.env to the package directory, naming it pkgname_caeva.env:

#cp /opt/cmcluster/toolkit/SGCAEVA/caeva.env \ /etc/cmcluster/pkgdir/<package_name>_caeva.env

NOTE: If not using a package name as a filename for the package control script, it is necessary to follow the convention of the environment file name. This is the combination of the file name of the package control script without the file extension, an underscore and type of the data replication technology (caeva) used. The extension of the file must be env. The following examples demonstrate how the environment file name should be chosen.

Example 1: If the file name of the control script is pkg.cntl, the environment file name would be pkg_caeva.env.

Example 2: If the file name of the control script is control_script.sh, the environment file name would be control_script_caeva.env.

7.Edit the environment file pkgname_caeva.env as follows:

232 Building Disaster Recovery Serviceguard Solutions Using Metrocluster with Continuous Access EVA