Managing Serviceguard A.11.20, March 2013

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.
Guidelines for Simple Dependencies
As you can see from the “Dragging Rules for Simple Dependencies” (page 144), 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; see “What Happens when a
Package Fails” (page 149).
Extended Dependencies
To the capabilities provided by Simple Dependencies (page 143), extended dependencies add the
following:
• You can specify whether the package depended on must be running or must be down.
You define this condition by means of the dependency_condition, using one of the literals
UP or DOWN (the literals can be upper or lower case). We'll refer to the requirement that
another package be down as an exclusionary dependency; see “Rules for Exclusionary
Dependencies” (page 148).
• You can specify where the dependency_condition must be satisfied: on the same node,
a different node, all nodes, or any node in the cluster.
You define this by means of the dependency_location parameter (page 244), using one
of the literals same_node, different_node, all_nodes, or any_node.
different_node and any_node are allowed only if dependency_condition is UP.
all_nodes is allowed only if dependency_condition is DOWN.
See “Rules for different_node and any_node Dependencies” (page 148).
For more information about the dependency_ parameters, see the definitions starting with
“dependency_name” (page 242), and the cmmakepkg (1m) manpage.
Package Configuration Planning 147