 |
» |
|
|
|
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-4 “Continentalclusters Data Replication Package
Structure” shows the types
of packages that are needed for each type of data replication. Table 2-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 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 “Sample
Local Cluster Configuration ”.
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.config and 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 “Sample
Cluster Configuration with Recovery Packages”.
|
Printable version
