Chapter 5. Manual Configuration of a Cluster / 5.3. Configuring Constraints
	5.2. Configuring Resources		5.4. Configuring CRM Options

Configuring Constraints

Having all the resources configured is only part of the job. Even if the clusters knows all needed resources, it might still not be able to handle them correctly. For example, it would be quite useless to try to mount the file system on the slave node of drbd (in fact, this would fail with drbd). To inform the cluster about these things, define constraints.

In Heartbeat, there are three different kinds of constraints available:

Locational constraints that define on which nodes a resource may be run (rsc_location).
Colocational constraints that tell the cluster which resources may or may not run together on a node (rsc_colocation).
Ordering constraints to define the sequence of actions (rsc_order).

Locational Constraints

This type of constraint may be added multiple times for each resource. All rsc_location constraints are evaluated for a given resource. A simple example that increases the probability to run a resource with the ID filesystem_1 on the node with the name earth to 100 would be the following:

<rsc_location id="filesystem_1_location" rsc="filesystem_1">
   <rule id="pref_filesystem_1" score="100">
      <expression attribute="#uname" operation="eq" value="earth"/>
   </rule>
</rsc_location>

To take effect, the rsc_location tag must define an rsc attribute. The content of this attribute must be the ID of a resource of the cluster.

The score attribute is set by the rule tag depending on the following expression, and is used as a priority to run a resource on a node. The scores are calculated by rules (see http://wiki.linux-ha.org/ScoreCalculation for details.)

Whether a rule really is activated, changing the score, depends on the evaluation of an expression. Several different operations are defined and the special attributes #uname and #id may be used in the comparison.

It is also possible to use another rule or a date_expression. For more information, refer to crm.dtd, which is located at /usr/lib/heartbeat/crm.dtd.

Colocational Constraints

The rsc_colocation constraint is used to define what resources should run on the same or on different hosts. It is not possible to give a score other than INFINITY or -INFINITY, defining resources to run together always or never to run together. For example, to run the two resources with the IDs filesystem_resource and nfs_group always on the same host, use the following constraint:

<rsc_colocation 
  id="nfs_on_filesystem"
  to="filesystem_resource"
  from="nfs_group" 
  score="INFINITY"/>

For a master slave configuration, it is necessary to know if the current node is a master in addition to running the resource locally. This can be checked with an additional to_role or from_role attribute.

Ordering Constraints

Sometimes it is necessary to provide an order in which services must start. For example, you cannot mount a file system before the device is available to a system. Ordering constraints can be used to start or stop a service right before or after a different resource meets a special condition, such as being started, stopped, or promoted to master. An ordering constraint looks like the following:

<rsc_order id="nfs_after_filesystem" from="group_nfs" action="start"
      to="filesystem_resource" to_action="start" type="after"/>

With type="after", the action of the from resource is done after the action of the to resource.

Constraints for the Example Configuration

The example used for this chapter is quite useless without additional constraints. It is essential that all resources run on the same machine as the master of the drbd resource. Another thing that is critical is that the drbd resource must be master before any other resource starts. Trying to mount the drbd device when drbd is not master simply fails. The constraints that must be fulfilled look like the following:

The file system must always be on the same node as the master of the drbd resource.

<rsc_colocation id="filesystem_on_master" to="drbd_resource"
       to_role="master" from="filesystem_resource" score="INFINITY"/>

The file system must be mounted on a node after the drbd resource is promoted to master on this node.

<rsc_order id="drbd_first" from="filesystem_resource" action="start"
       to="drbd_resource" to_action="promote" type="after"/>

The NFS server as well as the IP address start after the file system is mounted.

<rsc_order id="nfs_second" from="nfs_group" action="start"
       to="filesystem_resource" to_action="start" type="after"/>

The NFS server as well as the IP address must be on the same node as the file system.

<rsc_colocation id="nfs_on_drbd" to="filesystem_resource"
       from="nfs_group" score="INFINITY"/>

In addition to that, issue constraint that prevents the NFS server from running on a node where drbd is running in slave mode.
```
<rsc_colocation id="nfs_on_slave" to="drbd_resource"
       to_role="slave" from="nfs_group" score="-INFINITY"/>
```