Managing HP Serviceguard A.11.20.10 for Linux, December 2012

Note that the nodes will be tried in the order of pkg1’s node_name list, and pkg2 will be
dragged to the first suitable node on that list whether or not it is currently running on another
node.
• On failover:
If pkg1 fails on node1, pkg1 will select node2 to fail over to (or node3 if it can run
there and node2 is not available or does not meet all of its dependencies; etc.)
◦
◦ pkg2 will be dragged to whatever node pkg1 has selected, and restart there; then pkg1
will restart there.
• On failback:
◦ If both packages have moved to node2 and node1 becomes available, pkg1 will fail
back to node1 if both packages can run there;
– otherwise, neither package will fail back.
4.8.7.3 Guidelines for Simple Dependencies
As you can see from the above Dragging Rules for Simple Dependencies, if pkg1 depends on
pkg2, it can sometimes be a good idea to assign a higher priority to pkg1, because that provides
the best chance for a successful failover (and failback) if pkg1 fails.
But you also need to weigh the relative importance of the packages. If pkg2 runs a database that
is central to your business, you probably want it to run undisturbed, no matter what happens to
application packages that depend on it. In this case, the database package should have the highest
priority.
Note that, if no priorities are set, the dragging rules favor a package that is depended on over a
package that depends on it.
Consider assigning a higher priority to a dependent package if it is about equal in real-world
importance to the package it depends on; otherwise assign the higher priority to the more important
package, or let the priorities of both packages default.
You also need to think about what happens when a package fails. If other packages depend on
it, Serviceguard will halt those packages (and any packages that depend on them, etc.) This
happens regardless of the priority of the failed package.
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 172).
If you set successor_halt_timeout to zero, Serviceguard will halt the dependent packages
in parallel with the failed package; if you set it 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.
If you decide to create dependencies between packages, it is a good idea to test thoroughly,
before putting the packages into production, to make sure that package startup, halt, failover, and
failback behavior is what you expect.
4.8.7.4 Extended Dependencies
To the capabilities provided by Simple Dependencies (page 108), extended dependencies add the
following:
112 Planning and Documenting an HA Cluster