Building Disaster Recovery Serviceguard Solutions Using Metrocluster with Continuous Access XP P9000 for Linux B.12.00.00

Table 5 Validating Metrocluster package (continued)
WARNING: Raid Manager is not set to auto start.
You must set the START_RAIDMGR variable value to
1.
For example:
START_RAIDMGR =1
Warns you if the HORCM instance is not configured
in the /etc/mcxpca/raidmgr file.
cmcheckconf [–v]
# cmcheckconf
Verify whether the HORCM instance
is configured in the /etc/mcxpca/
raidmgr file.
WARNING: The HORCM instance <instance> is not
configured in the file /etc/mcxpca/raidmgr.
You must add the HORCM instance in the /etc/
mcxpca/raidmgr file. For example, if you have
RAIDMGR_INSTANCE variable set to instances
"1,2,3" but you have packaged the instance “0”,
then you must add instance “0” to the
RAIDMGR_INSTANCE variable.
For example:
RAIDMGR_INSTANCE = “1,2,3,0”
Rolling upgrade for Metrocluster
Rolling Upgrade allows you to upgrade the software components of the cluster with minimal
downtime to the applications managed by Metrocluster. see Rolling upgrade for the procedure.
Live Application Detach
There may be circumstances in which you want to do maintenance that involves halting a node,
or the entire cluster, without halting or failing over the affected packages. Such maintenance might
consist of anything short of rebooting the node or nodes, but a likely case is networking changes
that will disrupt the heartbeat. New command options in Serviceguard for Linux A.11.20.10
(collectively known as Live Application Detach (LAD)) allows you to do this kind of maintenance
while keeping the packages running. The packages are no longer monitored by Serviceguard, but
the applications continue to run. Packages in this state are called detached packages. When you
have done the necessary maintenance, you can restart the node or cluster, and normal monitoring
will resume on the packages. For more information on the LAD feature, see Managing HP
Serviceguard A.12.00.00 for Linux available at http://www.hp.com/go/linux-serviceguard-docs.
Remote array RAID manager instance
A remote array RAID Manager instance allows the Metrocluster package to determine the status
of the device group on the remote XP or P9000 array even when the remote hosts are down or
are inaccessible due to a network link failure. The remote array RAID Manager instance is configured
on a node using the command device of the remote XP or P9000 array.
In a Metrocluster environment with Continuous Access XP or P9000, the array at every site is
interfaced only with the Metrocluster nodes in the same site using a command device in the array.
When a Metrocluster package starts up on a node, the RAID Manager instance in the site
communicates with the RAID Manager instance at the remote site to obtain the Continuous Access
device group status. In situations where the remote hosts are down or are inaccessible due to a
network link failure, the Continuous Access device group status cannot be determined. This occurs
even when the remote array is up. Since currentness of data cannot be determined, the Metrocluster
package startup fails for packages that have the AUTO_NONCURDATA parameter set to 0.
Similarly, in a 2-node Metrocluster configuration that has a single node at every site, any node
failure results in the other node not being able to determine the device group status. The subsequent
failover of the Metrocluster packages to the surviving node might not succeed either.
Rolling upgrade for Metrocluster 29