Scores

- Specifying the Order Resources Should Start/Stop In - The way to specify the order in which resources should start is by creating rsc_order constraints. + Specifying Resource Start/Stop Order + Use a rsc_order constraint to specify resource ordering. Properties of an Ordering Constraint @@ -152,11 +152,11 @@ first - The name of a resource that must be started before the then resource is allowed to. + The name of a resource that must be started before the then resource. then - The name of a resource. This resource will start after the first resource. + The name of a resource that must be started after the first resource. score @@ -165,7 +165,7 @@ symmetrical - If true, which is the default, stop the resources in the reverse order. Default value: true + If true, stop the resources in the reverse order. Default value: true @@ -174,7 +174,7 @@ Mandatory Ordering When the then resource cannot run without the first resource being active, one should use mandatory constraints. - To specify a constraint is mandatory, use a scores greater than zero. + To specify a constraint as mandatory, use a score greater than zero. This will ensure that the then resource will react when the first resource changes state. @@ -190,7 +190,7 @@ Any change in state by the first resource will have no effect on the then resource. - Example of an optional and mandatory ordering constraint + Example of an optional and a mandatory ordering constraint @@ -212,7 +212,7 @@ If you think about it, its somewhat obvious. You can't place A relative to B unless you know where B is - While the human brain is sophisticated enough to read the constraint in any order and choose the correct one depending on the situation, the cluster is not quite so smart. Yet. + While the human brain is sophisticated enough to read the constraints in any order and choose the correct one depending on the situation, the cluster is not quite so smart. Yet. . So when you are creating colocation constraints, it is important to consider whether you should colocate A with B or B with A. @@ -238,11 +238,11 @@ rsc - The colocation source. If the constraint cannot be satisfied, the cluster may decide not to allow the resource to run at all. + The resource to be colocated. If the constraint cannot be satisfied, the cluster may decide not to allow this resource to run at all. with-rsc - The colocation target. The cluster will decide where to put this resource first and then decide where to put the resource in the rsc field + The resource target. The cluster will decide where to put this resource first and then decide where to put the colocation resource specified in the rsc field score @@ -261,7 +261,7 @@ If you need resource1 to always run on the same machine as resource2, you would add the following constraint: - An example colocation constraint + An example mandatory colocation constraint <rsc_colocation id="colocate" rsc="resource1" with-rsc="resource2" score="INFINITY"/> @@ -273,7 +273,7 @@ In this case use score="-INFINITY" - An example anti-colocation constraint + An example mandatory anti-colocation constraint <rsc_colocation id="anti-colocate" rsc="resource1" with-rsc="resource2" score="-INFINITY"/> @@ -324,9 +324,9 @@ - To simplify this situation, there is an alternate format for ordering constraints + Resource sets were introduced for ordering and dependency contraints to simplify this situation. - A chain of ordered resources expressed as a set + A set used to express a chain of ordeered resources. @@ -416,7 +416,7 @@

- Three Resources Sets + Three Resource Sets @@ -430,7 +430,7 @@ Collocating Sets of Resources Another common situation is for an administrator to create a set of collocated resources. - Previously this possible either by defining a resource group (See ) which could not always accurately express the design; or by defining each relationship as an individual constraint, causing a constraint explosion as the number of resources and combinations grew. + Previously this was possible either by defining a resource group (See ) which could not always accurately express the design; or by defining each relationship as an individual constraint, causing a constraint explosion as the number of resources and combinations grew. A chain of collocated resources @@ -445,12 +445,12 @@ - To make things easier, we allow an alternate form of colocation constraints using resource_sets. + Using resource sets for complex colocation contraints makes things easier. Just like the expanded version, a resource that can't be active also prevents any resource that must be collocated with it from being active. For example if B was not able to run, then both C (and by inference D) must also remain stopped. - The equivalent colocation chain expressed using resource_sets + A resource set for the same colocation dependency chain @@ -468,7 +468,7 @@ Resource sets have the same colocation semantics as groups. - A group resource with the equivalent colocation rules + A group resource for the same colocation dependency chain @@ -481,8 +481,8 @@ - This notation can also be used in this context to tell the cluster that a set of resources must all be located with a common peer, but have no dependencies on each other. - In this scenario, unlike the previous on, B would be allowed to remain active even if A or C (or both) were inactive. + This notation can also be used in this context to tell the cluster that a set of resources must all be located with a common peer, but have no ordering dependencies on each other. + In this scenario, unlike the previous one, B would be allowed to remain active even if A or C (or both) were inactive. Using colocation sets to specify a common peer. @@ -505,11 +505,11 @@ Of course there is no limit to the number and size of the sets used. - The only thing that matters is that in order for any member of set N to be active, all the members of set N+1 must also be active (and naturally on the same node), and that if a set has sequential="true", then in order for member M to be active, member M+1 must also be active. - You can even specify the role in which the members of a set must be in using the set's role attribute. + The only thing that matters is that in order for any member of a set to be active, all the members of the previous set must also be active (and naturally on the same node). When a set has sequential="true", then in order for any member to be active, the previous members must also be active. + You can also specify a dependency on the members role by using the role attribute. - A colocation chain where the members of the middle set have no inter-dependencies and the last has master status. + A colocation chain where the members of the middle set have no order dependencies and the last has master status. @@ -534,12 +534,12 @@

- Another Three Resources Sets + Another Three Resource Sets - +