Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
 Designing Disaster Tolerant High Availability Clusters: > Chapter 5 Building a Continental Cluster

Restoring Disaster Tolerance
» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

spacerspacerspacer
spacer
spacer
  		 
 

After a failover to a cluster occurs, restoring disaster tolerance has many challenges, the most significant of which are:

  • Restoring the failed cluster

    Depending on the nature of the disaster you may need to create a new cluster, or you may be able to restore the cluster. Steps for each scenario are discussed in the following sections.

  • Resynchronizing the data

    To resynchronize the data, you either restore the data to the cluster and continue with the same data replication procedure, or set up data replication to function in the other direction.

The following sections briefly outline some scenarios for restoring disaster tolerance.

Restore Clusters to their Original Roles

If the disaster did not destroy the cluster, you can return both clusters to their original roles. To do this:

  1. Make sure that both clusters are up and running, with the recovery packages continuing to run on the surviving cluster.

  2. On each cluster, stop the ContinentalClusters monitor package if it is still running:

    # cmhaltpkg ccmonpkg

  3. Compare the clusters to make sure their configurations are consistent. Correct any inconsistencies.

  4. For each recovery group where the new cluster will run the primary package:

    1. Synchronize the data from the disks on the surviving cluster to the disks on the new cluster. This may be time-consuming.

    2. Halt the application on the surviving cluster if necessary, and start it on the new cluster.

    3. To keep application down time to a minimum, start the primary package on the cluster before resynchronizing the data of the next recovery group.

  5. Restart the monitor using the following command on each cluster:

    # cmrunpkg ccmonpkg

    Alternatively, if you have modified the monitoring package configuration, use the following sequence on each cluster to apply the new configuration and start the monitor:

    # cmapplyconf -P ccmonpkg.config

    # cmmodpkg -e ccmonpkg

  6. View the status of the ContinentalCluster.

    # cmviewconcl

Primary Packages Remain on the Surviving Cluster

Configure the failed cluster as a recovery-only cluster and the surviving cluster as a primary-only cluster. This minimizes the downtime involved with moving the applications back to the restored cluster. It also assumes that the surviving cluster has sufficient resources to handle running all critical applications indefinitely. Use the following procedure:

  1. Halt the monitor packages. Issue the following command on each cluster:

    # cmhaltpkg ccmonpkg

  2. Edit the ContinentalClusters ASCII configuration file. You will need to change the definitions of monitoring clusters, and switch the names of primary and recovery packages in the definitions of recovery groups. You may also need to re-create data sender and data receiver packages.

  3. Check and apply the ContinentalClusters configuration:

    # cmcheckconcl -v -C cmconcl.config

    # cmapplyconcl -v -C cmconcl.config

  4. Restart the monitor packages. Issue the following command on each cluster:

    # cmmodpkg -e ccmonpkg

  5. View the status of the ContinentalCluster.

    # cmviewconcl

Newly Created Cluster Will Run Primary Packages

After you create a new cluster to replace the damaged one, you may choose to restore the critical applications to the new cluster and restore the other cluster to its role as backup for the recovered packages.

  1. Configure the new cluster as an MC/ServiceGuard cluster. Use the cmviewcl command on the surviving cluster and compare the results to the new cluster configuration. Correct any inconsistencies on the new cluster.

  2. Halt the monitor package on the surviving cluster:

    # cmhaltpkg ccmonpkg

  3. Edit the continental cluster configuration file to replace the data from the old failed cluster with data from the new cluster. Check and apply the ContinentalClusters configuration:

    # cmcheckconcl -v -C cmconcl.config

    # cmapplyconcl -v -C cmconcl.config

  4. For each recovery group where the new cluster will run the primary package:

    1. Synchronize the data from the disks on the surviving cluster to the disks on the new cluster. This may be time-consuming.

    2. Halt the application on the surviving cluster if necessary, and start it on the new cluster.

    3. To keep application down time to a minimum, start the primary package on the cluster before resynchronizing the data of the next recovery group.

  5. If the new cluster acts as recovery cluster for any recovery group, create a monitor package for the new cluster.

    Use the following command to apply the configuration of the new monitor pakcage:

    # cmapplyconf -p ccmonpkg.config

  6. Restart the monitor package on the surviving cluster:

    # cmrunpkg ccmonpkg

  7. View the status of the ContinentalCluster.

    # cmviewconcl

Newly Created Cluster Will Function as Recovery Cluster for All Recovery Groups

After you replace the failed cluster, if you are concerned with the downtime involved in moving the applications back, you can change the surviving cluster to the role of primary cluster for all recovery groups, and configure the new cluster as a recovery cluster for all those groups.

You would configure the new cluster as a standard MC/ServiceGuard cluster, and follow the usual procedure to configure the continental cluster with the new cluster used as a recovery cluster for all recovery groups.



Switching to the Recovery Packages in Case of Disaster
  		 


Maintaining a Continental Cluster  
Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© Hewlett-Packard Development Company, L.P.