LinuxLV · Pacemaker and CorosyncPacemaker constraints
Pacemaker constraints: location, colocation, order
What you'll learn
- Use location constraints
- Use colocation constraints
- Use order constraints
- Apply constraints to common scenarios
Prerequisites
Verified against Ubuntu 24.04 LTS · Debian 12 (Bookworm) · RHEL 9.x · Rocky Linux 9.x · AlmaLinux 9.x · Linux kernel 6.1 LTS / 6.6 LTS · systemd 255+ · OpenSSH 8.7p1 (RHEL 9) / 9.6p1 (Ubuntu 24.04) · nftables 1.0.x · chrony 4.x · Pacemaker 2.1.x · Corosync 3.1.x · 2026-08-09
Constraints shape where Pacemaker places resources and the order of operations. This lesson covers the three types and the common scenarios.
Location constraints
Location constraints say which nodes a resource can run on.
pcs has exactly two keywords, prefers and avoids:
# Mandatory: never place web on node3 (implicit -INFINITY)
pcs constraint location web avoids node3
# Advisory: a strong pull towards node1, but node2 remains usable
pcs constraint location web prefers node1=500
# Advisory: a mild push away from node3
pcs constraint location web avoids node3=50
There is no banned keyword. pcs constraint location web banned node3 is a syntax error and configures nothing, so the placement
you intended never happens.
pcs resource ban <resource> <node> also exists. It creates the
same -INFINITY location constraint, but it is a temporary
operational action rather than part of your design - use it to
drain a node for maintenance, and clear it afterwards with
pcs resource clear <resource> <node>.
For active-passive: prefer one node with a high score, ban the node that must never run it. For active-active: avoid location constraints altogether and let Pacemaker balance.
Colocation constraints
Colocation constraints say which resources run together. There is
no not keyword - anti-colocation is expressed with a negative
score:
# Web and DB must run on the same node
pcs constraint colocation add web with db INFINITY
# Web and DB must run on DIFFERENT nodes (anti-colocation)
pcs constraint colocation add web with db -INFINITY
# A preference rather than a rule
pcs constraint colocation add web with db 50
pcs constraint colocation add web with not db is not valid
syntax. It fails, which means the anti-affinity you thought you had
does not exist - and both replicas of a service can be placed on
one node, so a single node loss becomes a full outage.
Scores are positive (together) or negative (apart). The higher the
absolute value, the stronger the preference; INFINITY and
-INFINITY are mandatory.
Order constraints
Order constraints say which resources start or stop first:
# DB starts before web. On stop, the reverse: web stops before db.
pcs constraint order db then web
# Same shape, but only a preference
pcs constraint order db then web kind=Optional
pcs constraint order A then B means A starts before B. The stop
sequence is automatically the mirror image: B stops before A. You
do not write a separate constraint for stopping, and reading
order web then db as “web stops before db” inverts the meaning -
it actually starts web first, and tears down db first, which during
maintenance means the dependency is removed before the thing that
depends on it.
kind=Mandatory (default) is a hard order. kind=Optional applies
the ordering only when both actions happen in the same transition.
Common scenarios
Master/slave database
# Promote on node1, fall back to node2, never node3
pcs constraint location db prefers node1=1000
pcs constraint location db prefers node2=500
pcs constraint location db avoids node3
The two prefers lines carry explicit, different scores. Written
without scores they would both be INFINITY, which is not a
primary and a fallback - it is a tie, and Pacemaker would break it
on internal scoring you do not control. Only the avoids node3
line is meant to be absolute, so only it is left unscored.
Web and database together
# Same node...
pcs constraint colocation add web with db INFINITY
# ...and in the right order
pcs constraint order db then web
Both lines are required. The colocation places them together; the order guarantees the database is up before the web tier starts.
Application order
# Database first, then application
pcs constraint order db then app
pcs constraint order app then web
Active-active load balancing
# Don\'t constrain - let Pacemaker balance
# (No location, no colocation)
Verify constraints
pcs constraint config
Output (--full adds constraint ids, which you need before
you can remove one):
Location Constraints:
Resource: web
Preferred: node1
Preferred: node2
Resource: db
Avoid: node3
Colocation Constraints:
web with db (score:INFINITY)
Order Constraints:
start db then start web
Modify or remove:
pcs constraint remove mylocationconstraintid
Production discipline
For every cluster:
- Document the constraints.
- Verify with
pcs constraint config --full. - Test with
pcs resource move, then undo it withpcs resource clear. There is nopcs resource unmove- the subcommands aremove,move-with-constraint,banandclear. - Schedule quarterly constraint audits.
Knowledge check
Knowledge check · 5 questions
Q1. What makes a location constraint advisory rather than mandatory?
Q2. Keeping two resources apart is expressed with a negative colocation score rather than a separate anti-colocation keyword.
Q3. Which of the following are valid Pacemaker constraint types? Select all that apply.
Q4. Node1 and node2 are down for a power fault. The database will not start on node3, which is healthy and idle. pcs constraint config lists only: Resource: db / Avoid: node3. What is happening?
Q5. You configured `pcs constraint colocation add web with db INFINITY` and nothing else. During a failover the web service starts and immediately fails its health check. Why?
Passing score: 75%. Answers are checked in this browser.