Having all the resources configured is only part of the job. Even if the cluster knows all needed resources, it might still not be able to handle them correctly. Resource constraints let you specify which cluster nodes resources can run on, what order resources will load, and what other resources a specific resource is dependent on.
There are three different kinds of constraints available:
Locational constraints that define on which nodes a resource may be run, may not be run or is preferred to be run.
Collocational constraints that tell the cluster which resources may or may not run together on a node.
Ordering constraints to define the sequence of actions.
For more information on configuring constraints and detailed background information about the basic concepts of ordering and collocation, refer to the following documents available at http://clusterlabs.org/wiki/Documentation:
Pacemaker 1.0—Configuration Explained , chapter Resource Constraints
Collocation Explained
Ordering Explained
Learn how to add the various kinds of constraints with the GUI in Section 5.3.3, Configuring Resource Constraints. If you prefer the command line approach, see Section 6.3.4, Configuring Resource Constraints.
When defining constraints, you also need to deal with scores. Scores of all kinds are integral to how the cluster works. Practically everything from migrating a resource to deciding which resource to stop in a degraded cluster is achieved by manipulating scores in some way. Scores are calculated on a per-resource basis and any node with a negative score for a resource cannot run that resource. After calculating the scores for a resource, the cluster then chooses the node with the highest score.
INFINITY is currently defined as 1,000,000. Additions or subtractions with it stick to the following three basic rules:
Any value + INFINITY = INFINITY
Any value - INFINITY = -INFINITY
INFINITY - INFINITY = -INFINITY
When defining resource constraints, you specify a score for each constraint. The score indicates the value you are assigning to this resource constraint. Constraints with higher scores are applied before those with lower scores. By creating additional location constraints with different scores for a given resource, you can specify an order for the nodes that a resource will fail over to.
A resource will be automatically restarted if it fails. If that cannot be achieved on the current node, or it fails N times on the current node, it will try to fail over to another node. Each time the resource fails, its failcount is raised. You can define a number of failures for resources (a migration-threshold), after which they will migrate to a new node. If you have more than two nodes in your cluster, the node a particular resource fails over to is chosen by the High Availability software.
However, you can specify the node a resource will fail over to by configuring one or several location constraints and a migration-threshold for that resource. For detailed instructions how to achieve this with the GUI, refer to Section 5.3.4, Specifying Resource Failover Nodes. If you prefer the command line approach, see Section 6.3.5, Specifying Resource Failover Nodes.
Example 4-2 Migration Threshold—Process Flow
For example, let us assume you have configured a location constraint for resource r1 to preferably run on node1. If it fails there, migration-threshold is checked and compared to the failcount. If failcount >= migration-threshold then the resource is migrated to the node with the next best preference.
By default, once the threshold has been reached, the node will no longer be allowed to run the failed resource until the resource's failcount is reset. This can be done manually by the cluster administrator or by setting a failure-timeout option for the resource.
For example, a setting of migration-threshold=2 and failure-timeout=60s would cause the resource to migrate to a new node after two failures and potentially allow it to move back (depending on the stickiness and constraint scores) after one minute.
There are two exceptions to the migration threshold concept, occurring when a resource either fails to start or fails to stop:
Start failures set the failcount to INFINITY and thus always cause an immediate migration.
Stop failures cause fencing (when stonith-enabled is set to true which is the default).
In case there is no STONITH resource defined (or stonith-enabled is set to false), the resource will not migrate at all.
For details on using migration thresholds and resetting failcounts, refer to Section 5.3.4, Specifying Resource Failover Nodes. If you prefer the command line approach, see Section 6.3.5, Specifying Resource Failover Nodes.
A resource might fail back to its original node when that node is back online and in the cluster. If you want to prevent a resource from failing back to the node it was running on prior to failover, or if you want to specify a different node for the resource to fail back to, you must change its resource stickiness value. You can either specify resource stickiness when you are creating a resource, or afterwards.
Consider the following implications when specifying resource stickiness values:
This is the default. The resource will be placed optimally in the
system. This may mean that it is moved when a better
or less loaded node becomes available. This option is almost
equivalent to automatic failback, except that the resource may be
moved to a node that is not the one it was previously active on.
The resource will prefer to remain in its current location, but may be moved if a more suitable node is available. Higher values indicate a stronger preference for a resource to stay where it is.
The resource prefers to move away from its current location. Higher absolute values indicate a stronger preference for a resource to be moved.
The resource will always remain in its current location unless forced off because the node is no longer eligible to run the resource (node shutdown, node standby, reaching the migration-threshold, or configuration change). This option is almost equivalent to completely disabling automatic failback.
The resource will always move away from its current location.
Not all resources are equal. Some, such as Xen guests, require that the node hosting them meets their capacity requirements. If resources are placed such that their combined need exceed the provided capacity, the resources diminish in performance (or even fail).
To take this into account, the High Availability Extension allows you to specify the following parameters:
The capacity a certain node provides.
The capacity a certain resource requires.
An overall strategy for placement of resources.
Currently, these settings are static and must be configured by the administrator—they are not dynamically discovered or adjusted.
Learn how to configure these settings with the GUI in Section 5.3.6, Configuring Placement of Resources Based on Load Impact. If you prefer the command line approach, see Section 6.3.7, propertyplacement-strategy=balanced.
A node is considered eligible for a resource if it has sufficient free capacity to satisfy the resource's requirements. The nature of the required or provided capacities is completely irrelevant for the High Availability Extension, it just makes sure that all capacity requirements of a resource are satisfied before moving a resource to a node.
To configure the resource's requirements and the capacity a node provides, use utilization attributes. You can name the utilization attributes according to your preferences and define as many name/value pairs as your configuration needs. However, the attribute's values must be integers.
The placement strategy can be specified with the placement-strategy property (in the global cluster options). The following values are available:
Utilization values are not considered at all. Resources are allocated according to location scoring. If scores are equal, resources are evenly distributed across nodes.
Utilization values are considered when deciding if a node has enough free capacity to satisfy a resources's requirements. However, load-balancing is still done based on the number of resources allocated to a node.
Utilization values are considered when deciding if a node has enough free capacity to satisfy a resource's requirements. An attempt is made to concentrate the resources on as few nodes as possible (in order to achieve power savings on the remaining nodes).
Utilization values are considered when deciding if a node has enough free capacity to satisfy a resource's requirements. An attempt is made to distribute the resources evenly, thus optimizing resource performance.
NOTE: Configuring Resource Priorities
The available placement strategies are best-effort—they do not yet use complex heuristic solvers to always reach optimum allocation results. Thus, set your resource priorities in a way that makes sure that your most important resources are scheduled first.
Example 4-3 Example Configuration for Load-Balanced Placing
The following example demonstrates a three-node cluster of equal nodes, with four virtual machines.
node node1 utilization memory="4000"
node node2 utilization memory="4000"
node node3 utilization memory="4000"
primitive xenA ocf:heartbeat:Xen utilization memory="3500" \
meta priority="10"
primitive xenB ocf:heartbeat:Xen utilization memory="2000" \
meta priority="1"
primitive xenC ocf:heartbeat:Xen utilization memory="2000" \
meta priority="1"
primitive xenD ocf:heartbeat:Xen utilization memory="1000" \
meta priority="5"
property placement-strategy="minimal"
With all three nodes up, resource xenA will be placed onto a node first, followed by xenD. xenB and xenC would either be allocated together or one of them with xenD.
If one node failed, too little total memory would be available to host them all. xenA would be ensured to be allocated, as would xenD. However, only one of the remaining resources xenB or xenC could still be placed. Since their priority is equal, the result would still be open. To resolve this ambiguity as well, you would need to set a higher priority for either one.