HP Serviceguard Metrocluster Performing recovery in case of disaster, Receiving notification

3 Performing a recovery operation in Continentalclusters environment

Performing recovery in case of disaster

You can also initiate recovery forcefully even if the alarm event has not triggered but the alert event has happened. An administrator can initiate the recovery using cmrecoverclcommand. However, an administrator must confirm from the primary cluster administrator for the need of the recovery. After the confirmation is obtained, the administrator can start the recovery process using the cmrecovercl command. The administrator can choose to recover all the primary packages, or specific packages by specifying the recovery group names.

The primary steps for failing over a package are:

1.Receiving notification.

2.Verifying that recovery is required.

3.Preparing the storage in the recovery cluster

4.Using the cmrecovercl command to failover the recovery groups.

Receiving notification

After the monitor is started, as described in the section “Starting the Continentalclusters monitor package” (page 26), the monitor sends 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 must be treated as information that the cluster either might be developing a problem or might be recovering from a problem.

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

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

Verifying that recovery is required

It is important to follow an established protocol for coordinating with the remote cluster administrators to determine whether it is necessary to move the package. This includes initiating person-to-person communication between cluster sites. For example, it might be possible that the WAN network failed, causing the cluster alarm. Even if the cluster is down, it could be intentional and might not require recovery.

Some network failures, such as those that prevent clients from using the application, might require recovery. Other network failures, such as those that only prevent the two clusters from communicating, might not require recovery. Following an established protocol for communicating with the remote site must verify this. For an example of a recovery checklist, see the section “Recovery Checklist” (page 76).

Preparing the storage manually in the recovery cluster

If Metrocluster with Continuous Access for P9000 and XP, or Metrocluster with Continuous Access EVA, or Metrocluster with EMC SRDF, or Metrocluster with 3PAR Remote Copy is not being used, use the following steps before executing the Continentalclusters recovery command, cmrecovercl.

Performing recovery in case of disaster 29