|Index|Adding Constraints to HA Cluster Resources
SUSE Linux Enterprise High Availability 16.0

Adding Constraints to HA Cluster Resources

Publication Date: 23 Jun 2026

Resource constraints let you specify cluster node assignments, define the start order, and manage dependencies between resources. Because cluster resources sometimes depend on other resources or on a particular node configuration, they might need to run in a specific location or start in a specific order. Add resource constraints to specify exactly where and when High Availability cluster resources can run.

Requirements
 

  • An existing SUSE Linux Enterprise High Availability cluster

  • Existing cluster resources

Tip

If you still need to configure cluster resources, see Configuring HA Cluster Resources.

1 What are cluster resources?

 

In a High Availability cluster, the applications and services that need to be highly available are called resources. Cluster resources can include Web sites, e-mail servers, databases, file systems, virtual machines or any other applications or services that need to be available to users at all times. You can start, stop, monitor and move resources as needed. You can also specify whether resources should run together on the same node, or start and stop in sequential order. If a node fails, the resources running on it fail over (move) to another node instead of being lost.

In SUSE Linux Enterprise High Availability, the cluster resource manager (CRM) is Pacemaker, which manages and coordinates all cluster services. Pacemaker uses resource agents (RAs) to start, stop and monitor resources. A resource agent abstracts the resource and presents its status to the cluster. This means that Pacemaker only interacts with the resource agent, not with the actual application or service. SUSE Linux Enterprise High Availability supports many different resource agents that are designed to manage specific types of resources.

1.1 Primitive resources

 

Primitive resources represent the applications or services that need to be highly available. Configuring a primitive specifies the resource agent and any other information required for the cluster to manage a resource. To see the supported resource agent classes, run crm ra classes. To see the resource agents available within a class, run crm ra list CLASS.

Primitive resources can have the following settings:

Properties

Resource properties are the basic details required by the cluster: a unique name for the resource, and the resource agent that manages the application or service.

Parameters

Parameters are specific to each resource agent and determine the details and behavior of an application or service. To show all the parameters available for a resource agent, run crm ra info RESOURCE_AGENT.

Operations

Operations are actions that the cluster can perform on a resource, such as start, stop and monitor. To show the supported operations for a resource agent, run crm ra info RESOURCE_AGENT and scroll to the bottom of the output.

Meta attributes

Meta attributes change how the cluster treats a resource. To show all the meta attributes available for primitives, run crm_resource --list-options primitive.

Utilization attributes

If the cluster nodes have utilization attributes configured, you can add these attributes to cluster resources to help with load balancing. For more information, see https://clusterlabs.org/projects/pacemaker/doc/3.0/Pacemaker_Explained/html/utilization.html.

1.2 Resource groups

 

Cluster resources might depend on other resources, such as a Web server that requires an IP address and a file system. You can combine these resources into a resource group. Groups contain multiple primitives that need to be located together, started sequentially and stopped in the reverse order.

This diagram shows a box representing a node. The box contains four individual resources and a smaller box containing three more resources. The smaller box represents a resource group. A zoomed-in view of the resource group shows that the resources are an IP address, an XFS file system and an Apache Web server. The resources are numbered to show the start order in one direction and the reversed stop order in the other direction.
Figure 1: Resource group
 

Groups have the following properties:

Contents

Groups can only contain primitive resources, not clones or other groups.

Starting and stopping

Resources start in the order they appear and stop in the reverse order.

Location

Resources in the group must all run on the same node.

Dependency

If one of the resources can't run anywhere, then the resources that appear after it in the group can't run anywhere either.

Meta attributes

The meta attributes target-role, priority, maintenance and is-managed can be added directly to the group. All other attributes are inherited from the group's resources.

Resource stickiness

Stickiness in groups is additive. Every active resource in the group contributes its stickiness value to the group's total.

1.3 Resource clones

 

Resource clones can run simultaneously on multiple nodes. This is required for cluster file systems like GFS2, for example. You can clone a primitive or a group if the resource agent supports it. Clones can also have additional clone-specific meta attributes to change their behavior.

Clones can be one of the following types:

Anonymous clones

Anonymous clones are the simplest type. All instances of the clone behave identically. Therefore, only one instance of an anonymous clone can be active on each node.

Globally unique clones

Globally unique clones are distinct entities. An instance of the clone running on one node is not necessarily equivalent to another instance on another node.

Promotable clones

Promotable clones allow the instances to be in one of two operating modes: promoted or unpromoted (also known as primary and secondary, or active and passive). Promotable clones can be either anonymous or globally unique.

To make a clone promotable, the resource agent must support the promote and demote operations. The cluster determines which instance of the clone to promote using one of the following methods (or a combination of both):

  • If a resource agent supports promotable clones, it might automatically set promotion scores based on its own preference for which instance to promote.

  • You can manually set promotion rules or preferences by creating location or colocation constraints.

For more information, see https://clusterlabs.org/projects/pacemaker/doc/3.0/Pacemaker_Explained/html/collective.html#determining-which-instance-is-promoted

1.4 For more information

 

2 What are resource constraints?

 

Resource constraints let you specify cluster node assignments, define the start order, and manage dependencies between resources.

2.1 Types of constraints

 
Order

Order constraints tell the cluster to start resources in a specific order and stop them in the reverse order. You can also start or stop a resource right before or after a different resource performs a certain action, such as being promoted.

Location

Location constraints tell the cluster where resources can or cannot run. You can specify that a resource must or must not run on a particular node, or give the resource an optional preference for or against a node.

Colocation

Colocation constraints tell the cluster which resources can or cannot run together on the same node. You can specify that the resources must or must not run together, or give a resource an optional preference for or against another resource.

Important
Important: Restrictions for constraints and primitive resources

  • Don't add colocation constraints to primitives in a resource group. Add a colocation constraint to the group instead.

  • Don't add any constraints to a primitive that has been cloned. Add constraints to the clone instead.

2.2 Scores and kinds

 

Location and colocation constraints must have a score to indicate how important the constraint is. A score of INFINITY (positive or negative) means that the constraint must be applied. The score can also be a non-infinite number (positive or negative), which means the constraint is only a preference. In this case, the constraint might not be applied if its score is outweighed by other factors, such as other constraints, resource stickiness, failure thresholds, etc.

For location constraints, a positive score means the resource should (or must) run on the specified node. A negative score means the resource should not (or must not) run on the specified node. You can also add multiple location constraints with different scores to prioritize node preferences.

For colocation constraints, a positive score means the resources should (or must) run together on the same node. A negative score means the resources should not (or must not) run together on the same node.

Instead of a score, order constraints must have a kind, which defines whether the constraint is mandatory or optional.

2.3 Resource sets

 

Resource sets let you group multiple resources in a single constraint instead of needing multiple constraints. The effect depends on the type of constraint:

  • In a location constraint, a resource set applies the constraint to multiple resources instead of just one, without creating any dependency between the resources.

    Location constraints use curly brackets to group the resources.

  • In an order constraint, a resource set gives multiple resources the same position in the order. For example, a simple order constraint says that res1 must start first, then res2, then res3. However, if you put res2 and res3 in a resource set, the constraint would say that res1 must start first, and then res2 and res3 can start in any order.

    Order constraints can use round brackets or square brackets to group the resources.

  • In a colocation constraint, a resource set gives multiple resources the same relationship to the next resource. For example, a simple colocation constraint says that res1 must run on the same node as res2, which must run on the same node as res3. However, if you put res1 and res2 in a resource set, the constraint would say that res1 and res2 must run on the same node as res3, but aren't otherwise dependent on each other.

    Colocation constraints can use round brackets or square brackets to group the resources.

The syntax for resource sets can be complex, so before using them in a production environment, we recommend testing them to make sure the resources behave as expected.

For more information about the syntax of resource sets and the difference between round and square brackets, run crm help Resourcesets.

2.4 For more information

 

3 Adding order constraints

 

Order constraints tell the cluster to start resources in a specific order and stop them in the reverse order. You can also start or stop a resource right before or after a different resource performs a certain action, such as being promoted.

Instead of a score, order constraints have a kind. The kind can be one of the following:

  • Mandatory: Resources must start in this order.

  • Optional: The start order is only a preference.

  • Serialize: A resource must finish starting before the next resource can begin starting. This is useful for resources that put a high load on the node during start-up, for example.

You can add order constraints with the CRM Shell (crmsh) or with the Hawk Web interface.

  • CRM Shell
  • Hawk

You can perform this procedure on any node in the cluster.

  1. Log in either as the root user or as a user with sudo privileges.

  2. Add an order constraint. The basic command requires a name, a kind, and at least two resources: 

    > sudo crm configure order ORDER_NAME KIND: RESOURCE1 RESOURCE2

    The KIND can be Mandatory, Optional or Serialize.

    Additional options
     
    Resource sets

    You can use round brackets or square brackets to group resources in an order constraint. In this example, res1 must start first, and then res2 and res3 can start in any order: 

    > sudo crm configure order res1-first Mandatory: res1 [ res2 res3 ]

    Round brackets are treated as special characters in most shells, so for crm commands that aren't in interactive mode, you must escape the brackets with \: 

    > sudo crm configure order res1-first Mandatory: res1 \( res2 res3 \)

    For more information about the difference between round and square brackets, run crm help Resourcesets.

    Symmetry

    In most cases, you should keep the default symmetrical=true, which means that resources stop in the reverse of their start order. However, if necessary, you can change it to false.

    Actions

    You can require a resource to perform an action (start, stop, promote or demote) before or after another resource starts. In this example, res1 must start before clone2 can be promoted: 

    > sudo crm configure order res1-pr-clone2 Mandatory: res1 clone2:promote

  3. You can view all order constraints with the following command: 

    > sudo crm configure show type:order
For more information
 

4 Adding location constraints

 

Location constraints tell the cluster where resources can or cannot run. You can specify that a resource must or must not run on a particular node, or give the resource an optional preference for or against a node.

Location constraints use a score to indicate how important the constraint is. A score of INFINITY (positive or negative) means that the constraint must be applied. The score can also be a non-infinite number (positive or negative), which means the constraint is only a preference. You can also add multiple location constraints with different scores to prioritize node preferences.

You can add location constraints with the CRM Shell (crmsh) or with the Hawk Web interface.

  • CRM Shell
  • Hawk

You can perform this procedure on any node in the cluster.

  1. Log in either as the root user or as a user with sudo privileges.

  2. Add a location constraint. The basic command requires a name, at least one resource, a score, and a node: 

    > sudo crm configure location LOCATION_NAME RESOURCE SCORE: NODE

    The SCORE can be inf, -inf or a number (positive or negative).

    Additional options
     
    Resource sets

    You can use curly brackets to include multiple resources in a location constraint. In this example, res1 and res2 must both run on node alice: 

    > sudo crm configure location res1-2-alice { res1 res2 } inf: alice
    Resource patterns

    You can use a resource pattern (a regular expression between two slashes) to refer to multiple resources. If you add new resources with the same name pattern, they will also be included in the location constraint. In this example, any resources beginning with res must run on node alice: 

    > sudo crm configure location all-res-alice /res.*/ inf: alice
    Resource discovery

    In most cases, you should keep the default resource-discovery=always. This means that the cluster checks whether the resource is already running, to help avoid unwanted instances of the resource. However, if necessary, you can change it to never or exclusive.

    Rules

    Instead of specifying a single node, you can use a rule to refer to multiple nodes. If you add more nodes that meet the rule, they will also be included in the location constraint. In this example, res1 can't run on any node where the custom node attribute memory is less than 4096: 

    > sudo crm configure location res1-no-small-nodes res1 \
  rule -inf: memory lt 4096

  3. Check the status to see which node the resources are now running on: 

    > sudo crm status
For more information
 

5 Adding colocation constraints

 

Colocation constraints tell the cluster which resources can or cannot run together on the same node. You can specify that the resources must or must not run together, or give a resource an optional preference for or against another resource.

Colocation constraints use a score to indicate how important the constraint is. A score of INFINITY (positive or negative) means that the constraint must be applied. The score can also be a non-infinite number (positive or negative), which means the constraint is only a preference.

Important
Important: Resource start order

Colocation constraints don't affect the order in which the resources start. If you want resources to run on the same node and start in a specific order, create a resource group.

You can add colocation constraints with the CRM Shell (crmsh) or with the Hawk Web interface.

  • CRM Shell
  • Hawk

You can perform this procedure on any node in the cluster.

  1. Log in either as the root user or as a user with sudo privileges.

  2. Add a colocation constraint. The basic command requires a name, a score and at least two resources: 

    > sudo crm configure colocation COLOCATION_NAME SCORE: RESOURCE1 RESOURCE2

    The SCORE can be inf, -inf or a number (positive or negative).

    RESOURCE2 is assigned to a node first, and RESOURCE1 is placed relative to RESOURCE2.

    Additional options
     
    Resource sets

    You can use round brackets or square brackets to group resources in a colocation constraint. In this example, res1 and res2 must run on the same node as res3, but aren't otherwise dependent on each other: 

    > sudo crm configure colocation res1-2-with-res3 \
  inf: [ res1 res2 ] res3

    Round brackets are treated as special characters in most shells, so for crm commands that aren't in interactive mode, you must escape the brackets with \: 

    > sudo crm configure colocation res1-2-with-res3 \
  inf: \( res1 res2 \) res3

    For more information about the difference between round and square brackets, run crm help Resourcesets.

    Roles

    You can require a role (Started, Stopped, Promoted or Unpromoted) for one or more resources. The colocation constraint only applies when the resource is in this role. In this example, res1 must run on the same node where clone2 is in the Promoted role: 

    > sudo crm configure colocation res1-with-pr-clone2 \
  inf: res1 clone2:Promoted
    Node attributes

    You can use a node attribute to colocate resources on a group of nodes instead of one node. In this example, res1 and res2 don't have to run on the same node, but must run on nodes with the same value for the datacenter node attribute: 

    > sudo crm configure colocation res1-2-same-dc \
  inf: res1 res2 node-attribute=datacenter

  3. Check the status to see which node the resources are now running on: 

    > sudo crm status
For more information
 

6 Colocating resources without adding dependency

 

A colocation constraint creates dependency between the resources. If one resource fails, the cluster also restarts the other resource. However, sometimes you might need to place resources together without any dependency. You can do this with the CRM Shell's weak-bond command. This creates a Dummy resource, then creates a colocation constraint between the Dummy resource and the resources you specify.

You can perform this procedure on any node in the cluster.

  1. Log in either as the root user or as a user with sudo privileges.

  2. Run the following command, specifying two or more primitive resources: 

    > sudo crm configure assist weak-bond RESOURCE1 RESOURCE2
Create weak bond / independent colocation
The following elements will be created:
   * Colocation constraint, ID: place-constraint-1
   * Dummy resource, ID: place-dummy-1
Create resources (y/n)?

  3. Enter y to create the Dummy resource and colocation constraint.

  4. View the new constraint: 

    > sudo crm configure show place-constraint-1

  5. Check which node the resources are running on: 

    > sudo crm status
For more information
 

  • crm assist weak-bond --help