Managing HP Serviceguard A.11.20.20 for Linux, March 2014

• pkg1 will not start on any node unless pkg2 is running on that node.
• pkg1’s package_type (page 175) and failover_policy (page 178) constrain the type
and characteristics of pkg2, as follows:
◦ If pkg1 is a multi-node package, pkg2 must be a multi-node or system multi-node package.
(Note that system multi-node packages are not supported for general use.)
◦ If pkg1 is a failover package and its failover_policy is min_package_node, pkg2
must be a multi-node or system multi-node package.
◦ If pkg1 is a failover package and its failover_policy is configured_node, pkg2
must be:
– a multi-node or system multi-node package, or
– a failover package whose failover_policy is configured_node.
• pkg2 cannot be a failover package whose failover_policy is min_package_node.
• pkg2’s node_name list (page 176) must contain all of the nodes on pkg1’s.
This means that if pkg1 is configured to run on any node in the cluster (*), pkg2 must
also be configured to run on any node.
◦
NOTE: If pkg1 lists all the nodes, rather than using the asterisk (*), pkg2 must also
list them.
◦ Preferably the nodes should be listed in the same order if the dependency is between
packages whose failover_policy is configured_node; cmcheckconf and
cmapplyconf will warn you if they are not.
• A package cannot depend on itself, directly or indirectly.
That is, not only must pkg1 not specify itself in the dependency_condition (page 180), but
pkg1 must not specify a dependency on pkg2 if pkg2 depends on pkg1, or if pkg2 depends
on pkg3 which depends on pkg1, etc.
• If pkg1 is a failover package and pkg2 is a multi-node or system multi-node package, and
pkg2 fails, pkg1 will halt and fail over to the next node on its node_name list on which pkg2
is running (and any other dependencies, such as resource dependencies or a dependency on
a third package, are met).
• In the case of failover packages with a configured_node failover_policy, a set of
rules governs under what circumstances pkg1 can force pkg2 to start on a given node. This
is called dragging and is determined by each package’s priority (page 179). See “Dragging
Rules for Simple Dependencies” (page 115).
• If pkg2 fails, Serviceguard will halt pkg1 and any other packages that depend directly or
indirectly on pkg2.
By default, Serviceguard halts packages in dependency order, the dependent package(s) first,
then the package depended on. In our example, pkg1 would be halted first, then pkg2. If
there were a third package, pkg3, that depended on pkg1, pkg3 would be halted first, then
pkg1, then pkg2.
If the halt script for any dependent package hangs, by default the package depended on will
wait forever (pkg2 will wait forever for pkg1, and if there is apkg3 that depends on pkg1,
pkg1 will wait forever for pkg3). You can modify this behavior by means of the
successor_halt_timeout parameter (page 178)). (The successor of a package depends
on that package; in our example, pkg1 is a successor of pkg2; conversely pkg2 can be
referred to as a predecessor of pkg1.)
114 Planning and Documenting an HA Cluster