 |
» |
|
|
|
The steps for configuring the clusters, needed
by Continentalclusters, are as follows: Set up and test data replication
between the sites. Configure each cluster
for Serviceguard operation.
Setting up and Testing Data Replication | |
Depending on which data replication method you
choose, it can take a week or more to set up and test a data replication
method. If there is more than one recovery pair configured in a continental
cluster, a separate data replication link is required to be set up
for a different recovery pair (one for each pair). In the sample configuration, physical data replication
is done through a hardware link between disk arrays. Because this
method is hardware based, there is hardware set up and configuration
that can take several days. Some logical replication methods, such
as transaction processing monitors (TPMs), need application changes
that are more easily done during the original application development. Make sure that the data replication to the recovery
site is functional. This would include setting up the physical data
replication links across the WAN and making sure that the data is
replicated between the shared disk arrays. | | | |  | NOTE: If using physical data replication on the HP StorageWorks Disk
Array XP Series with Continuous Access XP or HP StorageWorks Disk
Array EVA Series with Continuous Access EVA or on the EMC Symmetrix
using EMC SRDF, use the special environment file templates that are
installed along with either Metrocluster with Continuous Access XP,
or Metrocluster with Continuous Access EVA, or Metrocluster with EMC
SRDF software. Refer to Chapters 3, 4 and 5 for detailed instructions
on configuring these special environment files. | | | | |
If the data replication software is separate from
the application itself, then a separate Serviceguard package should
be created for it. Some kinds of logical data replication require
that a data receiver package be running on the recovery cluster at
all times. If data sender and data receiver packages are used as your
choice of data replication method, configure and apply them as described
in the next sections before applying the continental cluster configuration. Table 2-5 shows
the types of packages that are needed for each type of data replication. Table 2-5 Continentalclusters Data Replication Package Structure | Primary Cluster | Recovery Cluster |
|---|
| Replication Type | Primary Application Package | Data Replication Sender Package | Recovery
Application Package | Data Replication Receiver
Package |
|---|
| XP Series Continuous Access | Yes | No | Yes | No | | EVA Series Continuous Access | Yes | No | Yes | No | | Symmetrix/EMC SRDF | Yes | No | Yes | No | | Oracle Standby Database | Yes | No | Yes | Yes |
Configuring a Cluster without Recovery Packages | |
Use the following steps and the instructions described
in chapters 4 through 7 of Managing Serviceguard user’s guide
as guidelines for creating a new cluster or preparing an existing
cluster to run in a Continentalclusters environment: If creating a new cluster,
install required versions of HP-UX and Serviceguard. Also, if using
an existing cluster, upgrade to the versions of HP-UX and Serviceguard
that are required for Continentalclusters. See the Continentalclusters
Release Notes for specifics on your versions requirements.
Coordinate with the recovery site to make sure the same versions and
patches are installed at both sites. Set up all cabling, being
sure to provide redundant disk storage links and network connections. Configure the disks and
filesystems. Set up data replication (logical or physical). Configure the cluster
according to the instructions in chapter 5 of the Managing Serviceguard
user’s guide. Use the cmapplyconf command
to apply the cluster configuration. Then test the cluster. Configure and test each
primary package according to the instructions in chapters 6 and 7
of the Managing Serviceguard user’s guide. Use the cmapplyconf command to apply the package
configuration. Be sure that AUTO_RUN is set to NO in the package ASCII configuration file for any package that is
in a recovery group, and therefore might at some time be a candidate
for recovery. This is to ensure that the package will not be automatically started if the primary site tries to come up again
following a primary site disaster. If changing
the setting of the AUTO_RUN parameter to NO in the ASCII configuration file for an existing
package, then re-apply the configuration using the cmapplyconf command. | | | | | NOTE: When package switching is disabled, a package does not automatically
start at cluster startup time. Therefore, setting AUTO_RUN(PKG_SWITCHING_ENABLED) to NO means that primary packages in recovery groups must be started manually
on the primary cluster. They also must be manually enabled for local
switching, using the cmmodpkg -e <packagename> command. | | | | |
Test local failover of
the packages. In our sample case, this would mean enabling package
switching for salespkg (cmmodpkg -e salespkg) and then testing
that salespkg fails over from LAnode1 to LAnode2. If using logical data
replication, configure and test the data sender package if one is
needed.
| | | | | NOTE: If you are configuring Oracle RAC instances in
Serviceguard packages in a CFS or CVM environment, do not specify
the CVM_DISK_GROUPS, and CVM_ACTIVATION_CMD fields in the package control
scripts as CVM disk group manipulation is addressed by the disk group
multi-node package. | | | | |
The primary cluster is shown in Figure 2-5. Configuring a Cluster with Recovery Packages | |
Use the following steps and the instructions in
chapters 4 through 7 of the Managing Serviceguard user’s guide
as guidelines for creating a new Recovery Cluster or preparing an
existing cluster to run in a Continentalclusters environment: Configure all hardware.
Make sure the cluster hardware is able to handle the task of running
any or all packages it supports in the Continentalclusters configuration: If this is a new cluster,
make sure the hardware is similar to that of the other cluster. The
recovery cluster must be built using servers of sufficient size and
resources so that they can take over packages on recovery and also
be able to run their own packages, if required. If this is an existing
cluster, determine whether it is necessary to add disks for data replication.
This is needed to ensure that there is enough capacity from system
resources to run all packages if applications fail over to the other
cluster. If not, either add nodes to the existing cluster, or move
less critical packages to another cluster.
For new clusters, install
minimum required versions of HP-UX and Serviceguard. For existing
clusters, perform a rolling upgrade to the minimum required versions
of HP-UX and Serviceguard if necessary. Coordinate with the other
site to make sure the same versions and patches are installed at both
sites. This may include coordinating between HP support personnel
if the sites have separate support contracts. Configure logical volumes,
using the same names on both the clusters. If your cluster uses a
physical data replication method and if data replication between the
disk arrays at the different data centers has already taken place, vgimport and vgchange can be used to
help configure the logical volumes on the Recovery Cluster. Use cmgetconf to capture the other cluster’s configuration. Then use cmquerycl on this cluster to generate a new ASCII file
for the recovery configuration. Modify the node names, volume group
names, resource names, and subnets as appropriate so that the two
clusters will be consistent. See chapter 5 in the Managing Serviceguard
user’s guide for details on cluster configuration. Set up the recovery package(s): Copy the package files
from the other cluster in the recovery pair for all mission critical
applications to be monitored by Continentalclusters. In the sample
configuration this means copying the ASCII files salespkg.configand custpkg.config, and the control scripts salespkg.cntl and custpkg.cntl. (If preferred rename the package configuration
files using a naming convention that identifies a package is a Continentalclusters
monitored package. For example, if preferred, name the sample package salespkg_bak.config to indicate that it is the backup
or recovery package.) Edit the package configuration
files, replacing node names, subnets, and other elements as needed.
For all recovery packages, be sure that AUTO_RUN (PKG_SWITCHING_ENABLED used prior to Serviceguard
A.11.12) is set to NO in the configuration
file. This will ensure that the recovery packages will not start automatically
when the recovery cluster forms, but only when the cmrecovercl command is issued. The following elements
should be the same in the package configuration for both the primary
and recovery packages: Modify the package control
script (salespkg_bak.cntl), checking for anything
that may be different between clusters: Volume groups (VGs) may be different. IP addresses may be different. Site-specific customer-defined routines (for example
routines that send messages to a local administrator) may be different. Control script files must be executable.
| | | | | NOTE: If you are using physical data replication on the HP StorageWorks
Disk Array XP Series with Continuous Access XP or HP StorageWorks
Disk Array EVA Series with Continuous Access EVA or on the EMC Symmetrix
using EMC SRDF, use the special environment file templates that are
provided by the separately purchased Metrocluster with Continuous
Access XP, or Metrocluster with Continuous Access EVA, or Metrocluster
with EMC SRDF products. | | | | |
Apply the configuration
using cmapplyconf and test the cluster. | | | |  | IMPORTANT: You must halt the primary package and the data sender packages
before you attempt to run or test any recovery packages. | | | | |
Test local failover of
the packages. In our sample case, this would mean enabling package
switching for salespkg_bak (cmmodpkg
-e salespkg_bak) and then testing that salespkg_bak fails over from NYnode1 to NYnode2. If you are using logical
data replication, configure, apply, and test the data receiver package
if one is needed. Create a package control
script. # cmmakepkg -s pkgname.cntl Customize the control script as appropriate to
your application using the guidelines in the Managing Serviceguard user’s guide. Standard 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.
The New York cluster is shown in Figure 2-6. |
Printable version
