Building Disaster Recovery Serviceguard Solutions Using Continentalclusters A.08.00

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 -f option 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