Constraints demystified

In Linux-HA Heartbeat, constraints are specifications for where and how you want to run your resources. They can take time to master but are important to having a functional cluster.

Heartbeat version 2 has three types of constraints:

򐂰 A location constraint specifies which cluster nodes to run for a particular resource.

򐂰 An ordering constraint specifies the order in which to run resources.

򐂰 A colocation constraint tells the cluster which resources might or might not run together on a node.

In the following sections, we provide an overview of each constraint and discuss usage scenarios. For implementation details of constraints, see Chapter 5,

“Linux-HA usage scenarios” on page 131.

2.4.1 Location constraints

With location constraints, you can tell Heartbeat where cluster resources should run. In Example 2-3 on page 33, we illustrate the usage of a location constraint.

In the example, the resource is an IP address. You can use the following settings to customize your location constraint:

rsc_location id The name of the location constraint. In Example 2-3 on page 33, the name is “location_IP”. Choose one that makes sense to you.

rsc The name of the resource this location constraint is for.

rule id The name of the rule for this resource. If you go through the HA Management GUI, this value is set for you. By default, it is set to prefered_<rsc_location id> and is normally fine.

score The probability of this rule being applied. INFINITY means always apply this rule. -INFINITY means never apply this rule.

You can also enter an integer number to indicate how much you want to apply this rule. The higher the value is, the more likely this rule will be applied.

expression attribute, operation, and value

These three fields define the rule of the location constraint.

expression attribute

The type of attribute to check. You can define the #uname,

#is_dc, and #id options. When #uname is specified, the host name is checked. When #is_dc is specified, a node is the Designated Coordinator might or might not be

checked. When #id is specified, the node ID is checked.

The #id option is not commonly used and is not recommended. When you want to specify a particular node, use the #uname option.

operation

The Boolean operation that the rule checks between the expression attribute field and the value field.

#value

The value to the option chosen in the expression attribute field. For example, if expression attribute=#uname, then the value field must be set to the host name of the node where you want the rule to apply. If expression

attribute=#is_dc, then the value field can be either true or false. When it is true, the rule applies to the Designated Coordinator node. When it is false, the rule applies to nodes that are not the DC. If expression attribute=#id, then the value field must be set to the ID of the node where you want the rule to apply. As mentioned earlier, the #id option for expression attribute is not commonly used and is not recommended.

You can specify the location constraint either through the HA Management GUI interface or the CLI. See Chapter 4, “Linux-HA release 2 installation and initial configuration” on page 57, and Chapter 5, “Linux-HA usage scenarios” on page 131, for implementation details.

To help you understand the location constraint better, Example 2-3 shows one in XML format.

Example 2-3 Location constraint

<rsc_location id="location_IP" rsc="Floating_IP">

<rule id="prefered_location_IP" score="INFINITY">

<expression attribute="#uname"

id="f4525b72-aed4-49b0-bca2-5a06b65aff8e" operation="eq"

value="lnxsu2"/>

</rule>

</rsc_location>

The nvpair of the id type in <expression attribute="#uname"

id="f4525b72-aed4-49b0-bca2-5a06b65aff8e" operation="eq"

value="lnxsu2"/> is a unique value that is automatically generated by the CRM and not something that you should specify. This location constraint is related to the resource named Floating_IP. Because of the INFINITY score, the preferred location in our example is always to run on the lnxsu2 node as specified by the following lines:

<expression attribute="#uname"

id="f4525b72-aed4-49b0-bca2-5a06b65aff8e" operation="eq"

value="lnxsu2"/>

2.4.2 Ordering constraints

Ordering constraints specify the order in which you want your resources to start or stop. They are convenient for multi-layered resource clusters in which order dependencies are extremely important. For example, you might need a Filesystem resource to be mounted before using the NFS server resource to export it as an NFS mount.

As with the location constraint, the following settings are mandatory for customizing your ordering constraint:

rsc_order id The name of the order constraint.

to With the default type of “before,” this setting specifies the name of the resource that starts first and stops second. With the type field set to “after,” the resource specified in this field is started second and stopped first.

from With the default type of “before,” this specifies the name of the resource that starts second, but stops first. With the type field set to “after,” the resource specified in this field is started first, and stopped second.

Aside from these settings, you can optionally set the following fields:

symmetrical This field can be set to one of two values, “true” or “false.” By default, it is set to “false,” which means that the resource that starts first is stopped second, and the resource that starts second is stopped first. This makes sense in most cases. For example, in our Filesystem and NFS scenario, we want to start the Filesystem resource first, before starting the NFS server that exports our Filesystem resource. When stopping the resources, we want to stop NFS before stopping Filesystem.

This is because we do not want to pull the Filesystem out from under NFS. You can also set this field to “true,” which means that the resource that starts first is also stopped first. Here the stop sequence mirrors, or is symmetrical to, the start sequence.

action This field specifies the action that is related to the ordering constraint. Options are “start” and “stop.” By default, both actions are accounted for in the ordering constraint.

type This field specifies the type of order, either “before” or “after.”

By default, the type is “before.”

As with the location constraint, you can specify the ordering constraint either through the HA Management GUI or the CLI. See Chapter 5, “Linux-HA usage scenarios” on page 131, for implementation details.

To help you understand the ordering constraint better, Example 2-4 shows an ordering constraint in the XML format.

Example 2-4 An ordering constraint

<rsc_order id="NFS_after_Filesystem" to="Filesystem_ocfs2" from="NFS server"/>

In Example 2-4, we define only the three mandatory fields. By default, the ordering constraint is not symmetrical and has the order type of “before.” This ordering constraint indicates to Heartbeat that the “Filesystem_ocfs2” resource must be started first before the “NFS server” resource. Reversely, “NFS server”

must be stopped before “Filesystem_ocfs2”.

2.4.3 Colocation constraint

A colocation constraint tells the cluster which two resources must reside on the same node or which two resources must never reside on the same node.

You can customize your colocation constraint by using the following settings:

rsc_colocation id Specifies the name of your colocation constraint. Choose something that is clear.

from Specifies the resource name that is checked second.

Wherever the resource specified in the “to” nvpair is located, the resource in the “from” nvpair cannot be in the same place. However, vice versa is acceptable.

to Specifies the resource name that is checked first.

score INFINITY for specifying always or -INFINITY for specifying never.

You can specify the colocation constraint either through the HA Management GUI or the CLI. See Chapter 5, “Linux-HA usage scenarios” on page 131, for implementation details.

Example 2-5 illustrates one usage of the colocation constraint:

Example 2-5 Usage of a colocation constraint

<rsc_colocation id="Never_run_both_o2cb_on_same_node" from="lsb_o2cb:0"

to="lsb_o2cb:1" score="-INFINITY"/>

<rsc_colocation id="Never_run_both_o2cb_on_same_node_2"

from="lsb_o2cb:1" to="lsb_o2cb:0" score="-INFINITY"/>

The first rule prevents lsb_o2cb:0 from being on the same node as lsb_o2cb:1. If lsb_o2cb:1 is on every node, then lsb_o2cb:0 is not anywhere. If lsb_o2cb:0 is on every node, lsb:o2db:1 is not affected.

The second rule prevents the opposite from happening. Together, the two ensure that the two resources, lsb_o2cb:0 and lsb_o2cb:1, never run on the same node.