Managing Serviceguard A.11.20, March 2013

NOTE: Check the Serviceguard/SGeRAC/SMS/Serviceguard Manager Plug-in Compatibility
and Feature Matrix and the latest Release Notes for your version of Serviceguard for up-to-date
information on CVM and CFS support: http://www.hp.com/go/hpux-serviceguard-docs.
Changes that Will Trigger Warnings
Changes to the following will trigger warnings, giving you a chance to cancel, if the change would
cause the package to fail.
NOTE: You will not be able to cancel if you use cmapplyconf -f.
• Package nodes
• Package dependencies
• Package weights (and also node capacity, defined in the cluster configuration file)
• Package priority
• auto_run
• failback_policy
Responding to Cluster Events
Serviceguard does not require much ongoing system administration intervention. As long as there
are no failures, your cluster will be monitored and protected. In the event of a failure, those packages
that you have designated to be transferred to another node will be transferred automatically. Your
ongoing responsibility as the system administrator will be to monitor the cluster and determine if
a transfer of package has occurred. If a transfer has occurred, you have to determine the cause
and take corrective actions.
The Event Monitoring Service and its HA monitors can provide monitoring for disks, NICs, and
some system events. Refer to the manual Using HA Monitors for more information.
The typical corrective actions to take in the event of a transfer of package include:
• Determining when a transfer has occurred.
• Determining the cause of a transfer.
• Repairing any hardware failures.
• Correcting any software problems.
• Restarting nodes.
• Transferring packages back to their original nodes.
Single-Node Operation
In a multi-node cluster, you could have a situation in which all but one node has failed, or you
have shut down all but one node, leaving your cluster in single-node operation. This remaining
node will probably have applications running on it. As long as the Serviceguard daemon cmcld
is active, other nodes can rejoin the cluster.
If the Serviceguard daemon fails when in single-node operation, it will leave the single node up
and your applications running. (This is different from the loss of the Serviceguard daemon in a
multi-node cluster, which halts the node with a TOC, and causes packages to be switched to
adoptive nodes.) It is not necessary to halt the single node in this scenario, since the application
is still running, and no other node is currently available for package switching.
You should not try to restart Serviceguard, since data corruption might occur if another node were
to attempt to start up a new instance of the application that is still running on the single node.
Responding to Cluster Events 325