Preface

This document will describe a simple and common resource configuration. We'll configure a Active/Passive configuration that makes an apache2 service high available on a shared IP. The configuration will also contain monitors and starting the resources will be done using a group. We will also try to explain our configuration and other possibilities in a short and clear way. If you want to know more you will be pointed at other documents who explain these possibilities further.

The configuration below excluded you also need to configure your [authkeys] and [ha.cf] to have a complete heartbeat configuration

mars and venus will be the two nodes I'll be using in this example. mars being the active and venus the passive.

Configuring Resources

As I said before this file only explains the resource configuration in heartbeat v2. The config file is located at /var/lib/heartbeat/crm/cib.xml. Basicly this file specifies the resource(s) for the cluster and where this resource should be executed.

There are 3 ways you can create this file:

• Write it manually

• Create it using admintools, found in /usr/lib/heartbeat.

• Use the python conversion script

In this example we will create the configuration file using the python-convert script, since this is the fasted way. So first we need to make an haresources file.

vi /root/haresources.temp

mars 10.0.200.30/16/eth0 apache2

convert the file to HAv2 style:

HA 2.0.2 :python /usr/lib/heartbeat/cts/haresources2cib.py /root/haresources.temp > /var/lib/heartbeat/crm/cib.xml
HA 2.0.3 :python /usr/lib/heartbeat/haresources2cib.py /root/haresources.temp > /var/lib/heartbeat/crm/cib.xml

The Example

This is what the python script will generate for us:

<?xml version="1.0" ?>
<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/>
        <resources>
            <group id="group_1">
                <primitive class="ocf" id="IPaddr_1" provider="heartbeat" type="IPaddr">
                     <operations>
                        <op id="1" interval="5s" name="monitor" timeout="5s"/>
                     </operations>
                     <instance_attributes>
                        <attributes>
                            <nvpair name="ip" value="10.0.200.30"/>
                            <nvpair name="netmask" value="16"/>
                            <nvpair name="nic" value="eth0"/>
                        </attributes>
                    </instance_attributes>
                </primitive>
                <primitive class="ocf" id="apache2id" provider="heartbeat" type="apache2">
                    <operations>
                       <op id="3" name="monitor" interval="10s" timeout="10s"/>
                    </operations>
                </primitive>
            </group>
        </resources>
        <constraints>
            <rsc_location id="rsc_location_group_1" rsc="group_1">
                <rule id="prefered_location_group_1" score="100">
                    <expression attribute="#uname" operation="eq" value="mars"/>
                </rule>
            </rsc_location>
        </constraints>
    </configuration>
    <status/>
</cib>

An Empty CIB

<cib>
   <configuration>
     <crm_config/>
     <nodes/>
     <resources/>
     <constraints/>
   </configuration>
   <status/>
</cib>

As you can see, the CIB is broken primarily into 2 parts:

• configuration: Where you configure everything about resources.

• status: You should never need to touch the status portion, however you can read more about it here: ClusterInformationBase/UnderstandingStatus.

crm_config

crm_config is where you define general resource options.

The configuration I have in my example was generated by the python convert script. you don't have to configure anything in de crm_config, because the default values are not bad. But If you want to know more, tweak heartbeat or you are using STONITH have a look at this.

node

Defines which nodes are part of the cluster.

The nodes section can be mostly ignored as it will be filled in automatically by the system. It is usually best to allow this to happen automatically as the most important value is the UUID of the node which can be easy to get wrong. I want to know more

resources

Defines the resources you will be using, in this tag you also configure your monitors and give some needed parameters to the resources.

Defining which resources you want to use in heartbeat is an important part of configuring heartbeat. There are 2 way's you can define these resources. you can put several resources in a resourcegroup, and even define more than one resourcegroup. It is also possible to define the resources separate without a group. But if you do, you'll have to define for each resource on which node it has to start. So it will result in a more complicated constrain defenition. This is why we will use a group because it is much easier if you want to start and stop a bunch of resources sequential.

Note: There is also a way to group nodes, this is done using UsingAttributes This is usefull if you have more than 2 nodes.

        <resources>
            <group id="group_1">
                <primitive class="ocf" id="IPaddr_1" provider="heartbeat" type="IPaddr">
                     <operations>
                        <op id="1" interval="5s" name="monitor" timeout="5s"/>
                     </operations>
                     <instance_attributes>
                        <attributes>
                            <nvpair name="ip" value="10.0.200.30"/>
                            <nvpair name="netmask" value="16"/>
                            <nvpair name="nic" value="eth0"/>
                        </attributes>
                    </instance_attributes>
                </primitive>
                <primitive class="ocf" id="apache2id" provider="heartbeat" type="apache">
                    <operations>
                       <op id="3" name="monitor" interval="10s" timeout="10s"/>
                    </operations>
                </primitive>
            </group>
        </resources>

The attributes:

• id: The id is always just an id that you can use to call the group or primitive.
• class: The class defines which Resource Agent to use there are 3 possible:
  • class=""ocf": use the scripts in /usr/lib/ocf/resource.d/heartbeat/
  • class="heartbeat": use the scripts in /etc/ha.d/resource.d/
  • class="lsb": use the scripts in /etc/init.d/
  • note: the lsb takes no arguments so you cant use operations with the lsb class.
• provider: Only needed if the class is ocf, than the provider is heartbeat, when class is lsb you don't need this attribute.
• type: Is the name of the startup script you are going to use.

the resource part in my example explained:

• There is one group named 'group_1'
  • In the group there are two resources configured (the primitives)
    • The first resource we make an alias ip address using the ocf script
      • The ip alias is checked every 5 seconds by the monitor
      • In the attributes we'll specify the ip alias had the ip address 10.0.200.30 and more...
    • The second resource is the apache2 server, using also a script in the ocf lib.
      • The apache server is also checked if still up every 10 seconds

more about resource

Constraints

Basicly, this is where you define which resource should start on which node.

In our example this is simple:

        <constraints>
            <rsc_location id="rsc_location_group_1" rsc="group_1">
                <rule id="prefered_location_group_1" score="100">
                    <expression attribute="#uname" operation="eq" value="mars"/>
                </rule>
            </rsc_location>
        </constraints>

In rsc_location you say with rsc "this group(group_1)". And in expression you define on wich node it should start first.

If you have only two node this is very simple then it runs on one node and if it fails it runs on the other. But if you have al large cluster it is better to specify where a resource should be running.

Constraints has much more possibilities, These however will be explained in other documents.

I want to know more

See Also

• v2/Examples/Advanced

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

• A Two IP address Active/Active Configuration

• A Basic Apache Web Server Configuration

• Two Apache Web Servers in an Active/Active Configuration

• Other simple examples are also available.

Linux-HA site built by the Linux-HA crowd. HTML4 / CSS2