Managing HP Serviceguard A.11.20.10 for Linux, December 2012

these are failover packages, and
the failing package can “drag” these packages to a node on which they can all run.
Otherwise the failing package halts and the packages it depends on continue to run
4. Starts the packages the failed package depends on (those halted in step 3, if any).
If the failed package has been able to drag the packages it depends on to the adoptive node,
Serviceguard starts them in the reverse of the order it halted them in the previous step (that is,
the package that does not depend on any other package is started first).
5. Starts the failed package.
6. Starts the packages that depend on the failed package (those halted in step 1).
7. If a package has the all_nodes dependency, and if the package changes to halt_aborted
state, the dependent package does not start. However, if the dependency_condition is
same_node or any_node, the dependent package is started, even if the dependent package
is in halt_aborted state.
4.8.9 For More Information
For more information, see:
The parameter descriptions for priority (page 173) and dependency_ (page 174), and the
corresponding comments in the package configuration template file
The cmmakepkg (1m) manpage
The white paper Serviceguard’s Package Dependency Feature, which you can find at http://
www.hp.com/go/hpux-serviceguard-docs
4.8.10 About Package Weights
Package weights and node capacities allow you to restrict the number of packages that can run
concurrently on a given node, or, alternatively, to limit the total package “weight” (in terms of
resource consumption) that a node can bear.
For example, suppose you have a two-node cluster consisting of a large system and a smaller
system. You want all your packages to be able to run on the large system at the same time, but,
if the large node fails, you want only the critical packages to run on the smaller system. Package
weights allow you to configure Serviceguard to enforce this behavior.
4.8.10.1 Package Weights and Node Capacities
You define a capacity, or capacities, for a node (in the cluster configuration file), and corresponding
weights for packages (in the package configuration file).
Node capacity is consumed by package weights. Serviceguard ensures that the capacity limit you
set for a node is never exceeded by the combined weight of packages running on it; if a node's
available capacity will be exceeded by a package that wants to run on that node, the package
will not run there. This means, for example, that a package cannot fail over to a node if that node
does not currently have available capacity for it, even if the node is otherwise eligible to run the
package unless the package that wants to run has sufficient priority to force one of the packages
that are currently running to move; see “How Package Weights Interact with Package Priorities
and Dependencies” (page 121).
4.8.10.2 Configuring Weights and Capacities
You can configure multiple capacities for nodes, and multiple corresponding weights for packages,
up to four capacity/weight pairs per cluster. This allows you considerable flexibility in managing
package use of each node's resources — but it may be more flexibility than you need. For this
reason Serviceguard provides two methods for configuring capacities and weights: a simple method
and a comprehensive method. The subsections that follow explain each of these methods.
4.8 Package Configuration Planning 115