Skip to main content
RunBook Academy

LinuxLV · Pacemaker and CorosyncPacemaker constraints

Pacemaker constraints: location, colocation, order

Advanced⏱ ~10 minpcs

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

Not yet marked complete on this device.

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 with pcs resource clear. There is no pcs resource unmove - the subcommands are move, move-with-constraint, ban and clear.
  • Schedule quarterly constraint audits.

Knowledge check

Knowledge check · 5 questions

  1. Q1. What makes a location constraint advisory rather than mandatory?

  2. Q2. Keeping two resources apart is expressed with a negative colocation score rather than a separate anti-colocation keyword.

  3. Q3. Which of the following are valid Pacemaker constraint types? Select all that apply.

  4. 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?

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