 |
» |
|
|
|
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. Create a directory /etc/cmcluster/pkgname for each package. # mkdir /etc/cmcluster/pkgname 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. 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 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 7g 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 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. 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. Add customer-defined run and halt commands in the
appropriate places according to the needs of the application. See Managing Serviceguard for
more information on these functions. Copy the environment file template /opt/cmcluster/toolkit/SGCA/xpca.env to the package directory, naming it pkgname_xpca.env. # cp /opt/cmcluster/toolkit/SGCA/xpca.env \ /etc/cmcluster/pkgname/pkgname_xpca.env | | | | | NOTE: If you do not use a package name as a filename for the
package control script, you must 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 (xpca) 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_xpca.env.
Example 2: If the file name of
the control script is control_script.sh, the environment file name would be control_script_xpca.env. | | | | |
Edit the environment file <pkgname>_xpca.env as follows: If necessary, add the path where the
Raid Manager 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. 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. 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 /etc/cmcluster/package_name, removing any quotes around the file names. 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. Uncomment the HORCMPERM variable and use the default value MGRNOINST if Raid Manager protection facility is not used
or disabled. If Raid Manager protection facility is enabled set
it to the name of the HORCM permission file. Uncomment the HORCMINST variable and set it to the Raid Manager instance
name used by Metrocluster/Continuous Access. 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 to compare with the actual fence
level returned by the array. 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. Uncomment the CLUSTER_TYPE variable and set it to METRO if you are using Metrocluster, or CONTINENTAL if you are using Continentalclusters.
After customizing the control script file and creating
the environment 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. Check the configuration using the cmcheckconf -P pkgname.config, then apply the Serviceguard configuration using the cmapplyconf -P pkgname.config command or SAM. Distribute
Metrocluster/Continuous Access configuration, environment and control
script files to other nodes in the cluster by using ftp or rcp: # rcp -p /etc/cmcluster/pkgname/* \ other_node:/etc/cmcluster/pkgname 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 the .rhosts may create a security issue. Verify that each node in the Serviceguard cluster
has the following files in the directory /etc/cmcluster/pkgname. - pkgname.cntl
Seviceguard package control
script - pkgname_xpca.env
Metrocluster/Continuous
Access environment file - pkgname.config
Serviceguard
package ASCII configuration file - pkgname.sh
Package
monitor shell script, if applicable - other files
Any
other scripts you use to manage Serviceguard
packages
The Serviceguard cluster is ready to automatically switch
packages to nodes in remote data centers using Metrocluster/Continuous
Access. |
Printable version
