Designing Disaster Recovery Clusters using Metroclusters and Continentalclusters, Reprinted October 2011 (5900-1881)

9. Apply the Serviceguard configuration using the cmapplyconf command or SAM.
10. Verify that each node in the Serviceguard cluster has the following files in the directory
/etc/cmcluster/pkgname:
bkpbkgname.cntl Metrocluster/Continuous Access package control script
bkpkgname_xpca.env Metrocluster/Continuous Access 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 Serviceguard packages
11. 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 Serviceguard is started.
12. Make sure the packages on the source disk site are not running. Using standard Serviceguard
commands (cmruncl, cmhaltcl, cmrunpkg, cmhaltpkg) test the target disk site for cluster
and package startup and package failover.
13. Any running package on the target disk site that has a counterpart on the source disk site
should be halted at this time.
Setting up the Continentalclusters Configuration
The steps below are the basic procedure for setting up the Continentalclusters configuration file
and the monitoring packages on the two clusters. For complete details on creating and editing the
configuration file, refer to Chapter 2: “Designing Continentalclusters”.
1. Generate the Continentalclusters configuration.
# cmqueryconcl -C cmconcl.config
2. Edit the configuration file cmconcl.config with the names of the two clusters, the nodes in
each cluster, the recovery groups and the monitoring definitions. The recovery groups define
the primary and recovery packages. When data replication is done using Continuous Access
P9000 or XP, there are no data sender and receiver packages.
Define the monitoring parameters, the notification mechanism (ITO, email, console, SNMP,
syslog or tcp) and notification type (alert or alarm) based on the cluster status (unknown, down,
up or error). Descriptions for these can be found in the configuration file generated in the
previous step.
3. Edit the Continentalclusters security file /etc/opt/cmom/cmomhosts to allow or deny hosts
read access by the monitor software.
4. On all nodes in both clusters copy the monitor package files from /opt/cmconcl/scripts
to/etc/cmcluster/ccmonpkg. Edit the monitor package configuration as needed in the
file /etc/cmcluster/ccmonpkg/ccmonpkg.config. Set the AUTO_RUN flag to YES.
This is in contrast to the flag setting for the application packages. The desired result is to have
the monitor package start automatically when the cluster is formed.
5. Apply the monitor package to both cluster configurations.
# cmapplyconf -P /etc/cmcluster/ccmonpkg/ccmonpkg.config
6. Apply the Continentalclusters configuration file using cmapplyconcl. Files are placed in
/etc/cmconcl/instances. There is no change to /etc/cmcluster/cmclconfig nor
is there an equivalent file for Continentalclusters.
# cmapplyconcl -C cmconcl.config
7. Start the monitor package on both clusters.
Completing and Running a Continentalclusters Solution with Continuous Access P9000 or XP 205