Rules for different_node and any_node Dependencies

These rules apply to packages whose dependency_condition is UP and whose dependency_location is different_node or any_node. For same-node dependencies, see Simple Dependencies (page 137); for exclusionary dependencies, see “Rules for Exclusionary Dependencies” (page 142).

Both packages must be failover packages whose failover_policy (page 237) is configured_node.

The priority (page 238) of the package depended on must be higher than or equal to the priority of the dependent package and the priorities of that package's dependents.

For example, if pkg1 has a different_node or any_node dependency on pkg2, pkg2's priority must be higher than or equal to pkg1's priority and the priority of any package that depends on pkg1 to be UP. pkg2's node order dominates when Serviceguard is placing the packages.

A package cannot depend on itself, directly or indirectly.

For example, 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.

“Dragging” rules apply. See “Dragging Rules for Simple Dependencies” (page 139).

What Happens when a Package Fails

This discussion applies to packages that have dependents, or are depended on, or both (UP dependencies only). When such a package fails, Serviceguard does the following:

1.Halts the packages that depend on the failing package, if any.

Serviceguard halts the dependent packages (and any packages that depend on them, etc.) This happens regardless of the priority of the failed package.

NOTE: Dependent packages are halted even in the case of different_node or any_node dependency. For example if pkg1 running on node1 has a different_node or any_node dependency on pkg2 running on node2, and pkg2 fails over to node3, pkg1 will be halted and restarted as described below.

By default the packages are halted in the reverse of the order in which they were started; and if the halt script for any of the dependent packages hangs, the failed package will wait indefinitely to complete its own halt process. This provides the best chance for all the dependent packages to halt cleanly, but it may not be the behavior you want. You can change it by means of the successor_halt_timeout parameter (page 237). (A successor is a package that depends on another package.)

If the failed package's successor_halt_timeout is set to zero, Serviceguard will halt the dependent packages in parallel with the failed package; if it is set to a positive number, Serviceguard will halt the packages in the reverse of the start order, but will allow the failed package to halt after the successor_halt_timeout number of seconds whether or not the dependent packages have completed their halt scripts.

2.Halts the failing package.

After the successor halt timer has expired or the dependent packages have all halted, Serviceguard starts the halt script of the failing package, regardless of whether the dependents' halts succeeded, failed, or timed out.

Package Configuration Planning 143

Page 143
Image 143
HP Serviceguard manual What Happens when a Package Fails, Rules for differentnode and anynode Dependencies