This section provides examples of common tasks you perform for HP XC systems that use HP Serviceguard as the availability tool. For more in-depth information on Serviceguard, see the HP Serviceguard documentation at the following Web site:
http://docs.hp.com/en/ha.html#Serviceguard
Each availability set relates to a corresponding Serviceguard cluster.
 |
 |  |
 |
 | NOTE: In the examples in this section, assume the PATH environment variable has been updated for Serviceguard commands. |
 |
 |  |
 |
Moving Packages |
 |
The following example describes how to relocate packages manually within a Serviceguard cluster (availability set). You can use the steps shown in this example to failback HP Serviceguard packages manually after an automatic failover.
Nodes n12 and n13 are assigned to an HP Serviceguard cluster. A package named pack1 runs on node n12.
Use the cmhaltpkg command to halt the pack1 package on node n12:
# pdsh -w n12 cmhaltpkg pack1 |
After the pack1 package stops, run the package on node n13:
# pdsh -w n13 cmrunpkg -n n11 pack1 |
Note that the command is issued on node n12 to run the package on n13.
Enable automatic failover of the HP Serviceguard package:
# pdsh -w n13 cmmodpkg -e pack1 |
Reimaging Nodes in the Availability Set |
 |
Reimaging a node is the means by which you update software on a node from a central repository, called a golden master. Chapter 10 discusses this topic in detail.
Nodes must be stopped and restarted during the reimaging process.
When a node is reimaged, but its partner in an availability set is still running, the reimaged node comes under the control of the availability tool automatically.
When both or all the nodes in an availability set are down, you must use the transfer_to_avail command on the head node to transfer control of services to the availability tool.
Consider the example of two HP Serviceguard clusters: one comprising nodes n12 and n13, and the other comprising nodes n14 and n16. Node n16 is the head node. The sequence of events is as follows:
The golden image on node n16 is updated so that the software can be propagated to the other nodes.
Nodes n12, n13, and n14 are stopped so that they can be reimaged.
Node n16 is still running.
When node n14 starts up again, it automatically joins its Serviceguard cluster. It does so because node n16, its partner, is up and running a Serviceguard cluster.
When nodes n12 and n13 start up, they do not form their Serviceguard cluster. You must issue the transfer_to_avail command on the head node to transfer control of services to their Serviceguard cluster. In this example, the transfer_to_avail command is run on the head node. This command ignores Serviceguard clusters that are already running and start the other clusters that are not.
Both nodes, n12 and n13, are up because they are reimaged. The control of their services is transferred to Serviceguard.