Product SiteDocumentation Site

Chapter 10. Advanced Resource Types

Table of Contents

10.1. Groups - A Syntactic Shortcut
10.1.1. Group Properties
10.1.2. Group Options
10.1.3. Group Instance Attributes
10.1.4. Group Contents
10.1.5. Group Constraints
10.1.6. Group Stickiness
10.2. Clones - Resources That Get Active on Multiple Hosts
10.2.1. Clone Properties
10.2.2. Clone Options
10.2.3. Clone Instance Attributes
10.2.4. Clone Contents
10.2.5. Clone Constraints
10.2.6. Clone Stickiness
10.2.7. Clone Resource Agent Requirements
10.3. Multi-state - Resources That Have Multiple Modes
10.3.1. Multi-state Properties
10.3.2. Multi-state Options
10.3.3. Multi-state Instance Attributes
10.3.4. Multi-state Contents
10.3.5. Monitoring Multi-State Resources
10.3.6. Multi-state Constraints
10.3.7. Multi-state Stickiness
10.3.8. Which Resource Instance is Promoted
10.3.9. Requirements for Multi-state Resource Agents
10.4. Bundles - Isolated Environments
10.4.1. Bundle Properties
10.4.2. Docker Properties
10.4.3. rkt Properties
10.4.4. Bundle Network Properties
10.4.5. Bundle Storage Properties
10.4.6. Bundle Primitive
10.4.7. Bundle Node Attributes
10.4.8. Bundle Meta-Attributes
10.4.9. Limitations of Bundles

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. A group of two primitive resources

<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="192.0.2.2"/>
    </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, too.
  • If Public-IP can’t run anywhere, neither can Email;
  • but 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="192.0.2.2"/>
     </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.
Another (typical) example of a group is a DRBD volume, the filesystem mount, an IP address, and an application that uses them.

10.1.1. Group Properties

Table 10.1. Properties of a Group Resource

Field Description
id
A unique name for the group

10.1.2. Group Options

Groups inherit the priority, target-role, and is-managed properties from primitive resources. See Section 5.4, “Resource Options” for information about those properties.

10.1.3. Group Instance Attributes

Groups have no instance attributes. However, any that are set for the group object will be inherited by the group’s children.

10.1.4. Group Contents

Groups may only contain a collection of cluster resources (see Section 5.3, “Resource Properties”). To refer to a child of a group resource, just use the child’s id instead of the group’s.

10.1.5. Group Constraints

Although it is possible to reference a group’s children in constraints, it is usually preferable to reference the group itself.

Example 10.3. Some 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.6. Group Stickiness

Stickiness, the measure of how much a resource wants to stay where it is, is additive in groups. Every active resource of the group will contribute its stickiness value to the group’s total. So if the default resource-stickiness is 100, and 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.