Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
Chapter 7. Resource Constraints
You can determine the behavior of a resource in a cluster by configuring constraints for that resource. You can configure the following categories of constraints:
locationconstraints — A location constraint determines which nodes a resource can run on. Location constraints are described in Section 7.1, “Location Constraints”.orderconstraints — An order constraint determines the order in which the resources run. Order constraints are described in Section 7.2, “Order Constraints”.colocationconstraints — A colocation constraint determines where resources will be placed relative to other resources. Colocation constraints are described in Section 7.3, “Colocation of Resources”.
As a shorthand for configuring a set of constraints that will locate a set of resources together and ensure that the resources start sequentially and stop in reverse order, Pacemaker supports the concept of resource groups. For information on resource groups, see Section 6.5, “Resource Groups”.
7.1. Location Constraints
Location constraints determine which nodes a resource can run on. You can configure location constraints to determine whether a resource will prefer or avoid a specified node.
In addition to location constraints, the node on which a resource runs is influenced by the
resource-stickiness value for that resource, which determines to what degree a resource prefers to remain on the node where it is currently running. For information on setting the resource-stickiness value, see Section 7.1.5, “Configuring a Resource to Prefer its Current Node”.
7.1.1. Basic Location Constraints
You can configure a basic location constraint to specify whether a resource prefers or avoid a node, with an optional
score value to indicate the relative degree of preference for the constraint.
The following command creates a location constraint for a resource to prefer the specified node or nodes. Note that it is possible to create constraints on a particular resource for more than one node with a single command.
pcs constraint location rsc prefers node[=score] [node[=score]] ...
The following command creates a location constraint for a resource to avoid the specified node or nodes.
pcs constraint location rsc avoids node[=score] [node[=score]] ...
Table 7.1, “Simple Location Constraint Options” summarizes the meanings of the options for configuring location constraints in their simplest form.
Table 7.1. Simple Location Constraint Options
| Field | Description |
|---|---|
rsc
|
A resource name
|
node
|
A node’s name
|
score
|
Postive integer value to indicate the preference for whether a resource should prefer or avoid a node.
INFINITY is the default score value for a resource location constraint.
A value of
INFINITY for score in a pcs contraint location rsc prefers command indicates that the resource will prefer that node if the node is available, but does not prevent the resource from running on another node if the specified node is unavailable.
A value of
INFINITY for score in a pcs contraint location rsc avoids command indicates that the resource will never run on that node, even if no other node is available. This is the equivalent of setting a pcs constraint location add command with a score of -INFINITY.
|
The following command creates a location constraint to specify that the resource
Webserver prefers node node1.
# pcs constraint location Webserver prefers node1
As of Red Hat Enterprise Linux 7.4,
pcs supports regular expressions in location constraints on the command line. These constraints apply to multiple resources based on the regular expression matching resource name. This allows you to configure multiple location contraints with a single command line.
The following command creates a location constraint to specify that resources
dummy0 to dummy9 prefer node1.
# pcs constraint location 'regexp%dummy[0-9]' prefers node1
Since Pacemaker uses POSIX extended regular expressions as documented at http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04, you can specify the same constraint with the following command.
# pcs constraint location 'regexp%dummy[[:digit:]]' prefers node17.1.2. Advanced Location Constraints
When configuring a location constraint on a node, you can use the
resource-discovery option of the pcs constraint location command to indicate a preference for whether Pacemaker should perform resource discovery on this node for the specified resource. Limiting resource discovery to a subset of nodes the resource is physically capable of running on can significantly boost performance when a large set of nodes is present. When pacemaker_remote is in use to expand the node count into the hundreds of nodes range, this option should be considered.
The following command shows the format for specifying the
resource-discovery option of the pcs constraint location command. Note that id is the constraint id. The meanings of rsc, node, and score are summarized in Table 7.1, “Simple Location Constraint Options”. In this command, a positive value for score corresponds to a basic location`constraint that configures a resource to prefer a node, while a negative value for score corresponds to a basic location`constraint that configures a resource to avoid a node. As with basic location constraints, you can use regular expressions for resources with these constraints as well.
pcs constraint location add id rsc node score [resource-discovery=option]
Table 7.2, “Resource Discovery Values” summarizes the meanings of the values you can specify for the
resource-discovery option.
Table 7.2. Resource Discovery Values
| Value | Description |
|---|---|
always
|
Always perform resource discovery for the specified resource on this node. This is the default
resource-discovery value for a resource location constraint.
|
never
|
Never perform resource discovery for the specified resource on this node.
|
exclusive
|
Perform resource discovery for the specified resource only on this node (and other nodes similarly marked as
exclusive). Multiple location constraints using exclusive discovery for the same resource across different nodes creates a subset of nodes resource-discovery is exclusive to. If a resource is marked for exclusive discovery on one or more nodes, that resource is only allowed to be placed within that subset of nodes.
|
Note that setting the
resource-discovery option to never or exclusive allows the possibility for the resource to be active in those locations without the cluster’s knowledge. This can lead to the resource being active in more than one location if the service is started outside the cluster's control (for example, by systemd or by an administrator). This can also occur if the resource-discovery property is changed while part of the cluster is down or suffering split-brain, or if the resource-discovery property is changed for a resource and node while the resource is active on that node. For this reason, using this option is appropriate only when you have more than eight nodes and there is a way to guarantee that the resource can run only in a particular location (for example, when the required software is not installed anywhere else).
7.1.3. Using Rules to Determine Resource Location
For more complicated location constraints, you can use Pacemaker rules to determine a resource's location. For general information about Pacemaker rules and the properties you can set, see Chapter 11, Pacemaker Rules.
Use the following command to configure a Pacemaker constraint that uses rules. If
score is omitted, it defaults to INFINITY. If resource-discovery is omitted, it defaults to always. For information on the resource-discovery option, see Section 7.1.2, “Advanced Location Constraints”. As with basic location constraints, you can use regular expressions for resources with these constraints as well.
When using rules to configure location constraints, the value of
score can be positive or negative, with a positive value indicating "prefers" and a negative value indicating "avoids".
pcs constraint location rsc rule [resource-discovery=option] [role=master|slave] [score=score | score-attribute=attribute] expression
The expression option can be one of the following where duration_options and date_spec_options are: hours, monthdays, weekdays, yeardays, months, weeks, years, weekyears, moon as described in Table 11.5, “Properties of a Date Specification”.
defined|not_defined attributeattribute lt|gt|lte|gte|eq|ne [string|integer|version] valuedate gt|lt datedate in-range date to datedate in-range date to duration duration_options ...date-spec date_spec_optionsexpression and|or expression(expression)
The following location constraint configures an expression that is true if now is any time in the year 2018.
# pcs constraint location Webserver rule score=INFINITY date-spec years=2018
The following command configures an expression that is true from 9 am to 5 pm, Monday through Friday. Note that the hours value of 16 matches up to 16:59:59, as the numeric value (hour) still matches.
# pcs constraint location Webserver rule score=INFINITY date-spec hours="9-16" weekdays="1-5"
The following command configures an expression that is true when there is a full moon on Friday the thirteenth.
# pcs constraint location Webserver rule date-spec weekdays=5 monthdays=13 moon=47.1.4. Location Constraint Strategy
Using any of the location constraints described in Section 7.1.1, “Basic Location Constraints”, Section 7.1.2, “Advanced Location Constraints”, and Section 7.1.3, “Using Rules to Determine Resource Location” you can configure a general strategy for specifying which nodes a resources can run on:
- Opt-In Clusters — Configure a cluster in which, by default, no resource can run anywhere and then selectively enable allowed nodes for specific resources. The procedure for configuring an opt-in cluster is described in Section 7.1.4.1, “Configuring an "Opt-In" Cluster”.
- Opt-Out Clusters — Configure a cluster in which, by default, all resources can run anywhere and then create location constraints for resources that are not allowed to run on specific nodes. The procedure for configuring an opt-out cluster is described in Section 7.1.4.2, “Configuring an "Opt-Out" Cluster”. This is the default Pacemaker strategy.
Whether you should choose to configure your cluster as an opt-in or opt-out cluster depends both on your personal preference and the make-up of your cluster. If most of your resources can run on most of the nodes, then an opt-out arrangement is likely to result in a simpler configuration. On the other hand, if most resources can only run on a small subset of nodes an opt-in configuration might be simpler.
7.1.4.1. Configuring an "Opt-In" Cluster
To create an opt-in cluster, set the
symmetric-cluster cluster property to false to prevent resources from running anywhere by default.
# pcs property set symmetric-cluster=false
Enable nodes for individual resources. The following commands configure location constraints so that the resource
Webserver prefers node example-1, the resource Database prefers node example-2, and both resources can fail over to node example-3 if their preferred node fails. When configuring location constraints for an opt-in cluster, setting a score of zero allows a resource to run on a node without indicating any preference to prefer or avoid the node.
#pcs constraint location Webserver prefers example-1=200#pcs constraint location Webserver prefers example-3=0#pcs constraint location Database prefers example-2=200#pcs constraint location Database prefers example-3=0
7.1.4.2. Configuring an "Opt-Out" Cluster
To create an opt-out cluster, set the
symmetric-cluster cluster property to true to allow resources to run everywhere by default.
# pcs property set symmetric-cluster=true
The following commands will then yield a configuration that is equivalent to the example in Section 7.1.4.1, “Configuring an "Opt-In" Cluster”. Both resources can fail over to node
example-3 if their preferred node fails, since every node has an implicit score of 0.
#pcs constraint location Webserver prefers example-1=200#pcs constraint location Webserver avoids example-2=INFINITY#pcs constraint location Database avoids example-1=INFINITY#pcs constraint location Database prefers example-2=200
Note that it is not necessary to specify a score of INFINITY in these commands, since that is the default value for the score.
7.1.5. Configuring a Resource to Prefer its Current Node
Resources have a
resource-stickiness value that you can set as a meta attribute when you create the resource, as described in Section 6.4, “Resource Meta Options”. The resource-stickiness value determines how much a resource wants to remain on the node where it is currently running. Pacemaker considers the resource-stickiness value in conjunction with other settings (for example, the score values of location constraints) to determine whether to move a resource to another node or to leave it in place.
By default, a resource is created with a
resource-stickiness value of 0. Pacemaker’s default behavior when resource-stickiness is set to 0 and there are no location constraints is to move resources so that they are evenly distributed among the cluster nodes. This may result in healthy resources moving more often than you desire. To prevent this behavior, you can set the default resource-stickiness value to 1. This default will apply to all resources in the cluster. This small value can be easily overridden by other constraints that you create, but it is enough to prevent Pacemaker from needlessly moving healthy resources around the cluster.
The following command sets the default resource-stickiness value to 1.
# pcs resource defaults resource-stickiness=1
If the
resource-stickiness value is set, then no resources will move to a newly-added node. If resource balancing is desired at that point, you can temporarily set the resource-stickiness value back to 0.
Note that if a location constraint score is higher than the resource-stickiness value, the cluster may still move a healthy resource to the node where the location constraint points.
For further information about how Pacemaker determines where to place a resource, see Section 9.6, “Utilization and Placement Strategy”.
