Axiomas, definiciones, teoremas, lemas, corolarios

When you have completed the following steps, packages will be able to automatically 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 MC/ServiceGuard package so the application can fail over to any of the nodes in the cluster. Customizations include setting environment variables and supplying 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 Managing MC/ServiceGuard 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

Copy /opt/cmcluster/toolkit/SGCA/sgcapkg.cntl to the package directory, naming it pkgname.cntl:

# cp /opt/cmcluster/toolkit/SGCA/sgcapkg.cntl \ /etc/cmcluster/pkgname/pkgname.cntl

2. Create a package configuration file with the commands:

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

NOTE Do not create an MC/ServiceGuard package control script template with the cmmakepkg -s command or by using SAM. The package control script template included with this product should be used instead.

Building a Metropolitan Cluster Using MetroCluster/CA Configuring Packages for Automatic Disaster Recovery

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, that you 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 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 control script (see step 4g 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 not 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 XP Series disk array. Clusters with multiple packages that use devices on the XP Series disk array will all cause package startup time to increase when more than one package is starting at the same time.

4. Edit the package control script <pkgname>.cntl as follows:

a. If necessary, add the path where the RaidManager software binaries have been installed to the PATH environment variable. If the software is in the usual location, /usr/bin, you can just uncomment the line in the script.

b. Uncomment the behavioral configuration environment variables starting with AUTO_. It is recommended that you retain the default values of these variables unless you have a specific business requirement to change them. See Appendix A for an explanation of these variables.

c. Uncomment the PKGDIR variable and set it to the full path name of the directory where the control script has been placed. This directory, which is used for status data files, must be unique for each package. For example, set PKGDIR to

Configuring Packages for Automatic Disaster Recovery

/etc/cmcluster/package_name, removing any quotes around the file names.

d. Uncomment the DEVICE_GROUP variable and set it to this package’s Raid Manager device group name, as specified in the Raid Manager configuration file.

e. Uncomment the HORCMINST variable and set it to the Raid Manager instance name used by MetroCluster/CA.

f. Uncomment the FENCE variable and set it to either ASYNC, NEVER, or DATA according to your business requirements or special MetroCluster requirements. This variable is used for two purposes:

• To compare with the actual fence level returned by the array.

• To set the fence level when paircreate operations are performed.

g. If you are using asynchronous data replication, set the HORCTIMEOUT variable to a value greater than the side file timeout value configured with the Service Processor (SVP), but less than the RUN_SCRIPT_TIMEOUT set in the package

configuration file. The default setting is the side file timeout value + 60 seconds.

h. Uncomment the DC1HOST array variable and set the elements to the node names of the systems on the local side of the ESCON link. The order of the node names is not important.

i. Uncomment the DC2HOST array variable and set the elements to the node names of the systems on the remote side of the ESCON link. The order of the node names is not important.

j. Uncomment the CLUSTER_TYPE variable and set it to METRO. (The value CONTINENTAL is for use with ContinentalClusters, described in Chapter 5.)

5. Customize the control script as appropriate to your application using the guidelines in Managing MC/ServiceGuard. Standard

MC/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.

6. Add customer-defined run and halt commands in the appropriate places according to the needs of the application. See Managing

Building a Metropolitan Cluster Using MetroCluster/CA Configuring Packages for Automatic Disaster Recovery

MC/ServiceGuard for more information on these functions.

7. After customizing the control script file and before starting up the package, do a syntax check on the control script using the following command (be sure to include the -n option to perform syntax checking only):

# sh -n <pkgname.cntl>

If any messages are returned, you should correct the syntax errors.

8. Check the configuration using the cmcheckconf -P

pkgname.config, then apply the MC/ServiceGuard configuration using the cmapplyconf -P pkgname.config command or SAM.

9. Distribute MetroCluster/CA control script files to other nodes in the cluster by using ftp or rcp:

# rcp -p /etc/cmcluster/pkgname/pkgname.cntl \ other_node:/etc/cmcluster/pkgname/pkg_ame.cntl

See the example script Samples/ftpit to see how to semi-automate the copy using ftp. This script assumes the package directories already exist on all nodes.

Using ftp may be preferable at your organization, since it does not require the use of a.rhosts file for root. Root access via .rhosts may create a security issue.

10. Verify that each node in the MC/ServiceGuard cluster has the following files in the directory /etc/cmcluster/pkgname: pkgname.cntl MetroCluster/CA package control script

pkgname.config ServiceGuard package ASCII configuration file pkgname.sh Package monitor shell script, if applicable other files Any other scripts you use to manage

MC/ServiceGuard packages

The MC/ServiceGuard cluster is ready to automatically switch packages to nodes in remote data centers using MetroCluster/CA.

Maintaining a Cluster that uses MetroCluster/CA

Maintaining a Cluster that uses