Preface

This document describes how to configure your resources without groups, how to use more than one group and there will be an explanation of constraints. Throughout this document we will use one example:

In the example there are 3 nodes: mars, venus and pluto, and 5 resources: named, apache, mysql and two IPs. The example will be more advanced with regard to groups and constraints. Things like monitors[1] and attributes[2] we did not use in this example to keep it more understandable.

We want to have the following setup:

• apache and its ip have to run on mars, it has to fail over to venus
• mysql and its ip have to run on venus, it has to fail over to mars or venus
• named has to run on pluto, it has to fail over to venus.

A configuration without groups

In a configuration without groups you just don't use the <group> tag and define your primitives in the <resource> tag. If symmetric_cluster = true the resources will run anywhere by default. If it is false you must define where they can run.

it looks something like this:

<resources>
    <primitive id="IPaddrid" class="ocf" type="IPaddr" provider="heartbeat">
       <instance_attributes>
            <attributes>
                <nvpair name="ip" value="10.0.0.10"/>
            </attributes>
       </instance_attributes>
    </primitive>
    <primitive id="mysqlid" class="lsb" type="mysql"/>
    <primitive id="apache2id" class="lsb" type="apache2"/>
</resources>

More groups

Groups are usefull to start or stop a several resources sequentialy, it also gives you a groupid that you can use in the constraints. Using that id you can address all the resources in the group, making your constraint section more simple.

<resources>
    <group id="group1">
        <primitive id="IPaddrid" class="ocf" type="IPaddr" provider="heartbeat">
             <instance_attributes>
                <attributes>
                    <nvpair name="ip" value="10.0.0.10"/>
                </attributes>
             </instance_attributes>
        </primitive>
        <primitive id="mysqlid" class="lsb" type="mysql"/>
    </group>
    <group id="group2">
        <primitive id="apache2id" class="lsb" type="apache2"/>
        <primitive id="bindid" class="lsb" type="bind"/>
    </group>
</resources>

Constraints, a step further

In a two cluster node constraints are simple, then it runs either on one node or the other, But in large clusters it is better to specify where a resource should run.

This is why we will use 3 nodes and 5 resources in the example.

<resources>
 <group id="apache_group">
  <primitive id="apache_ip" class="ocf" type="IPaddr" provider="heartbeat">
    <instance_attributes>
       <attributes>
         <nvpair name="ip" value="10.0.0.10"/>
       </attributes>
    </instance_attributes>
  </primitive>
  <primitive class="lsb" id="apache_id" type="apache"/>
 </group>
  <primitive class="lsb" id="named_id" type="named"/>
 <group id="mysl_group">
  <primitive class="lsb" id="mysql_id" type="mysql"/>
  <primitive id="mysql_ip" class="ocf" type="IPaddr" provider="heartbeat">
    <instance_attributes>
       <attributes>
         <nvpair name="ip" value="10.0.0.20"/>
       </attributes>
    </instance_attributes>
  </primitive>
 </group>
</resources>

You can specify 3 types of constraints:

• Locational Constraints: Where resources can/cannot be placed
• Co-locational Constraints: Where resources can/cannot be placed relative to other resources
• Ordering Constraints: What order to perform actions in

In one way or another, all constraints have a score. A score adjusts the resource's preference for running on any node matching the condition. Resources are never placed on nodes that end up with a negative score.

Two special values of score exist: INFINITY and -INFINITY. Processing of these special values is as follows:

 INFINITY +/- -INFINITY :  ERROR
 INFINITY +/-  int      :  INFINITY
-INFINITY +/-  int      : -INFINITY

Some constraints are implicit when the advanced resource types are used. For example in a group resource, it implied that they must all run on the same node, and that they will be started in order of listing (and stopped in the reverse order).

Co-Location Preferences

The simplest type of constraint to configure is a colocational one (see Annotated DTD[3]). One needs only to provide the id of two resources and a score to indicate if they cannot or if they must run on the same node.

The score for a co-locational constraint can currently only be INFINITY or -INFINITY, this may change in the future.

Use INFINITY to indicate the resource must run on the same node, and -INFINITY to indicate they should NEVER run on the same node.

Examples

Run the apache instance on the same machine as the apache ip:

<rsc_colocation id="web_same" from="apache_ip"
                to="apache_id" score="INFINITY"/>

Note: This constraint is already implicit becouse there is a group over these resources. The following constraint is more usefull: DON'T run apache and named on the same machine:

<rsc_colocation id="not_same" from="apache_group"
                to="named_id" score="-INFINITY"/>

Location Preferences

Locational constraints[4] use rules[5] and expressions[6] to match one or more cluster nodes and apply a score.

It is very important to point out how the symmetric_cluster[7] option affects the locational constraints you will need.

If symmetric_cluster is TRUE, then resources can run anywhere by default and you will need to either:

• specify where they CANNOT run using scores of -INFINITY, or
• specifying relative preferences (usually with a positive score)

If symmetric_cluster is FALSE, then resources cannot run anywhere by default and you will need to either:

• specify where they MUST run using scores of INFINITY, or
• specifying relative preferences (usually with a positive score)

The examples below work regardless of the value for symmetric_cluster.

More on rules and constraints can be found on the page ClusterInformationBase/AdvancedRules[8]

Examples

If possible, run apache_group on the node with uname="mars"

<rsc_location id="run_apache" rsc="apache_group">
    <rule id="pref_run_apache" score="100">
        <expression attribute="#uname" operation="eq" value="mars"/>
    </rule>
</rsc_location>

DON'T ever run named_id on the node with uname="mars"

<rsc_location id="dont_run_named" rsc="named_id">
    <rule id="pref_dont_run_named" score="-INFINITY">
        <expression attribute="#uname" operation="eq" value="mars"/>
    </rule>
</rsc_location>

To specify that apache_group can only ever run on the node with uname="mars" and nowhere else, one would use the following:

<rsc_location id="run_apache" rsc="apache_group">
    <rule id="pref_run_apache" score="INFINITY">
        <expression attribute="#uname" operation="eq" value="mars"/>
    </rule>
    <rule id="pref_run_apache" score="-INFINITY">
        <expression attribute="#uname" operation="ne" value="mars"/>
    </rule>
</rsc_location>

Order Preferences

The Order constraint enables you to define dependancies between two resources. You can define a resource should start or stop before or after an other resource

more info[9]

Examples

Apache Listens to an IP but that IP has to be started before apache can start. So the following defines the ip address has to start before apache server starts. symmetrical="TRUE" creates the reverse constraint.

<rsc_order id="apache_group_order" from="apache_ip" action="start" type="before" to="apache_id" symmetrical="true"/>

Note: both resources are in a group, which starts the resources sequentially. Since apache_ip is defined before apache_id this is in our example excessive.

The complete example

<cib>
    <configuration>
        <crm_config>
            <nvpair id="transition_idle_timeout" name="transition_idle_timeout" value="120s"/>
            <nvpair id="symmetric_cluster" name="symmetric_cluster" value="true"/>
            <nvpair id="no_quorum_policy" name="no_quorum_policy" value="stop"/>
        </crm_config>
        <nodes>
            <node id="f67904e0-4dfc-4db1-83a2-e930fc1d20f4" uname="mars" type="member"/>
            <node id="e9bdfde9-01b0-421f-acd8-8a65a53e775f" uname="venus" type="member"/>
            <node id="5d9a8c11-8684-43ea-9180-5e221530c193" uname="pluto" type="member"/>
        </nodes>
        <resources>
            <group id="apache_group">
                <primitive id="apache_ip" class="ocf" type="IPaddr" provider="heartbeat">
                    <instance_attributes>
                        <attributes>
                            <nvpair name="ip" value="10.0.0.10"/>
                        </attributes>
                    </instance_attributes>
                </primitive>
                <primitive class="lsb" id="apache_id" type="apache"/>
            </group>
            <primitive class="lsb" id="named_id" type="named"/>
            <group id="mysl_group">
                <primitive class="lsb" id="mysql_id" type="mysql"/>
                <primitive id="mysql_ip" class="ocf" type="IPaddr" provider="heartbeat">
                    <instance_attributes>
                        <attributes>
                            <nvpair name="ip" value="10.0.0.20"/>
                        </attributes>
                    </instance_attributes>
                </primitive>
            </group>
        </resources>
        <constraints>
            <rsc_colocation id="not_apache" from="apache_group" to="named_id" score="-INFINITY"/>
            <rsc_colocation id="not_named" from="named_id" to="apache_group" score="-INFINITY"/>
            <rsc_location id="location_apache_group" rsc="apache_group">
                <rule id="prefered_location_apache" score="100">
                    <expression attribute="#uname" operation="eq" value="mars"/>
                </rule>
                <rule id="prefered_location_apache" score="50">
                    <expression attribute="#uname" operation="eq" value="venus"/>
                </rule>
            </rsc_location>
            <rsc_location id="location_named" rsc="named_id">
                <rule id="prefered_location_named" score="100">
                    <expression attribute="#uname" operation="eq" value="pluto"/>
                </rule>
                <rule id="prefered_location_named" score="-INFINITY">
                    <expression attribute="#uname" operation="eq" value="mars"/>
                </rule>
            </rsc_location>
            <rsc_location id="location_mysql" rsc="mysql_group">
                <rule id="prefered_location_mysql" score="100">
                    <expression attribute="#uname" operation="eq" value="venus"/>
                </rule>
            </rsc_location>
        </constraints>
    </configuration>
    <status/>
</cib>

The example constraints explained

The first two constraints define apache group can't run with named and named not with apache group.

The first locational constraint defines that apachegroup runs on mars and if mars fails it has to run on venus

The second locational constraint says that it is preferred to run named on pluto and says that it may never run on mars. This implies it will fail over to venus.

The last constraint defines that mysql group preferred location is the venus node. it is not defined to which node it has to fail over. Because symmetrical="TRUE" CRM will choose on which node it will fail over.

See Also

• v2/Examples/Simple[10]

• A Basic Single IP Address Configuration[11] (newbies start here)

• A Two IP address Active/Active Configuration[12]

• A Basic Apache Web Server Configuration[13]

• Two Apache Web Servers in an Active/Active Configuration[14]

• Other simple examples[15] are also available.

---

This information provided courtesy of the Linux-HA project at http://linux-ha.org/