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 primary 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, environment file and contributed
scripts will reside in the /opt/cmcluster/toolkit/SGCA and /usr/sbin directories. One fileset contains the Continuous Access
(CA) integration scripts, environment file and sample scripts directory.
When swinstall(1m) has completed, create a directory as follows for the
new package in the primary cluster:
# mkdir /etc/cmcluster/<package_name>
Create an MC/ServiceGuard package configuration file in the primary
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. Only after primary packages start, use cmmodpkg to enable package switching on all primary packages.
Enabling package switching in the package configuration would automatically
start the primary package when the cluster starts. However, had
there been a primary cluster disaster, resulting in the recovery
package starting and running on the recovery cluster, the primary
package should not be started until after first stopping 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.
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
MetroCluster/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:
- pkgname.cntl
MetroCluster/CA package control script
- pkgname_xpca.env
MetroCluster/CA environment file
- pkgname.ascii
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.
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.
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.
Using standard MC/ServiceGuard commands (cmruncl, cmhaltcl, cmrunpkg, cmhaltpkg), test the primary cluster for cluster and package startup
and package failover.
Any running package on the primary cluster that
will have a counterpart on the recovery cluster must be halted at
this time.
Printable version
