/ 5.5. Configuring Resource Constraints
	5.4. Creating a STONITH Resource		5.6. Specifying Resource Failover Nodes

Configuring Resource Constraints

Having all the resources configured is only one part of the job. Even if the cluster knows all needed resources, it might still not be able to handle them correctly. For example, it would not make sense 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 High Availability, there are three different kinds of constraints available:

Locational constraints that define on which nodes a resource may be run (in the crm shell with the command location).
Collocational constraints that tell the cluster which resources may or may not run together on a node (colocation).
Ordering constraints to define the sequence of actions (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 fs1-loc on the node with the name earth to 100 would be the following:

crm(live)configure# location fs1-loc fs1 100: earth

Collocational Constraints

The colocation command is used to define what resources should run on the same or on different hosts. Usually it is very common to use the following sequence:

crm(live)configure# order rsc1 rsc2
crm(live)configure# colocation rsc2 rsc1

It is only possible to set a score of either +INFINITY or -INFINITY, defining resources that must always or must never run on the same node. For example, to run the two resources with the IDs filesystem_resource and nfs_group always on the same host, use the following constraint:

crm(live)configure# colocation nfs_on_filesystem inf: nfs_group filesystem_resource

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. Use the following commands in the crm shell to configure an an ordering constraint:

crm(live)configure# order nfs_after_filesystem mandatory: group_nfs filesystem_resource

Constraints for the Example Configuration

The example used for this chapter would not work as expected 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.

crm(live)configure# colocation filesystem_on_master inf: \
    filesystem_resource drbd_resource:Master

The NFS server as well as the IP address must be on the same node as the file system.
```
crm(live)configure# colocation nfs_with_fs inf: \
   nfs_group filesystem_resource
```
The NFS server as well as the IP address start after the file system is mounted:
```
crm(live)configure# order nfs_second mandatory: \
   filesystem_resource nfs_group
```
The file system must be mounted on a node after the drbd resource is promoted to master on this node.
```
crm(live)configure# order drbd_first inf: \
    drbd_resource:promote filesystem_resource
```