 |
» |
|
|
|
Use the procedures in this section to configure a recovery
package on the recovery cluster. Consult the MC/ServiceGuard documentation
for more detailed instructions on setting up MC/ServiceGuard with
packages, and for instructions on how to start, halt, and move packages
and their services between nodes in a cluster. | | | |  | NOTE: Neither the primary cluster nor the recovery cluster
may configure an XP series paired volume, PVOL or SVOL, as a cluster
lock disk. A cluster lock disk must always be writable. Since
it cannot be guaranteed that either half of a paired volume is always
writable, they may not be used as a cluster lock disk. Using a
disk as a cluster lock disk that is part of a paired volume is not
a supported configuration. | | | | |
Create and test a standard MC/ServiceGuard
cluster using the procedures described in the user's manual, Managing MC/ServiceGuard. Install ContinentalClusters on all the cluster nodes
in the recovery cluster (Skip this step if the software has been
preinstalled) | | | | | NOTE: MC/ServiceGuard should already be installed on all the
cluster nodes. | | | | |
Run swinstall(1m) to install ContinentalClusters product from an SD depot.
The toolkit integration scripts, environmental file, control file
and contributed scripts will reside in the /opt/cmcluster/toolkit/SGCA and /usr/sbin directories. One fileset contains the Continuous
Access (CA) tintegration scripts, environmental file and sample
scripts directory. When swinstall(1m) has completed, create a directory as follows for the
new package in the recovery cluster: # mkdir /etc/cmcluster/<package_name> Create an MC/ServiceGuard package configuration file in the recovery cluster
with the commands: # cd /etc/cmcluster/<package_name> # cmmakepkg -p <package_name>.ascii
Customize it as appropriate to your application.
Be sure to include the pathname of the control script (/etc/cmcluster/<package_name>/ <package_name>.cntl)
for the RUN_SCRIPT and HALT_SCRIPT parameters. Set the AUTO_RUN flag to NO. This is to ensure the package will not start
when the cluster starts. Do not use cmmodpkg
to enable package switching on any recovery package. Enabling package switching
will automatically start the recovery package. Package switching
on a recovery package will be automatically set by the cmrecovercl command on the recovery cluster when it successfully starts
the recovery package. Create a package control script with the command: # cmmakepkg -s pkgname.cntl 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. | | | | | NOTE: Some of the control script variables, such as VG and LV, on the recovery cluster must be the same as on
the primary cluster. Some of the control script variables, such
as, FS, SERVICE_NAME, SERVICE_CMD and SERVICE_RESTART are probably the same as on the primary cluster.
Some of the control script variables, such as IP and SUBNET, on the recovery cluster are probably different from
those on the primary cluster. Make sure that you review all the
variables accordingly. | | | | |
Add customer-defined run and halt commands in the
appropriate places according to the needs of the application. See Managing MC/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 Edit the environment file <pkgname>_xpca.env as follows: 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. 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/CA. 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 DC1HOST array
variable and set the elements to the node names of the systems on
the local side of the CA link. The order of the node names is not
important. Uncomment the DC2HOST array
variable and set the elements to the node names of the systems on
the remote side of the CA link. The order of the node names is not
important. Uncomment the CLUSTER_TYPE variable and set it to METRO. (The value CONTINENTAL is for use with ContinentalClusters, described in
Chapter 5.)
Distribute
ContinentalCluster/CA 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 .rhosts may create a security issue. Apply the MC/ServiceGuard configuration using the cmapplyconf command or SAM. Verify that each node in the MC/ServiceGuard cluster
has the following files in the directory /etc/cmcluster/pkgname: - bkpbkgname.cntl
MetroCluster/CA package control script - bkpkgname_xpca.env
MetroCluster/CA environment file - bkpkgname.ascii
ServiceGuard package ASCII configuration file - bkpkgname.sh
Package monitor shell script, if applicable - other files
Any other scripts you use to manage MC/ServiceGuard
packages
Edit the file /etc/rc.config.d/raidmgr, specifying
the Raid Manager instance to be used for ContinentalClusters, and
specify that the instance be started at boot time. | | | | | NOTE: The appropriate Raid Manager instance used by ContinentalClusters must be
running before the package is started. This
normally means that the Raid Manager instance must be started before MC/ServiceGuard
is started. | | | | |
Make sure the packages on the primary cluster are
not running. Using standard MC/ServiceGuard commands (cmruncl, cmhaltcl, cmrunpkg,
cmhaltpkg) test the recovery cluster for cluster and package startup
and package failover. Any running package on the recovery cluster that
has a counterpart on the primary cluster should be halted at this
time.
|
Printable version
