NOTE: Continentalclusters monitors cluster status, but not package status.

7.View the status of the Continentalclusters.

# cmviewconcl

Switching to the Recovery Packages in Case of Disaster

Once the clusters are configured and tested, packages will be able to fail over to an alternate node in another data center and still have access to the data they need to function. The primary steps for failing over a package are:

1.Receive notification that a monitored cluster is unavailable.

2.Verify that it is necessary and safe to start the recovery packages.

3.Use the recovery command to stop data replication and start recovery packages.

4.View the status of the Continentalclusters.

# cmviewconcl

It is important to have a well-defined recovery process, and that all members at both sites are educated on how to use this process.

Receiving Notification

Once the monitor is started, as described in “Starting the Continentalclusters Monitor Package” (page 89), the monitor will send notifications as configured. The following types of notifications are generated as configured in cmclconf.ascii:

•CLUSTER_ALERT is a change in the status of a cluster. Recovery via the cmrecovercl command is not enabled by default. This should be treated as information that the cluster either may be developing a problem or may be recovering from a problem.

•CLUSTER_ALARM is a change in the status of a cluster that indicates that the cluster has been unavailable for an unacceptable amount of time. Recovery via the cmrecovercl command is enabled.

The issuing of notifications takes place at the timing intervals specified for each cluster event. However, it sometimes may appear that an alert or alarm takes longer than configured. Keep in mind that if several changes of cluster state (for example, Down to Error to Unreachable to Down) take place in a smaller time than the configured interval for an alert or alarm, the timer is reset to 0 after each change of state; thus, the time to the alert or alarm will be the configured interval plus the time used by all the earlier state changes.

NOTE: The cmrecovercl command is fully enabled only after a CLUSTER_ALARM is issued; however, the command may be used with the -foption when a CLUSTER_ALERT has been issued.

Verifying that Recovery is Needed

It is important to follow the established protocol for coordinating with the remote site to determine whether moving the package is required. This includes initiating person-to-person communication between sites. For example, it may be possible that the WAN network failed, causing the cluster alarm.

Some network failures, such as those that prevent clients from using the application, may require recovery. Other network failures, such as those that only prevent the two clusters from communicating, may not require recovery. Following an established protocol for communicating with the remote site would verify this. See Figure 20 (page 91) for an example of a recovery checklist.

94 Designing Continentalclusters