Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 13. Determining the order in which cluster resources are run

To determine the order in which the resources run, you must 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]

For example the following command configures an ordering constraint to ensure that the resource firstresource starts first, before the resource secondresource. 

# pcs constraint order start firstresource then secondresource

The following table summarizes the properties and options for configuring ordering constraints.

Expand
Table 13.1. Properties of an Order Constraint
FieldDescription

resource_id

The name of a resource on which an action is performed.

action

The action to be ordered on the resource. Possible values of the action property are as follows:

* start - Order start actions of the resource.

* stop - Order stop actions of the resource.

* promote - Promote the resource from an unpromoted resource to a promoted resource.

* demote - Demote the resource from a promoted resource to an unpromoted resource.

If no action is specified, the default action is start.

kind option

How to enforce the constraint. The possible values of the kind option are as follows:

* Optional - Only applies if both resources are executing the specified action.

* Mandatory - Always enforce the constraint (default value). If the first resource you specified is stopping or cannot be started, the second resource you specified must be stopped.

* Serialize - Ensure that no two stop/start actions occur concurrently for the resources you specify. The first and second resource you specify can start in either order, but one must complete starting before the other can be started. A typical use case is when resource startup puts a high load on the host.

symmetrical option

If true, the reverse of the constraint applies for the opposite action (for example, if B starts after A starts, then B stops before A stops). Ordering constraints for which kind is Serialize cannot be symmetrical. The default value is true for Mandatory and Optional kinds, false for Serialize.

Displaying ordering constraints

The following command lists all current ordering constraints. 

# pcs constraint order [config]

You can display all current location, order, and colocation constraints with the following command. To show the internal constraint IDS, specify the --full option. 

# pcs constraint [config] [--full]

By default, listing resource constraints does not display expired constraints. To include expired constaints in the listing, use the --all option of the pcs constraint command. This will list expired constraints, noting the constraints and their associated rules as (expired) in the display.

The following command lists the constraints that reference specific resources. 

# pcs constraint ref resource ...
Removing resources from an ordering constraint

Use the following command to remove resources from any ordering constraint. 

# pcs constraint order remove resource1 [resourceN]...

13.1. Configuring mandatory ordering
Copy link

A mandatory ordering constraint ensures the second resource waits for the first to complete its action. Valid actions include start, stop, promote, and demote. For example, "start A then start B" prevents B from starting until A succeeds. To enable this, set the kind option to Mandatory or use the default.

If the symmetrical option is set to true or left to default, the opposite actions will be ordered in reverse. The start and stop actions are opposites, and demote 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.

13.2. Configuring advisory ordering
Copy link

When the 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.

Procedure

  • Configure an advisory ordering constraint for the resources named VirtualIP and dummy_resource: 

    # pcs constraint order VirtualIP then dummy_resource kind=Optional

13.3. Configuring ordered resource sets
Copy link

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.

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 true or false to indicate whether the set of resources must be ordered relative to each other. The default value is true.

    Setting sequential to false allows 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 true or false to indicate whether all of the resources in the set must be active before continuing. Setting require-all to false means that only one resource in the set needs to be started before continuing on to the next set. Setting require-all to false has no effect unless used in conjunction with unordered sets, which are sets for which sequential is set to false. The default value is true.
  • action, which can be set to start, promote, demote or stop.
  • role, which can be set to Stopped, Started, Promoted, or Unpromoted.

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.
  • symmetrical, to set whether the reverse of the constraint applies for the opposite action. 
# pcs constraint order set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]

If you have three resources named D1, D2, and D3, the following command configures them as an ordered resource set. 

# pcs constraint order set D1 D2 D3

If you have six resources named A, B, C, D, E, and F, this example configures an ordering constraint for the set of resources that will start as follows:

  • A and B start independently of each other
  • C starts once either A or B has started
  • D starts once C has started
  • E and F start independently of each other once D has started

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

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 systemd 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.

If a cluster includes a resource that depends on the external service foo that is not managed by the cluster, you can configure a startup order for an external service.

Procedure

  1. Create the drop-in unit /etc/systemd/system/resource-agents-deps.target.d/foo.conf that contains the following: 

    [Unit]
Requires=foo.service
After=foo.service

  2. Run the systemctl daemon-reload command: 

    # systemctl daemon-reload

Cluster dependencies extend beyond services. For example, you can configure a dependency on mounting a file system at /srv.

Procedure

  1. Ensure that /srv is listed in the /etc/fstab file. This will be converted automatically to the systemd file srv.mount at 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 on your system.

  2. 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.conf that contains the following: 

    [Unit]
Requires=srv.mount
After=srv.mount

  3. Run the systemctl daemon-reload command: 

    # systemctl daemon-reload

If an LVM volume group used by a Pacemaker cluster contains one or more physical volumes that reside on remote block storage, such as an iSCSI target, you can configure a systemd resource-agents-deps target and a systemd drop-in unit for the target to ensure that the service starts before Pacemaker starts.

The following procedure configures blk-availability.service as a dependency. The blk-availability.service service is a wrapper that includes iscsi.service, among other services. If your deployment requires it, you could configure iscsi.service (for iSCSI only) or remote-fs.target as the dependency instead of blk-availability.

Procedure

  1. Create the drop-in unit /etc/systemd/system/resource-agents-deps.target.d/blk-availability.conf that contains the following: 

    [Unit]
Requires=blk-availability.service
After=blk-availability.service

  2. Run the systemctl daemon-reload command: 

    # systemctl daemon-reload
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top