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

4. Edit the Continentalclusters security file /etc/opt/cmom/cmomhosts to allow or deny hosts
read access by the monitor software.
5. 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 monitor package should
start automatically when the cluster is formed.
6. Apply the monitor package to both cluster configurations.
# cmapplyconf -P /etc/cmcluster/ccmonpkg/ccmonpkg.config
7. Restore the logical SRDF links for the package. See the script Samples/post.cmapplyfor
an example of how to automate this task. The script must be customized with the appropriate
Symmetrix device group names. Example:
# Samples/post.cmapply
8. Generate the cluster 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. Example:
# cmapplyconcl -C cmconcl.config
9. Start the monitor package on both clusters.
The monitor package for a cluster checks the status of the other cluster and issues alerts and
alarms, as defined in the Continentalclusters configuration file, based on the other cluster’s
status.
10. Check /var/adm/syslog/syslog.log for messages. Also check the ccmonpkg package
log file.
11. Start the primary packages on the source disk site using cmrunpkg. Test local failover within
the source disk site.
12. View the status of the Continentalclusters primary and target disk sites, including configured
event data.
# cmviewconcl -v
The Continentalclusters is now ready for testing. See Chapter 2: “Designing Continentalclusters”,
section “Testing the Continentalclusters” (page 92).
Switching to the Recovery Cluster in Case of Disaster
It is vital the administrator verify that recovery is needed after receiving a cluster alert or alarm.
Network failures may produce false alarms.
After validating a failure, start the recovery process using the cmrecovercl [-f] command.
Note the following:
• During an alert, the cmrecovercl will not start the recovery packages unless the -f option
is used.
• During an alarm, the cmrecovercl will start the recovery packages without the -f option.
• When there is neither an alert nor an alarm condition, cmrecovercl cannot start the recovery
packages on the target disk site. This condition applies not only when no alert or alarm was
issued, but also applies to the situation where there was an alert or alarm, but the source disk
site recovered and its current status is Up.
Verify SRDF links are Up.
# symrdf list
304 Building Disaster Recovery Serviceguard Solutions Using Metrocluster with EMC SRDF