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 4 Building a Metropolitan Cluster Using MetroCluster/SRDF

Configuring MC/ServiceGuard Packages for Automatic Disaster Recovery

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

Before you can implement these procedures you must:

  • Configure your cluster hardware according to disaster tolerant architecture guidelines outlined in “Designing a Disaster Tolerant Architecture for use with MetroCluster/SRDF”.

  • Configure the MC/ServiceGuard cluster according to the procedures outlined in Managing MC/ServiceGuard manual.

  • Create the SymCLI database, and build Symmetrix device groups, consistency groups, and gatekeepers for each package. Export exclusive volume groups for each package as described in “Preparing a Cluster for MetroCluster/SRDF”. This must be done on each node that will potentially run the package.

  • Install the MetroCluster with EMC SRDF product on all nodes according to the instructions in the MetroCluster with EMC SRDF Release Notes.

When you have completed these steps, packages will be able to automatically fail over to an alternate node in another data center and still have access to the data it needs to function.

This procedure must be repeated on all the cluster nodes for each MC/ServiceGuard application package so the application can failover to any of the nodes in the cluster. Customizations include setting environment variables and supplying customer-defined run and halt commands, as appropriate. The package control script must also be customized for the particular application software that it will control. Consult Managing MC/ServiceGuard for more detailed instructions on how to start, halt, and move packages and their services between nodes in a cluster.

For ease of troubleshooting, you may want to configure and test one package at a time.

  1. Create a directory /etc/cmcluster/pkgname for each package:

    # mkdir /etc/cmcluster/pkgname

  2. Create a package configuration file with the commands:

    # cd /etc/cmcluster/pkgname

    # cmmakepkg -p pkgname.ascii

    Customize the package configuration file as appropriate to your application. Be sure to include the pathname of the control script (/etc/cmcluster/pkgname/pkgname.cntl) for the RUN_SCRIPT and HALT_SCRIPT parameters.

  3. In the <pkgname>.ascii file, list the node names in the order in which you want the package to fail over. It is recommended for performance reasons, that you have the package fail over locally first, then to the remote data center.

    NOTE: If you are using the EMS disk monitor as a package resource, you must not use NO_TIMEOUT. Otherwise, package shutdown will hang if there is not access from the host to the package disks.

    This toolkit may increase package startup time by 5 minutes or more. Packages with many disk devices will take longer to start up than those with fewer devices due to the time needed to get device status from the EMC Symmetrix disk array. Clusters with multiple packages that use devices on the EMC Symmetrix disk array will cause package startup time to increase when more than one package is starting at the same time.

    The value of RUN_SCRIPT_TIMEOUT in the package ASCII file should be set to NO_TIMEOUT or to a large enough value to take into consideration the extra startup time due to getting status from the Symmetrix.

  4. Create a package control script with the command:

    # cmmakepkg -s pkgname.cntl

    Customize the control script as appropriate to your application using the guidelines in Managing MC/ServiceGuard. Standard MC/ServiceGuard package customizations include modifying the VG, LV, FS, IP, SUBNET, SERVICE_NAME, SERVICE_CMD and SERVICE_RESTART parameters. Be sure to set LV_UMOUNT_COUNT to 1 or greater.

  5. Add customer-defined run and halt commands in the appropriate places according to the needs of the application. See Managing MC/ServiceGuard for more information on these functions.

  6. In the package_name.ascii file, list the node names in the order in which you want the package to fail over. It is recommended for performance reasons, that you have the package fail over locally first, then to the remote data center. Be sure to set the MAX_CONFIGURED_PACKAGES parameter to 1 or more, depending on the number of packages that will run on the cluster.

  7. Copy the environment file template /opt/cmcluster/toolkit/SGSRDF/srdf.env to the package directory, naming it pkgname_srdf.env:

    # cp /opt/cmcluster/toolkit/SGSRDF/srdf.env \

    /etc/cmcluster/pkgname/pkgname_srdf.env

  8. Edit the environment file <pkgname>_srdf.env as follows:

    1. Add the path where the srdf.env SymCLI software binaries have been installed to the PATH environment variable. If the software is in the usual location, /usr/symcli/bin, you can just uncomment the line in the script.

    2. Uncomment AUTO*environment variables. It is recommended that you retain the default values of these variables unless you have a specific business requirement to change them. See Appendix B for an explanation of these variables.

    3. Uncomment the PKGDIR variable and set it to the full path name of the directory where the control script has been placed. This directory must be unique for each package and is used for status data files. For example, set PKGDIR to /etc/cmcluster/package_name, removing any quotes around the file names.

    4. Uncomment the DEVICE_GROUP variables EMC Symmetrix for the local disk array and set it to the Symmetrix device group names given in the symdg list command. If you are using an M by N configuration, configure the DEVICE_GROUP variable with the name of the consistency group.

    5. Uncomment the RETRY and RETRYTIME variables. These variables are used to decide how often and how many times to retry the Symmetrix status commands. The defaults should be used for the first package. For other packages RETRYTIME should be altered to avoid contention when more than one package is starting on a node. RETRY * RETRYTIME should be approximately five minutes to keep package startup time under 5 minutes.

       RETRYTIMERETRY
      pkgA60 seconds5 attempts
      pkgB43 seconds7 attempts
      pkgC33 seconds9 attempts

    6. Uncomment the CLUSTERTYPE variable and set it to METRO. (The value CONTINENTAL is only for use with the ContinentalClusters product, described in Chapter 5.)

    7. If you are using an M by N configuration, be sure that the variable CONSISTENCYGROUPS is set to 1 in the control script:

      CONSISTENCYGROUPS=1

  9. Distribute MetroCluster/SRDF configuration, environment and control script files to other nodes in the cluster by using ftp or rcp:

    # rcp -p /etc/cmcluster/pkgname/* \

    other_node:/etc/cmcluster/pkgname

    See the example script Samples/ftpit to see how to semi-automate the copy using ftp. This script assumes the package directories already exist on all nodes.

    Using ftp may be preferable at your organization, since it does not require the use of a.rhosts file for root. Root access via .rhosts may create a security issue.

  10. Verify that each node in the MC/ServiceGuard cluster has the following files in the directory /etc/cmcluster/pkgname:

    pkgname.cntl

    ServiceGuard package control script

    pkgname_srdf.env

    MetroCluster/SRDF environment file

    pkgname.ascii

    ServiceGuard package ASCII configuration file

    pkgname.sh

    Package monitor shell script, if applicable

    other files

    Any other scripts you use to manage MC/ServiceGuard packages

    The MC/ServiceGuard cluster is ready to automatically switch packages to nodes in remote data centers using MetroClusters/SRDF

  11. Check the configuration using the cmcheckconf -P package_name.ascii, then apply the MC/ServiceGuard configuration using the cmapplyconf -P package_name.ascii command or SAM.

  12. Restore the SRDF logical links for the disks associated with the application package. See the script Samples/post.cmapply for an example of how to automate this task. The script must be customized with the Symmetrix device group names. You may want to redirect the output of this script to a file for debugging purposes.

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