Chapter 10. Advanced Resource Types

Table of Contents

10.1. Groups - A Syntactic Shortcut

10.1.1. Properties
10.1.2. Options
10.1.3. Using Groups

10.2. Clones - Resources That Should be Active on Multiple Hosts

10.2.1. Properties
10.2.2. Options
10.2.3. Using Clones

10.3. Multi-state - Resources That Have Multiple Modes

10.3.1. Properties
10.3.2. Options
10.3.3. Using Multi-state Resources

10.1. Groups - A Syntactic Shortcut

One of the most common elements of a cluster is a set of resources that need to be located together, start sequentially and stop in the reverse order. To simplify this configuration we support the concept of groups.

Example 10.1. An example group


  <group id="shortcut">
   <primitive id="Public-IP" class="ocf" type="IPaddr" provider="heartbeat">
    <instance_attributes id="params-public-ip">
       <nvpair id="public-ip-addr" name="ip" value="1.2.3.4"/>
    </instance_attributes>
   </primitive>
   <primitive id="Email" class="lsb" type="exim"/>
  </group>

Although the example above contains only two resources, there is no limit to the number of resources a group can contain. The example is also sufficient to explain the fundamental properties of a group:

Resources are started in the order they appear in (Public-IP first, then Email)
Resources are stopped in the reverse order to which they appear in (Email first, then Public-IP)
If a resource in the group can't run anywhere, then nothing after that is allowed to run
- If Public-IP can’t run anywhere, neither can Email
- If Email can’t run anywhere, this does not affect Public-IP in any way

The group above is logically equivalent to writing:

Example 10.2. How the cluster sees a group resource


  <configuration>
   <resources>
    <primitive id="Public-IP" class="ocf" type="IPaddr" provider="heartbeat">
     <instance_attributes id="params-public-ip">
        <nvpair id="public-ip-addr" name="ip" value="1.2.3.4"/>
     </instance_attributes>
    </primitive>
    <primitive id="Email" class="lsb" type="exim"/>
   </resources>
   <constraints>
      <rsc_colocation id="xxx" rsc="Email" with-rsc="Public-IP" score="INFINITY"/>
      <rsc_order id="yyy" first="Public-IP" then="Email"/>
   </constraints>
  </configuration>

Obviously as the group grows bigger, the reduced configuration effort can become significant.

10.1.1. Properties

Table 10.1. Properties of a Group Resource

Field	Description
id	Your name for the group

10.1.2. Options

Options inherited from simple resources: priority, target-role, is-managed

10.1.3. Using Groups

10.1.3.1. Instance Attributes

Groups have no instance attributes, however any that are set here will be inherited by the group's children.

10.1.3.2. Contents

Groups may only contain a collection of primitive cluster resources. To refer to the child of a group resource, just use the child's id instead of the group's.

10.1.3.3. Constraints

Although it is possible to reference the group's children in constraints, it is usually preferable to use the group's name instead.

Example 10.3. Example constraints involving groups


  <constraints>
    <rsc_location id="group-prefers-node1" rsc="shortcut" node="node1" score="500"/>
    <rsc_colocation id="webserver-with-group" rsc="Webserver" with-rsc="shortcut"/>
    <rsc_order id="start-group-then-webserver" first="Webserver" then="shortcut"/>
  </constraints>

10.1.3.4. Stickiness

Stickiness, the measure of how much a resource wants to stay where it is, is additive in groups. Every active member of the group will contribute its stickiness value to the group's total. So if the default resource-stickiness is 100 a group has seven members, five of which are active, then the group as a whole will prefer its current location with a score of 500.