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
Groups - A Syntactic Shortcut) 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.
<constraints>
<rsc_colocation id="coloc-1" rsc="B" with-rsc="A" score="INFINITY"/>
<rsc_colocation id="coloc-2" rsc="C" with-rsc="B" score="INFINITY"/>
<rsc_colocation id="coloc-3" rsc="D" with-rsc="C" score="INFINITY"/>
</constraints>
Example 6.13. A chain of collocated resources
To make things easier, we allow an alternate form of colocation constraints using resource_sets. 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.
<constraints>
<rsc_colocation id="coloc-1" score="INFINITY" >
<resource_set id="collocated-set-example" sequential="true">
<resource_ref id="A"/>
<resource_ref id="B"/>
<resource_ref id="C"/>
<resource_ref id="D"/>
</resource_set>
</rsc_colocation>
</constraints>
Example 6.14. The equivalent colocation chain expressed using resource_sets
Note
Resource sets have the same colocation semantics as groups.
<group id="dummy">
<primitive id="A" .../>
<primitive id="B" .../>
<primitive id="C" .../>
<primitive id="D" .../>
</group>
Example 6.15. A group resource with the equivalent colocation rules
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.
<constraints>
<rsc_colocation id="coloc-1" score="INFINITY" >
<resource_set id="collocated-set-1" sequential="false">
<resource_ref id="A"/>
<resource_ref id="B"/>
<resource_ref id="C"/>
</resource_set>
<resource_set id="collocated-set-2" sequential="true">
<resource_ref id="D"/>
</resource_set>
</rsc_colocation>
</constraints>
Example 6.16. Using colocation sets to specify a common peer.
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.
<constraints>
<rsc_colocation id="coloc-1" score="INFINITY" >
<resource_set id="collocated-set-1" sequential="true">
<resource_ref id="A"/>
<resource_ref id="B"/>
</resource_set>
<resource_set id="collocated-set-2" sequential="false">
<resource_ref id="C"/>
<resource_ref id="D"/>
<resource_ref id="E"/>
</resource_set>
<resource_set id="collocated-set-2" sequential="true" role="Master">
<resource_ref id="F"/>
<resource_ref id="G"/>
</resource_set>
</rsc_colocation>
</constraints>
Example 6.17. A colocation chain where the members of the middle set have no inter-dependencies and the last has master status.