|
rpm-build |
3ee90c |
:compat-mode: legacy
|
|
rpm-build |
3ee90c |
= Resource Constraints =
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
////
|
|
rpm-build |
3ee90c |
We prefer [[ch-constraints]], but older versions of asciidoc don't deal well
|
|
rpm-build |
3ee90c |
with that construct for chapter headings
|
|
rpm-build |
3ee90c |
////
|
|
rpm-build |
3ee90c |
anchor:ch-constraints[Chapter 7, Alerts]
|
|
rpm-build |
3ee90c |
indexterm:[Resource,Constraint]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
== Scores ==
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
indexterm:[Resource,Score]
|
|
rpm-build |
3ee90c |
indexterm:[Node,Score]
|
|
rpm-build |
3ee90c |
Scores of all kinds are integral to how the cluster works.
|
|
rpm-build |
3ee90c |
Practically everything from moving a resource to deciding which
|
|
rpm-build |
3ee90c |
resource to stop in a degraded cluster is achieved by manipulating
|
|
rpm-build |
3ee90c |
scores in some way.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Scores are calculated per resource and node. Any node with a
|
|
rpm-build |
3ee90c |
negative score for a resource can't run that resource. The cluster
|
|
rpm-build |
3ee90c |
places a resource on the node with the highest score for it.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Infinity Math ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Pacemaker implements +INFINITY+ (or equivalently, ++INFINITY+) internally as a
|
|
rpm-build |
3ee90c |
score of 1,000,000. Addition and subtraction with it follow these three basic
|
|
rpm-build |
3ee90c |
rules:
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
* Any value + +INFINITY+ = +INFINITY+
|
|
rpm-build |
3ee90c |
* Any value - +INFINITY+ = +-INFINITY+
|
|
rpm-build |
3ee90c |
* +INFINITY+ - +INFINITY+ = +-INFINITY+
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[NOTE]
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
What if you want to use a score higher than 1,000,000? Typically this possibility
|
|
rpm-build |
3ee90c |
arises when someone wants to base the score on some external metric that might
|
|
rpm-build |
3ee90c |
go above 1,000,000.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
The short answer is you can't.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
The long answer is it is sometimes possible work around this limitation
|
|
rpm-build |
3ee90c |
creatively. You may be able to set the score to some computed value based on
|
|
rpm-build |
3ee90c |
the external metric rather than use the metric directly. For nodes, you can
|
|
rpm-build |
3ee90c |
store the metric as a node attribute, and query the attribute when computing
|
|
rpm-build |
3ee90c |
the score (possibly as part of a custom resource agent).
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
== Deciding Which Nodes a Resource Can Run On ==
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
indexterm:[Constraint,Location Constraint]
|
|
rpm-build |
3ee90c |
'Location constraints' tell the cluster which nodes a resource can run on.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
There are two alternative strategies. One way is to say that, by default,
|
|
rpm-build |
3ee90c |
resources can run anywhere, and then the location constraints specify nodes
|
|
rpm-build |
3ee90c |
that are not allowed (an 'opt-out' cluster). The other way is to start with
|
|
rpm-build |
3ee90c |
nothing able to run anywhere, and use location constraints to selectively
|
|
rpm-build |
3ee90c |
enable allowed nodes (an 'opt-in' cluster).
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Whether you should choose opt-in or opt-out depends on your
|
|
rpm-build |
3ee90c |
personal preference and the make-up of your cluster. If most of your
|
|
rpm-build |
3ee90c |
resources can run on most of the nodes, then an opt-out arrangement is
|
|
rpm-build |
3ee90c |
likely to result in a simpler configuration. On the other-hand, if
|
|
rpm-build |
3ee90c |
most resources can only run on a small subset of nodes, an opt-in
|
|
rpm-build |
3ee90c |
configuration might be simpler.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Location Properties ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_location element]
|
|
rpm-build |
3ee90c |
indexterm:[Constraint,Location Constraint,rsc_location element]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Attributes of a rsc_location Element
|
|
rpm-build |
3ee90c |
[width="95%",cols="2m,1,<5",options="header",align="center"]
|
|
rpm-build |
3ee90c |
|=========================================================
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|Attribute
|
|
rpm-build |
3ee90c |
|Default
|
|
rpm-build |
3ee90c |
|Description
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|id
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|A unique name for the constraint (required)
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,id attribute,rsc_location element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_location element,id attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|rsc
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|The name of the resource to which this constraint applies. A location
|
|
rpm-build |
3ee90c |
constraint must either have a +rsc+, have a +rsc-pattern+, or contain at least
|
|
rpm-build |
3ee90c |
one resource set.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,rsc attribute,rsc_location element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_location element,rsc attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|rsc-pattern
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|A pattern matching the names of resources to which this constraint applies.
|
|
rpm-build |
3ee90c |
The syntax is the same as
|
|
rpm-build |
3ee90c |
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04[POSIX]
|
|
rpm-build |
3ee90c |
extended regular expressions, with the addition of an initial '!' indicating
|
|
rpm-build |
3ee90c |
that resources 'not' matching the pattern are selected. If the regular
|
|
rpm-build |
3ee90c |
expression contains submatches, and the constraint is governed by a
|
|
rpm-build |
3ee90c |
<<ch-rules,rule>>, the submatches can be referenced as +%0+ through +%9+ in
|
|
rpm-build |
3ee90c |
the rule's +score-attribute+ or a rule expression's +attribute+. A location
|
|
rpm-build |
3ee90c |
constraint must either have a +rsc+, have a +rsc-pattern+, or contain at least
|
|
rpm-build |
3ee90c |
one resource set.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,rsc-pattern attribute,rsc_location element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_location element,rsc-pattern attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|node
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|The name of the node to which this constraint applies. A location constraint
|
|
rpm-build |
3ee90c |
must either have a +node+ and +score+, or contain at least one rule.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,node attribute,rsc_location element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_location element,node attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|score
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|Positive values indicate a preference for running the affected resource(s) on
|
|
rpm-build |
3ee90c |
+node+ -- the higher the value, the stronger the preference. Negative values
|
|
rpm-build |
3ee90c |
indicate the resource(s) should avoid this node (a value of +-INFINITY+
|
|
rpm-build |
3ee90c |
changes "should" to "must"). A location constraint must either have a +node+
|
|
rpm-build |
3ee90c |
and +score+, or contain at least one rule.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,score attribute,rsc_location element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_location element,score attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|resource-discovery
|
|
rpm-build |
3ee90c |
|always
|
|
rpm-build |
3ee90c |
a|Whether Pacemaker should perform resource discovery (that is, check whether
|
|
rpm-build |
3ee90c |
the resource is already running) for this resource on this node. This should
|
|
rpm-build |
3ee90c |
normally be left as the default, so that rogue instances of a service can be
|
|
rpm-build |
3ee90c |
stopped when they are running where they are not supposed to be. However,
|
|
rpm-build |
3ee90c |
there are two situations where disabling resource discovery is a good idea:
|
|
rpm-build |
3ee90c |
when a service is not installed on a node, discovery might return an error
|
|
rpm-build |
3ee90c |
(properly written OCF agents will not, so this is usually only seen with other
|
|
rpm-build |
3ee90c |
agent types); and when Pacemaker Remote is used to scale a cluster to hundreds
|
|
rpm-build |
3ee90c |
of nodes, limiting resource discovery to allowed nodes can significantly boost
|
|
rpm-build |
3ee90c |
performance.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
* +always:+ Always perform resource discovery for the specified resource on this node.
|
|
rpm-build |
3ee90c |
* +never:+ Never perform resource discovery for the specified resource on this node.
|
|
rpm-build |
3ee90c |
This option should generally be used with a -INFINITY score, although that is not strictly
|
|
rpm-build |
3ee90c |
required.
|
|
rpm-build |
3ee90c |
* +exclusive:+ Perform resource discovery for the specified resource only on
|
|
rpm-build |
3ee90c |
this node (and other nodes similarly marked as +exclusive+). Multiple location
|
|
rpm-build |
3ee90c |
constraints using +exclusive+ discovery for the same resource across
|
|
rpm-build |
3ee90c |
different nodes creates a subset of nodes resource-discovery is exclusive to.
|
|
rpm-build |
3ee90c |
If a resource is marked for +exclusive+ discovery on one or more nodes, that
|
|
rpm-build |
3ee90c |
resource is only allowed to be placed within that subset of nodes.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,resource-discovery attribute,rsc_location element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_location element,resource-discovery attribute]
|
|
rpm-build |
3ee90c |
indexterm:[Constraint,Location Constraint,Resource Discovery]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|=========================================================
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[WARNING]
|
|
rpm-build |
3ee90c |
=========
|
|
rpm-build |
3ee90c |
Setting resource-discovery to +never+ or +exclusive+ removes Pacemaker's
|
|
rpm-build |
3ee90c |
ability to detect and stop unwanted instances of a service running
|
|
rpm-build |
3ee90c |
where it's not supposed to be. It is up to the system administrator (you!)
|
|
rpm-build |
3ee90c |
to make sure that the service can 'never' be active on nodes without
|
|
rpm-build |
3ee90c |
resource-discovery (such as by leaving the relevant software uninstalled).
|
|
rpm-build |
3ee90c |
=========
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Asymmetrical "Opt-In" Clusters ===
|
|
rpm-build |
3ee90c |
indexterm:[Asymmetrical Clusters]
|
|
rpm-build |
3ee90c |
indexterm:[Opt-In Clusters]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
To create an opt-in cluster, start by preventing resources from
|
|
rpm-build |
3ee90c |
running anywhere by default:
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
----
|
|
rpm-build |
3ee90c |
# crm_attribute --name symmetric-cluster --update false
|
|
rpm-build |
3ee90c |
----
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Then start enabling nodes. The following fragment says that the web
|
|
rpm-build |
3ee90c |
server prefers *sles-1*, the database prefers *sles-2* and both can
|
|
rpm-build |
3ee90c |
fail over to *sles-3* if their most preferred node fails.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Opt-in location constraints for two resources
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-1" rsc="Webserver" node="sles-1" score="200"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-2" rsc="Webserver" node="sles-3" score="0"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-3" rsc="Database" node="sles-2" score="200"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-4" rsc="Database" node="sles-3" score="0"/>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Symmetrical "Opt-Out" Clusters ===
|
|
rpm-build |
3ee90c |
indexterm:[Symmetrical Clusters]
|
|
rpm-build |
3ee90c |
indexterm:[Opt-Out Clusters]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
To create an opt-out cluster, start by allowing resources to run
|
|
rpm-build |
3ee90c |
anywhere by default:
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
----
|
|
rpm-build |
3ee90c |
# crm_attribute --name symmetric-cluster --update true
|
|
rpm-build |
3ee90c |
----
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Then start disabling nodes. The following fragment is the equivalent
|
|
rpm-build |
3ee90c |
of the above opt-in configuration.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Opt-out location constraints for two resources
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-1" rsc="Webserver" node="sles-1" score="200"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-2-do-not-run" rsc="Webserver" node="sles-2" score="-INFINITY"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-3-do-not-run" rsc="Database" node="sles-1" score="-INFINITY"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-4" rsc="Database" node="sles-2" score="200"/>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[[node-score-equal]]
|
|
rpm-build |
3ee90c |
=== What if Two Nodes Have the Same Score ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
If two nodes have the same score, then the cluster will choose one.
|
|
rpm-build |
3ee90c |
This choice may seem random and may not be what was intended, however
|
|
rpm-build |
3ee90c |
the cluster was not given enough information to know any better.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Constraints where a resource prefers two nodes equally
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-1" rsc="Webserver" node="sles-1" score="INFINITY"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-2" rsc="Webserver" node="sles-2" score="INFINITY"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-3" rsc="Database" node="sles-1" score="500"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-4" rsc="Database" node="sles-2" score="300"/>
|
|
rpm-build |
3ee90c |
<rsc_location id="loc-5" rsc="Database" node="sles-2" score="200"/>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
In the example above, assuming no other constraints and an inactive
|
|
rpm-build |
3ee90c |
cluster, +Webserver+ would probably be placed on +sles-1+ and +Database+ on
|
|
rpm-build |
3ee90c |
+sles-2+. It would likely have placed +Webserver+ based on the node's
|
|
rpm-build |
3ee90c |
uname and +Database+ based on the desire to spread the resource load
|
|
rpm-build |
3ee90c |
evenly across the cluster. However other factors can also be involved
|
|
rpm-build |
3ee90c |
in more complex configurations.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[[s-resource-ordering]]
|
|
rpm-build |
3ee90c |
== Specifying the Order in which Resources Should Start/Stop ==
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
indexterm:[Constraint,Ordering Constraint]
|
|
rpm-build |
3ee90c |
indexterm:[Resource,Start Order]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
'Ordering constraints' tell the cluster the order in which certain
|
|
rpm-build |
3ee90c |
resource actions should occur.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[IMPORTANT]
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
Ordering constraints affect 'only' the ordering of resource actions;
|
|
rpm-build |
3ee90c |
they do 'not' require that the resources be placed on the
|
|
rpm-build |
3ee90c |
same node. If you want resources to be started on the same node
|
|
rpm-build |
3ee90c |
'and' in a specific order, you need both an ordering constraint 'and'
|
|
rpm-build |
3ee90c |
a colocation constraint (see <<s-resource-colocation>>), or
|
|
rpm-build |
3ee90c |
alternatively, a group (see <<group-resources>>).
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Ordering Properties ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_order element]
|
|
rpm-build |
3ee90c |
indexterm:[Constraint,Ordering Constraint,rsc_order element]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Attributes of a rsc_order Element
|
|
rpm-build |
3ee90c |
[width="95%",cols="1m,1,<4",options="header",align="center"]
|
|
rpm-build |
3ee90c |
|=========================================================
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|Field
|
|
rpm-build |
3ee90c |
|Default
|
|
rpm-build |
3ee90c |
|Description
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|id
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|A unique name for the constraint
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,id attribute,rsc_order element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_order element,id attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|first
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|Name of the resource that the +then+ resource depends on
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,first attribute,rsc_order element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_order element,first attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|then
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|Name of the dependent resource
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,then attribute,rsc_order element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_order element,then attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|first-action
|
|
rpm-build |
3ee90c |
|start
|
|
rpm-build |
3ee90c |
|The action that the +first+ resource must complete before +then-action+
|
|
rpm-build |
3ee90c |
can be initiated for the +then+ resource. Allowed values: +start+,
|
|
rpm-build |
3ee90c |
+stop+, +promote+, +demote+.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,first-action attribute,rsc_order element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_order element,first-action attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|then-action
|
|
rpm-build |
3ee90c |
|value of +first-action+
|
|
rpm-build |
3ee90c |
|The action that the +then+ resource can execute only after the
|
|
rpm-build |
3ee90c |
+first-action+ on the +first+ resource has completed. Allowed
|
|
rpm-build |
3ee90c |
values: +start+, +stop+, +promote+, +demote+.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,then-action attribute,rsc_order element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_order element,then-action attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|kind
|
|
rpm-build |
3ee90c |
|Mandatory
|
|
rpm-build |
3ee90c |
a|How to enforce the constraint. Allowed values:
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
* +Mandatory:+ +then-action+ will never be initiated for the +then+ resource
|
|
rpm-build |
3ee90c |
unless and until +first-action+ successfully completes for the +first+
|
|
rpm-build |
3ee90c |
resource.
|
|
rpm-build |
3ee90c |
* +Optional:+ The constraint applies only if both specified resource actions
|
|
rpm-build |
3ee90c |
are scheduled in the same transition (that is, in response to the same
|
|
rpm-build |
3ee90c |
cluster state). This means that +then-action+ is allowed on the +then+
|
|
rpm-build |
3ee90c |
resource regardless of the state of the +first+ resource, but if both actions
|
|
rpm-build |
3ee90c |
happen to be scheduled at the same time, they will be ordered.
|
|
rpm-build |
3ee90c |
* +Serialize:+ Ensure that the specified actions are never performed
|
|
rpm-build |
3ee90c |
concurrently for the specified resources. +First-action+ and +then-action+
|
|
rpm-build |
3ee90c |
can be executed in either order, but one must complete before the other can
|
|
rpm-build |
3ee90c |
be initiated. An example use case is when resource start-up puts a high load
|
|
rpm-build |
3ee90c |
on the host.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,kind attribute,rsc_order element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_order element,kind attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|symmetrical
|
|
rpm-build |
3ee90c |
|TRUE for +Mandatory+ and +Optional+ kinds. FALSE for +Serialize+ kind.
|
|
rpm-build |
3ee90c |
|If true, the reverse of the constraint applies for the opposite action (for
|
|
rpm-build |
3ee90c |
example, if B starts after A starts, then B stops before A stops).
|
|
rpm-build |
3ee90c |
+Serialize+ orders cannot be symmetrical.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,symmetrical attribute,rsc_order element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_order element,symmetrical attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|=========================================================
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
+Promote+ and +demote+ apply to the master role of
|
|
rpm-build |
3ee90c |
<<s-resource-promotable,promotable>> resources.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Optional and mandatory ordering ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Here is an example of ordering constraints where +Database+ 'must' start before
|
|
rpm-build |
3ee90c |
+Webserver+, and +IP+ 'should' start before +Webserver+ if they both need to be
|
|
rpm-build |
3ee90c |
started:
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Optional and mandatory ordering constraints
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_order id="order-1" first="IP" then="Webserver" kind="Optional"/>
|
|
rpm-build |
3ee90c |
<rsc_order id="order-2" first="Database" then="Webserver" kind="Mandatory" />
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Because the above example lets +symmetrical+ default to TRUE,
|
|
rpm-build |
3ee90c |
+Webserver+ must be stopped before +Database+ can be stopped,
|
|
rpm-build |
3ee90c |
and +Webserver+ should be stopped before +IP+
|
|
rpm-build |
3ee90c |
if they both need to be stopped.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[[s-resource-colocation]]
|
|
rpm-build |
3ee90c |
== Placing Resources Relative to other Resources ==
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
indexterm:[Constraint,Colocation Constraint]
|
|
rpm-build |
3ee90c |
indexterm:[Resource,Location Relative to Other Resources]
|
|
rpm-build |
3ee90c |
'Colocation constraints' tell the cluster that the location of one resource
|
|
rpm-build |
3ee90c |
depends on the location of another one.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Colocation has an important side-effect: it affects the order in which
|
|
rpm-build |
3ee90c |
resources are assigned to a node. Think about it: You can't place A relative to
|
|
rpm-build |
3ee90c |
B unless you know where B is.
|
|
rpm-build |
3ee90c |
footnote:[
|
|
rpm-build |
3ee90c |
While the human brain is sophisticated enough to read the constraint
|
|
rpm-build |
3ee90c |
in any order and choose the correct one depending on the situation,
|
|
rpm-build |
3ee90c |
the cluster is not quite so smart. Yet.
|
|
rpm-build |
3ee90c |
]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
So when you are creating colocation constraints, it is important to
|
|
rpm-build |
3ee90c |
consider whether you should colocate A with B, or B with A.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Another thing to keep in mind is that, assuming A is colocated with
|
|
rpm-build |
3ee90c |
B, the cluster will take into account A's preferences when
|
|
rpm-build |
3ee90c |
deciding which node to choose for B.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
For a detailed look at exactly how this occurs, see
|
|
rpm-build |
3ee90c |
http://clusterlabs.org/doc/Colocation_Explained.pdf[Colocation Explained].
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[IMPORTANT]
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
Colocation constraints affect 'only' the placement of resources; they do 'not'
|
|
rpm-build |
3ee90c |
require that the resources be started in a particular order. If you want
|
|
rpm-build |
3ee90c |
resources to be started on the same node 'and' in a specific order, you need
|
|
rpm-build |
3ee90c |
both an ordering constraint (see <<s-resource-ordering>>) 'and' a colocation
|
|
rpm-build |
3ee90c |
constraint, or alternatively, a group (see <<group-resources>>).
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Colocation Properties ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_colocation element]
|
|
rpm-build |
3ee90c |
indexterm:[Constraint,Colocation Constraint,rsc_colocation element]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Attributes of a rsc_colocation Constraint
|
|
rpm-build |
3ee90c |
[width="95%",cols="1m,1,<4",options="header",align="center"]
|
|
rpm-build |
3ee90c |
|=========================================================
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|Field
|
|
rpm-build |
3ee90c |
|Default
|
|
rpm-build |
3ee90c |
|Description
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|id
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|A unique name for the constraint (required).
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,id attribute,rsc_colocation element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_colocation element,id attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|rsc
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|The name of a resource that should be located relative to +with-rsc+ (required).
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,rsc attribute,rsc_colocation element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_colocation element,rsc attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|with-rsc
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|The name of the resource used as the colocation target. The cluster will
|
|
rpm-build |
3ee90c |
decide where to put this resource first and then decide where to put +rsc+ (required).
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,with-rsc attribute,rsc_colocation element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_colocation element,with-rsc attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|node-attribute
|
|
rpm-build |
3ee90c |
|#uname
|
|
rpm-build |
3ee90c |
|The node attribute that must be the same on the node running +rsc+ and the
|
|
rpm-build |
3ee90c |
node running +with-rsc+ for the constraint to be satisfied. (For details,
|
|
rpm-build |
3ee90c |
see <<s-coloc-attribute>>.)
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,node-attribute attribute,rsc_colocation element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_colocation element,node-attribute attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|score
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|Positive values indicate the resources should run on the same
|
|
rpm-build |
3ee90c |
node. Negative values indicate the resources should run on
|
|
rpm-build |
3ee90c |
different nodes. Values of \+/- +INFINITY+ change "should" to "must".
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,score attribute,rsc_colocation element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,rsc_colocation element,score attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|=========================================================
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Mandatory Placement ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Mandatory placement occurs when the constraint's score is
|
|
rpm-build |
3ee90c |
++INFINITY+ or +-INFINITY+. In such cases, if the constraint can't be
|
|
rpm-build |
3ee90c |
satisfied, then the +rsc+ resource is not permitted to run. For
|
|
rpm-build |
3ee90c |
+score=INFINITY+, this includes cases where the +with-rsc+ resource is
|
|
rpm-build |
3ee90c |
not active.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
If you need resource +A+ to always run on the same machine as
|
|
rpm-build |
3ee90c |
resource +B+, you would add the following constraint:
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Mandatory colocation constraint for two resources
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
<rsc_colocation id="colocate" rsc="A" with-rsc="B" score="INFINITY"/>
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Remember, because +INFINITY+ was used, if +B+ can't run on any
|
|
rpm-build |
3ee90c |
of the cluster nodes (for whatever reason) then +A+ will not
|
|
rpm-build |
3ee90c |
be allowed to run. Whether +A+ is running or not has no effect on +B+.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Alternatively, you may want the opposite -- that +A+ 'cannot'
|
|
rpm-build |
3ee90c |
run on the same machine as +B+. In this case, use
|
|
rpm-build |
3ee90c |
+score="-INFINITY"+.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Mandatory anti-colocation constraint for two resources
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
<rsc_colocation id="anti-colocate" rsc="A" with-rsc="B" score="-INFINITY"/>
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Again, by specifying +-INFINITY+, the constraint is binding. So if the
|
|
rpm-build |
3ee90c |
only place left to run is where +B+ already is, then
|
|
rpm-build |
3ee90c |
+A+ may not run anywhere.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
As with +INFINITY+, +B+ can run even if +A+ is stopped.
|
|
rpm-build |
3ee90c |
However, in this case +A+ also can run if +B+ is stopped, because it still
|
|
rpm-build |
3ee90c |
meets the constraint of +A+ and +B+ not running on the same node.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Advisory Placement ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
If mandatory placement is about "must" and "must not", then advisory
|
|
rpm-build |
3ee90c |
placement is the "I'd prefer if" alternative. For constraints with
|
|
rpm-build |
3ee90c |
scores greater than +-INFINITY+ and less than +INFINITY+, the cluster
|
|
rpm-build |
3ee90c |
will try to accommodate your wishes but may ignore them if the
|
|
rpm-build |
3ee90c |
alternative is to stop some of the cluster resources.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
As in life, where if enough people prefer something it effectively
|
|
rpm-build |
3ee90c |
becomes mandatory, advisory colocation constraints can combine with
|
|
rpm-build |
3ee90c |
other elements of the configuration to behave as if they were
|
|
rpm-build |
3ee90c |
mandatory.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Advisory colocation constraint for two resources
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
<rsc_colocation id="colocate-maybe" rsc="A" with-rsc="B" score="500"/>
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[[s-coloc-attribute]]
|
|
rpm-build |
3ee90c |
=== Colocation by Node Attribute ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
The +node-attribute+ property of a colocation constraints allows you to express
|
|
rpm-build |
3ee90c |
the requirement, "these resources must be on similar nodes".
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
As an example, imagine that you have two Storage Area Networks (SANs) that are
|
|
rpm-build |
3ee90c |
not controlled by the cluster, and each node is connected to one or the other.
|
|
rpm-build |
3ee90c |
You may have two resources +r1+ and +r2+ such that +r2+ needs to use the same
|
|
rpm-build |
3ee90c |
SAN as +r1+, but doesn't necessarily have to be on the same exact node.
|
|
rpm-build |
3ee90c |
In such a case, you could define a <<s-node-attributes,node attribute>> named
|
|
rpm-build |
3ee90c |
+san+, with the value +san1+ or +san2+ on each node as appropriate. Then, you
|
|
rpm-build |
3ee90c |
could colocate +r2+ with +r1+ using +node-attribute+ set to +san+.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[[s-resource-sets]]
|
|
rpm-build |
3ee90c |
== Resource Sets ==
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
'Resource sets' allow multiple resources to be affected by a single constraint.
|
|
rpm-build |
3ee90c |
indexterm:[Constraint,Resource Set]
|
|
rpm-build |
3ee90c |
indexterm:[Resource,Resource Set]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.A set of 3 resources
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
----
|
|
rpm-build |
3ee90c |
<resource_set id="resource-set-example">
|
|
rpm-build |
3ee90c |
<resource_ref id="A"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="B"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="C"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
----
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Resource sets are valid inside +rsc_location+,
|
|
rpm-build |
3ee90c |
+rsc_order+ (see <<s-resource-sets-ordering>>),
|
|
rpm-build |
3ee90c |
+rsc_colocation+ (see <<s-resource-sets-colocation>>),
|
|
rpm-build |
3ee90c |
and +rsc_ticket+ (see <<s-ticket-constraints>>) constraints.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
A resource set has a number of properties that can be set,
|
|
rpm-build |
3ee90c |
though not all have an effect in all contexts.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Attributes of a resource_set Element
|
|
rpm-build |
3ee90c |
[width="95%",cols="2m,1,<5",options="header",align="center"]
|
|
rpm-build |
3ee90c |
|=========================================================
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|Field
|
|
rpm-build |
3ee90c |
|Default
|
|
rpm-build |
3ee90c |
|Description
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|id
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|A unique name for the set
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,id attribute,resource_set element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,resource_set element,id attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|sequential
|
|
rpm-build |
3ee90c |
|true
|
|
rpm-build |
3ee90c |
|Whether the members of the set must be acted on in order.
|
|
rpm-build |
3ee90c |
Meaningful within +rsc_order+ and +rsc_colocation+.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,sequential attribute,resource_set element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,resource_set element,sequential attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|require-all
|
|
rpm-build |
3ee90c |
|true
|
|
rpm-build |
3ee90c |
|Whether all members of the set must be active before continuing.
|
|
rpm-build |
3ee90c |
With the current implementation, the cluster may continue even if only one
|
|
rpm-build |
3ee90c |
member of the set is started, but if more than one member of the set is
|
|
rpm-build |
3ee90c |
starting at the same time, the cluster will still wait until all of those have
|
|
rpm-build |
3ee90c |
started before continuing (this may change in future versions).
|
|
rpm-build |
3ee90c |
Meaningful within +rsc_order+.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,require-all attribute,resource_set element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,resource_set element,require-all attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|role
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|Limit the effect of the constraint to the specified role.
|
|
rpm-build |
3ee90c |
Meaningful within +rsc_location+, +rsc_colocation+ and +rsc_ticket+.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,role attribute,resource_set element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,resource_set element,role attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|action
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|Limit the effect of the constraint to the specified action.
|
|
rpm-build |
3ee90c |
Meaningful within +rsc_order+.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,action attribute,resource_set element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,resource_set element,action attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|score
|
|
rpm-build |
3ee90c |
|
|
|
rpm-build |
3ee90c |
|'Advanced use only.' Use a specific score for this set within the constraint.
|
|
rpm-build |
3ee90c |
indexterm:[XML attribute,score attribute,resource_set element]
|
|
rpm-build |
3ee90c |
indexterm:[XML element,resource_set element,score attribute]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
|=========================================================
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[[s-resource-sets-ordering]]
|
|
rpm-build |
3ee90c |
== Ordering Sets of Resources ==
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
A common situation is for an administrator to create a chain of
|
|
rpm-build |
3ee90c |
ordered resources, such as:
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.A chain of ordered resources
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_order id="order-1" first="A" then="B" />
|
|
rpm-build |
3ee90c |
<rsc_order id="order-2" first="B" then="C" />
|
|
rpm-build |
3ee90c |
<rsc_order id="order-3" first="C" then="D" />
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Visual representation of the four resources' start order for the above constraints
|
|
rpm-build |
3ee90c |
image::images/resource-set.png["Ordered set",width="16cm",height="2.5cm",align="center"]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Ordered Set ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
To simplify this situation, resource sets (see <<s-resource-sets>>) can be used
|
|
rpm-build |
3ee90c |
within ordering constraints:
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.A chain of ordered resources expressed as a set
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_order id="order-1">
|
|
rpm-build |
3ee90c |
<resource_set id="ordered-set-example" sequential="true">
|
|
rpm-build |
3ee90c |
<resource_ref id="A"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="B"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="C"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="D"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
</rsc_order>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
While the set-based format is not less verbose, it is significantly
|
|
rpm-build |
3ee90c |
easier to get right and maintain.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[IMPORTANT]
|
|
rpm-build |
3ee90c |
=========
|
|
rpm-build |
3ee90c |
If you use a higher-level tool, pay attention to how it exposes this
|
|
rpm-build |
3ee90c |
functionality. Depending on the tool, creating a set +A B+ may be equivalent to
|
|
rpm-build |
3ee90c |
+A then B+, or +B then A+.
|
|
rpm-build |
3ee90c |
=========
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Ordering Multiple Sets ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
The syntax can be expanded to allow sets of resources to be ordered relative to
|
|
rpm-build |
3ee90c |
each other, where the members of each individual set may be ordered or
|
|
rpm-build |
3ee90c |
unordered (controlled by the +sequential+ property). In the example below, +A+
|
|
rpm-build |
3ee90c |
and +B+ can both start in parallel, as can +C+ and +D+, however +C+ and +D+ can
|
|
rpm-build |
3ee90c |
only start once _both_ +A+ _and_ +B+ are active.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Ordered sets of unordered resources
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_order id="order-1">
|
|
rpm-build |
3ee90c |
<resource_set id="ordered-set-1" sequential="false">
|
|
rpm-build |
3ee90c |
<resource_ref id="A"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="B"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
<resource_set id="ordered-set-2" sequential="false">
|
|
rpm-build |
3ee90c |
<resource_ref id="C"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="D"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
</rsc_order>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Visual representation of the start order for two ordered sets of unordered resources
|
|
rpm-build |
3ee90c |
image::images/two-sets.png["Two ordered sets",width="13cm",height="7.5cm",align="center"]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Of course either set -- or both sets -- of resources can also be
|
|
rpm-build |
3ee90c |
internally ordered (by setting +sequential="true"+) and there is no
|
|
rpm-build |
3ee90c |
limit to the number of sets that can be specified.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Advanced use of set ordering - Three ordered sets, two of which are internally unordered
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_order id="order-1">
|
|
rpm-build |
3ee90c |
<resource_set id="ordered-set-1" sequential="false">
|
|
rpm-build |
3ee90c |
<resource_ref id="A"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="B"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
<resource_set id="ordered-set-2" sequential="true">
|
|
rpm-build |
3ee90c |
<resource_ref id="C"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="D"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
<resource_set id="ordered-set-3" sequential="false">
|
|
rpm-build |
3ee90c |
<resource_ref id="E"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="F"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
</rsc_order>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Visual representation of the start order for the three sets defined above
|
|
rpm-build |
3ee90c |
image::images/three-sets.png["Three ordered sets",width="16cm",height="7.5cm",align="center"]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[IMPORTANT]
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
An ordered set with +sequential=false+ makes sense only if there is another
|
|
rpm-build |
3ee90c |
set in the constraint. Otherwise, the constraint has no effect.
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
=== Resource Set OR Logic ===
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
The unordered set logic discussed so far has all been "AND" logic.
|
|
rpm-build |
3ee90c |
To illustrate this take the 3 resource set figure in the previous section.
|
|
rpm-build |
3ee90c |
Those sets can be expressed, +(A and B) then \(C) then (D) then (E and F)+.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Say for example we want to change the first set, +(A and B)+, to use "OR" logic
|
|
rpm-build |
3ee90c |
so the sets look like this: +(A or B) then \(C) then (D) then (E and F)+.
|
|
rpm-build |
3ee90c |
This functionality can be achieved through the use of the +require-all+
|
|
rpm-build |
3ee90c |
option. This option defaults to TRUE which is why the
|
|
rpm-build |
3ee90c |
"AND" logic is used by default. Setting +require-all=false+ means only one
|
|
rpm-build |
3ee90c |
resource in the set needs to be started before continuing on to the next set.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Resource Set "OR" logic: Three ordered sets, where the first set is internally unordered with "OR" logic
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_order id="order-1">
|
|
rpm-build |
3ee90c |
<resource_set id="ordered-set-1" sequential="false" require-all="false">
|
|
rpm-build |
3ee90c |
<resource_ref id="A"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="B"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
<resource_set id="ordered-set-2" sequential="true">
|
|
rpm-build |
3ee90c |
<resource_ref id="C"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="D"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
<resource_set id="ordered-set-3" sequential="false">
|
|
rpm-build |
3ee90c |
<resource_ref id="E"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="F"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
</rsc_order>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[IMPORTANT]
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
An ordered set with +require-all=false+ makes sense only in conjunction with
|
|
rpm-build |
3ee90c |
+sequential=false+. Think of it like this: +sequential=false+ modifies the set
|
|
rpm-build |
3ee90c |
to be an unordered set using "AND" logic by default, and adding
|
|
rpm-build |
3ee90c |
+require-all=false+ flips the unordered set's "AND" logic to "OR" logic.
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[[s-resource-sets-colocation]]
|
|
rpm-build |
3ee90c |
== Colocating Sets of Resources ==
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Another common situation is for an administrator to create a set of
|
|
rpm-build |
3ee90c |
colocated resources.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
The simplest way to do this is to define a resource group (see
|
|
rpm-build |
3ee90c |
<<group-resources>>), but that cannot always accurately express the desired
|
|
rpm-build |
3ee90c |
relationships. For example, maybe the resources do not need to be ordered.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Another way would be to define each relationship as an individual constraint,
|
|
rpm-build |
3ee90c |
but that causes a difficult-to-follow constraint explosion as the number of
|
|
rpm-build |
3ee90c |
resources and combinations grow.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Colocation chain as individual constraints, where A is placed first, then B, then C, then D
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_colocation id="coloc-1" rsc="D" with-rsc="C" score="INFINITY"/>
|
|
rpm-build |
3ee90c |
<rsc_colocation id="coloc-2" rsc="C" with-rsc="B" score="INFINITY"/>
|
|
rpm-build |
3ee90c |
<rsc_colocation id="coloc-3" rsc="B" with-rsc="A" score="INFINITY"/>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
To express complicated relationships with a simplified syntax
|
|
rpm-build |
3ee90c |
footnote:[which is not the same as saying easy to follow],
|
|
rpm-build |
3ee90c |
<<s-resource-sets,resource sets>> can be used within colocation constraints.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Equivalent colocation chain expressed using +resource_set+
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_colocation id="coloc-1" score="INFINITY" >
|
|
rpm-build |
3ee90c |
<resource_set id="colocated-set-example" sequential="true">
|
|
rpm-build |
3ee90c |
<resource_ref id="A"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="B"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="C"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="D"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
</rsc_colocation>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[NOTE]
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
Within a +resource_set+, the resources are listed in the order they are
|
|
rpm-build |
3ee90c |
_placed_, which is the reverse of the order in which they are _colocated_.
|
|
rpm-build |
3ee90c |
In the above example, resource +A+ is placed before resource +B+, which is
|
|
rpm-build |
3ee90c |
the same as saying resource +B+ is colocated with resource +A+.
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
As with individual constraints, a resource that can't be active prevents any
|
|
rpm-build |
3ee90c |
resource that must be colocated with it from being active. In both of the two
|
|
rpm-build |
3ee90c |
previous examples, if +B+ is unable to run, then both +C+ and by inference +D+
|
|
rpm-build |
3ee90c |
must remain stopped.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[IMPORTANT]
|
|
rpm-build |
3ee90c |
=========
|
|
rpm-build |
3ee90c |
If you use a higher-level tool, pay attention to how it exposes this
|
|
rpm-build |
3ee90c |
functionality. Depending on the tool, creating a set +A B+ may be equivalent to
|
|
rpm-build |
3ee90c |
+A with B+, or +B with A+.
|
|
rpm-build |
3ee90c |
=========
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
Resource sets can also be used to tell the cluster that entire _sets_ of
|
|
rpm-build |
3ee90c |
resources must be colocated relative to each other, while the individual
|
|
rpm-build |
3ee90c |
members within any one set may or may not be colocated relative to each other
|
|
rpm-build |
3ee90c |
(determined by the set's +sequential+ property).
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
In the following example, resources +B+, +C+, and +D+ will each be colocated
|
|
rpm-build |
3ee90c |
with +A+ (which will be placed first). +A+ must be able to run in order for any
|
|
rpm-build |
3ee90c |
of the resources to run, but any of +B+, +C+, or +D+ may be stopped without
|
|
rpm-build |
3ee90c |
affecting any of the others.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Using colocated sets to specify a shared dependency
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_colocation id="coloc-1" score="INFINITY" >
|
|
rpm-build |
3ee90c |
<resource_set id="colocated-set-2" sequential="false">
|
|
rpm-build |
3ee90c |
<resource_ref id="B"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="C"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="D"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
<resource_set id="colocated-set-1" sequential="true">
|
|
rpm-build |
3ee90c |
<resource_ref id="A"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
</rsc_colocation>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[NOTE]
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
Pay close attention to the order in which resources and sets are listed.
|
|
rpm-build |
3ee90c |
While the members of any one sequential set are placed first to last (i.e., the
|
|
rpm-build |
3ee90c |
colocation dependency is last with first), multiple sets are placed last to
|
|
rpm-build |
3ee90c |
first (i.e. the colocation dependency is first with last).
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[IMPORTANT]
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
A colocated set with +sequential="false"+ makes sense only if there is
|
|
rpm-build |
3ee90c |
another set in the constraint. Otherwise, the constraint has no effect.
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
There is no inherent limit to the number and size of the sets used.
|
|
rpm-build |
3ee90c |
The only thing that matters is that in order for any member of one set
|
|
rpm-build |
3ee90c |
in the constraint to be active, all members of sets listed after it must also
|
|
rpm-build |
3ee90c |
be active (and naturally on the same node); and if a set has +sequential="true"+,
|
|
rpm-build |
3ee90c |
then in order for one member of that set to be active, all members listed
|
|
rpm-build |
3ee90c |
before it must also be active.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
If desired, you can restrict the dependency to instances of promotable clone
|
|
rpm-build |
3ee90c |
resources that are in a specific role, using the set's +role+ property.
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Colocation in which the members of the middle set have no interdependencies, and the last set listed applies only to instances in the master role
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
[source,XML]
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
<constraints>
|
|
rpm-build |
3ee90c |
<rsc_colocation id="coloc-1" score="INFINITY" >
|
|
rpm-build |
3ee90c |
<resource_set id="colocated-set-1" sequential="true">
|
|
rpm-build |
3ee90c |
<resource_ref id="F"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="G"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
<resource_set id="colocated-set-2" sequential="false">
|
|
rpm-build |
3ee90c |
<resource_ref id="C"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="D"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="E"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
<resource_set id="colocated-set-3" sequential="true" role="Master">
|
|
rpm-build |
3ee90c |
<resource_ref id="A"/>
|
|
rpm-build |
3ee90c |
<resource_ref id="B"/>
|
|
rpm-build |
3ee90c |
</resource_set>
|
|
rpm-build |
3ee90c |
</rsc_colocation>
|
|
rpm-build |
3ee90c |
</constraints>
|
|
rpm-build |
3ee90c |
-------
|
|
rpm-build |
3ee90c |
======
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
.Visual representation of the above example (resources are placed from left to right)
|
|
rpm-build |
3ee90c |
image::images/pcmk-colocated-sets.png["Colocation chain",width="960px",height="431px",align="center"]
|
|
rpm-build |
3ee90c |
|
|
rpm-build |
3ee90c |
[NOTE]
|
|
rpm-build |
3ee90c |
====
|
|
rpm-build |
3ee90c |
Unlike ordered sets, colocated sets do not use the +require-all+ option.
|
|
rpm-build |
3ee90c |
====
|