Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 56. 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]
The following table summarizes the properties and options for configuring ordering constraints.
Field | Description |
---|---|
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:
*
*
*
*
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 A stops). Ordering constraints for which |
Use the following command to remove resources from any ordering constraint.
pcs constraint order remove resource1 [resourceN]...
56.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 stop
, start
, and additionally for promotable clones, demote
and 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.
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.
56.2. Configuring advisory ordering
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.
The following command configures an advisory ordering constraint for the resources named VirtualIP
and dummy_resource
.
# pcs constraint order VirtualIP then dummy_resource kind=Optional
56.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.
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 totrue
orfalse
to indicate whether the set of resources must be ordered relative to each other. The default value istrue
.Setting
sequential
tofalse
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 totrue
orfalse
to indicate whether all of the resources in the set must be active before continuing. Settingrequire-all
tofalse
means that only one resource in the set needs to be started before continuing on to the next set. Settingrequire-all
tofalse
has no effect unless used in conjunction with unordered sets, which are sets for whichsequential
is set tofalse
. The default value istrue
. -
action
, which can be set tostart
,promote
,demote
orstop
, as described in the "Properties of an Order Constraint" table in Determining the order in which cluster resources are run. -
role
, which can be set toStopped
,Started
,Master
, orSlave
. As of RHEL 8.5, thepcs
command-line interface acceptsPromoted
andUnpromoted
as a value forrole
. ThePromoted
andUnpromoted
roles are the functional equivalent of theMaster
andSlave
roles.
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 the "Properties of an Order Constraint" table in Determining the order in which cluster resources are run. -
symmetrical
, to set whether the reverse of the constraint applies for the opposite action, as described in in the "Properties of an Order Constraint" table in Determining the order in which cluster resources are run.
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
andB
start independently of each other -
C
starts once eitherA
orB
has started -
D
starts onceC
has started -
E
andF
start independently of each other onceD
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
56.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 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.
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.conf
that contains the following:[Unit] Requires=foo.service After=foo.service
-
Run the
systemctl daemon-reload
command.
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:
-
Ensure that
/srv
is listed in the/etc/fstab
file. This will be converted automatically to thesystemd
filesrv.mount
at boot when the configuration of the system manager is reloaded. For more information, see thesystemd.mount
(5) and thesystemd-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.conf
that contains the following.[Unit] Requires=srv.mount After=srv.mount
-
Run the
systemctl daemon-reload
command.
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
.
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
-
Run the
systemctl daemon-reload
command.