NOTE: pkg1 can depend on more than one other package, and pkg2 can depend on another package or packages; we are assuming only two packages in order to make the rules as clear as possible.

pkg1 will not start on any node unless pkg2 is running on that node.

pkg1’s package_type (page 234) and failover_policy (page 237) 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 node_name list (page 235) 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 239), 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 238). See “Dragging Rules for Simple Dependencies” (page 139).

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 a pkg3 that depends on pkg1, pkg1 will wait forever for pkg3). You can modify this behavior by means of the successor_halt_timeout parameter (page 237). (The successor of a package depends

138 Planning and Documenting an HA Cluster

Page 138
Image 138
HP Serviceguard manual Planning and Documenting an HA Cluster