This site best when viewed with a modern standards-compliant browser. We recommend Firefox Get Firefox!.

Linux-HA project logo
Providing Open Source High-Availability Software for Linux and other OSes since 1999.

USA Flag UK Flag

Japanese Flag

ホームページ

サイトについて

コンタクト情報

使用条件

協力方法

セキュリティ

This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

2010.1.28
追加パッケージ集リニューアル
追加パッケージ集は、こちらから

2008.8.28
RHEL用rpm更新
更新情報はこちらから

2008.8.18
Heartbeat 2.1.4
リリース!
Downloadはこちらから

2007.11.13
Linux-ha-japan日本語ML移植しました

2007.10.5
日本語サイトOPEN
日本語MLも開設しました

2007.10.5
OSC2007 Tokyo/Fall で Heartbeat紹介
発表資料を公開しました

Last site update:
2017-12-14 23:46:42

Contents

  1. Introduction
  2. General Principles
  3. Extra features
  4. Conversion Examples

Introduction

To convert haresources files to a CIB, please use the haresources2cib.py script. Use it like this:

/usr/lib/heartbeat/haresources2cib.py --stdout -c ha.cf \
  haresources > cib.xml

Run the script with --help to get usage.

Note that if you installed Linux-HA somewhere else, then the pathnames need to change to match your installation.

haresources2cib.py converts heartbeat RAs such as IPaddr or apache to OCF RAs. To disable the conversion, use the --no-ocf option.

haresources2cib.py monitors each resource in the original haresources file. To disable adding any monitoring operations, use the --no-monitor option. To selectively disable certain monitoring, or to change the monitoring interval and timeout values, you have to modify the output file manually.

If you've used the haresources2cib.py command, you're mostly done. However, if you want to understand your configuration better by seeing how to do this by hand, then by all means read on!

General Principles

Entries in haresources files follow this format:

{hostname} {resource_type}::{parameter_value}::{parameter_value}::... \
    {resource_type}::{parameter_value}::{parameter_value}::...        \
    {resource_type}::{parameter_value}::{parameter_value}::...

For each line in haresources:

  • Create a <group id="group_N"> block, where N is an unused integer
    (this declares the resource group to the CRM)

  • Add a <rsc_location> child block to the <group> block:
    (this tells the CRM where the resource group is supposed to run)

    • Add a <rule> child block as to the <resource_location> block.
      (this provides a place to hold the expressions that make up this location rule)

      • Add an <expression/> tag as a child to the <rule> block.
        (this tells the CRM exactly where you want the resource group to run)

  • For each resource:
    • Add a <resource> child block to the <group> block:
      (this tells the CRM that this <resource> is part of this <group>)

    • Add a child <attributes> tag to the <resource> block.

      • (this provides a place to hold all the parameters to the resource group)

      • For each parameter you want to pass to this particular resource agent:
        • Add an <nvpair/> child tag to the <attributes> block.
          (this tells what parameter you want to pass to the resource agent)

<rsc_location> XML blocks looks like this:

<rsc_location id="loc_group_N" rsc="group_N">
  <rule id="pref_loc_group_N" score="100">
    <--! Change __hostname__ to the host you want this resource on -->
    <expression id="pref_loc_group_N_expr" attribute="#uname" operation="eq" value="__hostname__"/>
  </rule>
</rsc_location>

<rule> XML blocks look like this:

<rule id="pref_run_ip_resource" score="100">
  <!-- expression tags go here --> 
</rule>

<expression> XML tags look like this:

     <!-- Replace __hostname__ with the hostname you want this group to run on -->
      <expression id="pref_loc_group_N_expr" attribute="#uname" operation="eq" value="__hostname__"/>

<resource> XML blocks look like this.

<--! Change __resource_type__ to the heartbeat resource script name -->
<primitive id="group_N_rsc_M" class="heartbeat" type="__resource_type__">
  <instance_attributes>
    <attributes>
    </attributes>
  </instance_attributes>
</primitive>

<nvpair/> tags look like this:

<!-- "N" values are consecutive integers starting from 1 -->
<!-- __parameter_value__ is the value you want argument "N" to have -->
<nvpair name="N" value="__parameter_value__"/>

The net effect is like this:

<cib>
  <configuration>
    <resources>
      <group id="group_N">
         <!-- Change __resource_type__ to the heartbeat resource script name
                 for this particular /etc/ha.d/resource.d resource
          -->
        <primitive id="group_N_rsc_M" class="heartbeat" type="__resource_type__">
          <instance_attributes>
            <attributes>
             <!-- "N" values count up consecutively starting from 1.
               __parameter_value__ is the value you want argument "N" to
               resource agent "__resource_type" to have.
               Leave the <nvpair>s out if there are no parameters.
               OCF resource agents are similar.
              -->
              <nvpair name="N" value="__parameter_value__"/>
            </attributes>
          </instance_attributes>
        </primitive>
      </group>
    </resources>
    <constraints>
      <rsc_location id="run_group_N" rsc="group_N">
        <rule id="pref_run_group_N" score="100">
          <!-- Change __hostname__ to the host you want this resource on -->
          <expression attribute="#uname" operation="eq" value="__hostname__"/>
        </rule>
      </rsc_location>
    <constraints>
  </configuration>
</cib>

Extra features

Groups may be named by appending #groupname to the end of the haresources line:

{node} {resource_1} {resource_2} ... #{groupname}

Individual resources still get autogenerated names.

Basic clones configuration:

anywhere {resource_1} {resource_2} ... #clone:{clonename}

Stonith clones are generated from the ha.cf stonith_host lines.

In addition to the autogenerated constraints, it is possible to create additional constraints:

#rsc_order {resource_from} {action} {before|after} {resource_to}
#rsc_colocation {resource_1} {resource_2} {score}

Generated order constraints are symmetrical.

Conversion Examples