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

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.

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.

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: