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 -foption is used.

•During an alarm, the cmrecovercl will start the recovery packages without the -foption.

•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