 |
» |
|
|
|
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 data is replicated between
the shared disk arrays. | | | |  | 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 installed along with Metrocluster
CA XP or Metrocluster CA EVA or Metrocluster/SRDF software. Refer
to Chapters 5 and 6 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 4-4 “Continentalclusters Data Replication Package
Structure” shows the types
of packages that are needed for each type of data replication. Table 4-4 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 CA | Yes | No | Yes | No | | EVA Series CA | 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 in chapters 4
through 7 of Managing Serviceguard manual as guidelines for creating a new cluster or
preparing an existing cluster to run in a Continentalclusters environment: If you are creating a new cluster,
install required versions (or later) of HP-UX and Serviceguard. If
you are 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 required version. 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 Managing Serviceguard manual. 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 Managing Serviceguard manual. Use the cmapplyconf command to apply the package configuration. Be sure that AUTO_RUN (PKG_SWITCHING_ENABLED) 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 you change the setting of the PKG_SWITCHING_ENABLED parameter to NO in the ASCII configuration file for an existing
package, you must 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, if that is desired, 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 you are using logical data replication, configure
and test the data sender package if one is needed.
The primary cluster is shown in Figure 4-5 “Sample
Local Cluster Configuration ”.
Configuring
a Cluster with Recovery Packages | |
Use the following steps and the instructions in chapters 4
through 7 of Managing Serviceguard manual 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. For example,
if V class HP 9000 systems comprise one cluster, they should
be used to build the other. If this is an existing cluster, determine whether
you need 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 Managing Serviceguard manual 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.config and custpkg.config, and the
control scripts salespkg.cntl and custpkg.cntl. (You may want to rename the package configuration files
using a naming convention that lets you know that a package is a Continentalclusters monitored
package. For example, you may want to 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 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 will 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 CA XP, Metrocluster
CA EVA and Metrocluster/SRDF products. | | | | |
Apply the configuration using cmapplyconf and test the cluster. 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 with the command: # cmmakepkg -s pkgname.cntl Customize the control script as appropriate to your application
using the guidelines in Managing Serviceguard. 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 4-6 “Sample
Cluster Configuration with Recovery Packages”.
|
Printable version
