HP XC System Software Administration Guide Version 3.1

n14: nagios.n16 up running enabled n16
n14: dbserver.n16 up running enabled n16
The cmviewcl command views the status of all Serviceguard clusters that correspond to the avail1
and avail2 availability sets.
2.4.2 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.
1. Nodes n12 and n13 are assigned to an HP Serviceguard cluster. A package named pack1 runs on
node n12.
2. Use the cmhaltpkg command to halt the pack1 package on node n12:
# pdsh -w n12 cmhaltpkg pack1
3. 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.
4. Enable automatic failover of the HP Serviceguard package:
# pdsh -w n13 cmmodpkg -e pack1
2.4.3 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 (page 129) 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:
1. The golden image on node n16 is updated so that the software can be propagated to the other nodes.
2. Nodes n12, n13, and n14 are stopped so that they can be reimaged.
Node n16 is still running.
3. 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.
4. 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.
# transfer_to_avail
5. Both nodes, n12 and n13, are up because they are reimaged. The control of their services is transferred
to Serviceguard.
46 Improved Availability