Chapter 12. Determining the order in which cluster resources are run
To determine the order in which the resources run, you configure an ordering constraint.
The following shows the format for the command to configure an ordering constraint.
pcs constraint order [action] resource_id then [action] resource_id [options]
Table 12.1, “Properties of an Order Constraint”, summarizes the properties and options for configuring ordering constraints.
Table 12.1. Properties of an Order Constraint
The name of a resource on which an action is performed.
The action to perform on a resource. Possible values of the action property are as follows:
If no action is specified, the default action is
| || |
How to enforce the constraint. The possible values of the
| || |
If true, the reverse of the constraint applies for the opposite action (for example, if B starts after A starts, then B stops before Ordering constraints for which
Use the following command to remove resources from any ordering constraint.
pcs constraint order remove resource1 [resourceN]...
12.1. Configuring mandatory ordering
A mandatory ordering constraint indicates that the second action should not be initiated for the second resource unless and until the first action successfully completes for the first resource. Actions that may be ordered are
start, and additionally for promotable clones,
promote. For example, "A then B" (which is equivalent to "start A then start B") means that B will not be started unless and until A successfully starts. An ordering constraint is mandatory if the
kind option for the constraint is set to
Mandatory or left as default.
symmetrical option is set to
true or left to default, the opposite actions will be ordered in reverse. The
stop actions are opposites, and
promote are opposites. For example, a symmetrical "promote A then start B" ordering implies "stop B then demote A", which means that A cannot be demoted until and unless B successfully stops. A symmetrical ordering means that changes in A’s state can cause actions to be scheduled for B. For example, given "A then B", if A restarts due to failure, B will be stopped first, then A will be stopped, then A will be started, then B will be started.
Note that the cluster reacts to each state change. If the first resource is restarted and is in a started state again before the second resource initiated a stop operation, the second resource will not need to be restarted.
12.2. Configuring advisory ordering
kind=Optional option is specified for an ordering constraint, the constraint is considered optional and only applies if both resources are executing the specified actions. Any change in state by the first resource you specify will have no effect on the second resource you specify.
The following command configures an advisory ordering constraint for the resources named
pcs constraint order VirtualIP then dummy_resource kind=Optional
12.3. Configuring ordered resource sets
A common situation is for an administrator to create a chain of ordered resources, where, for example, resource A starts before resource B which starts before resource C. If your configuration requires that you create a set of resources that is colocated and started in order, you can configure a resource group that contains those resources, as described in Configuring resource groups.
There are some situations, however, where configuring the resources that need to start in a specified order as a resource group is not appropriate:
- You may need to configure resources to start in order and the resources are not necessarily colocated.
- You may have a resource C that must start after either resource A or B has started but there is no relationship between A and B.
- You may have resources C and D that must start after both resources A and B have started, but there is no relationship between A and B or between C and D.
In these situations, you can create an ordering constraint on a set or sets of resources with the
pcs constraint order set command.
You can set the following options for a set of resources with the
pcs constraint order set command.
sequential, which can be set to
falseto indicate whether the set of resources must be ordered relative to each other. The default value is
falseallows a set to be ordered relative to other sets in the ordering constraint, without its members being ordered relative to each other. Therefore, this option makes sense only if multiple sets are listed in the constraint; otherwise, the constraint has no effect.
require-all, which can be set to
falseto indicate whether all of the resources in the set must be active before continuing. Setting
falsemeans that only one resource in the set needs to be started before continuing on to the next set. Setting
falsehas no effect unless used in conjunction with unordered sets, which are sets for which
sequentialis set to
false. The default value is
action, which can be set to
stop, as described in Properties of an Order Constraint.
role, which can be set to
You can set the following constraint options for a set of resources following the
setoptions parameter of the
pcs constraint order set command.
id, to provide a name for the constraint you are defining.
kind, which indicates how to enforce the constraint, as described in Properties of an Order Constraint.
symmetrical, to set whether the reverse of the constraint applies for the opposite action, as described in Properties of an Order Constraint.
pcs constraint order set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]
If you have three resources named
D3, the following command configures them as an ordered resource set.
pcs constraint order set D1 D2 D3
If you have six resources named
F, this example configures an ordering constraint for the set of resources that will start as follows:
Bstart independently of each other
Cstarts once either
Fstart independently of each other once
Stopping the resources is not influenced by this constraint since
symmetrical=false is set.
pcs constraint order set A B sequential=false require-all=false set C D set E F sequential=false setoptions symmetrical=false
12.4. Configuring startup order for resource dependencies not managed by Pacemaker
It is possible for a cluster to include resources with dependencies that are not themselves managed by the cluster. In this case, you must ensure that those dependencies are started before Pacemaker is started and stopped after Pacemaker is stopped.
You can configure your startup order to account for this situation by means of the
resource-agents-deps target. You can create a
systemd drop-in unit for this target and Pacemaker will order itself appropriately relative to this target.
For example, if a cluster includes a resource that depends on the external service
foo that is not managed by the cluster, perform the following procedure.
Create the drop-in unit
/etc/systemd/system/resource-agents-deps.target.d/foo.confthat contains the following:
[Unit] Requires=foo.service After=foo.service
A cluster dependency specified in this way can be something other than a service. For example, you may have a dependency on mounting a file system at
/srv, in which case you would perform the following procedure:
/srvis listed in the
/etc/fstabfile. This will be converted automatically to the
srv.mountat boot when the configuration of the system manager is reloaded. For more information, see the
systemd.mount(5) and the
systemd-fstab-generator(8) man pages.
To make sure that Pacemaker starts after the disk is mounted, create the drop-in unit
/etc/systemd/system/resource-agents-deps.target.d/srv.confthat contains the following.
[Unit] Requires=srv.mount After=srv.mount