[Linux-cluster] Can I use cman instead of the HA (High Availability) package?

[Lon Hohberger]

On Wed, 2005-06-08 at 15:39 -0400, Coman Iliut wrote:
> Is there any documentation you can point me to, for rgmanager?
> 
> I installed the rpm but there anre no man pages.

Doxygen!

(just kidding)

Not really, there's a UI you can use to configure it (system-config-
cluster), or you can refer to the examples/*.conf and
src/daemons/tests/*.conf.

I'm still working on a decent "HOWTO" for people who wish to hand-
edit...  I'm about 2% done, but here it is anyway... ;)

-- Lon

-------------- next part --------------
rgmanager HOWTO, v0.0.1

How Resources Work

Resource Agents, Meta-Data, and an overview

Resource information is provided to rgmanager via the "meta-data"
command-line option.  This option tells the user (or program, in this
case) what the various parameters are for a given resource type.  For
example, the output of the "ip.sh" looks something like the following
(the description tags have been removed to make this shorter):

<?xml version="1.0" ?>
<resource-agent version="rgmanager 2.0" name="ip">
    <version>1.0</version>
    <parameters>
        <parameter name="address" unique="1" primary="1"/>
        <parameter name="family"/>
        <parameter name="monitor_link">
            <content type="boolean" default="1"/>
        </parameter>
    </parameters>

    <actions>
        <action name="start" timeout="20"/>
        <action name="stop" timeout="20"/>
        <action name="status" interval="20" timeout="10"/>
        <action name="monitor" interval="20" timeout="10"/>
        <action name="status" depth="10" interval="60" timeout="20"/>
        <action name="monitor" depth="10" interval="60" timeout="20"/>
        <action name="status" depth="20" interval="2m" timeout="20"/>
        <action name="monitor" depth="20" interval="2m" timeout="20"/>
        <action name="meta-data" timeout="20"/>
        <action name="verify-all" timeout="20"/>
    </actions>

    <special tag="rgmanager">
        <attributes maxinstances="1"/>
    </special>
</resource-agent>

For each <parameter> block, rgmanager will call the script with an
OCF_RESKEY_param environment variable the parameter exists.  We'll get
back to that later.

This is closely related to the OCF RA API 1.0, but there are a few
differences of note: we allow "primary", "required", and "unique"
attributes.  "Primary" parameters and "unique" parameters can not be
shared between any two resources of the same type in
/etc/cluster/cluster.conf, and a resource must have all "required"
parameters.  "Primary" means that it is unique, required, and can be
passed by reference in the resource tree, for instance:

<rm>
    <resources>
        <ip address="192.168.1.2" monitor_link="1"/>
    </resources>
    <service name="foo">
        <ip ref="192.168.1.2"/>
    </service>
</rm>

Note, however, the <attributes maxinstances="1"> in the <special> tag. 
This means that the IP address may only appear once in the entire
service tree; it may not be reused.  A subsequent reference to
192.168.1.2 will be completely ignored by rgmanager.  If there is no
"maxinstances" tag in the resource agent meta-data, there is no limit on
the maximum number of times the resource may be referenced.

Remember when I mentioned that parameters are passed as environment
variables to the resource scripts?  In normal terms, here's how
rgmanager starts an IP address given the above parameters:

	OCF_RESKEY_address="192.168.1.2" \
	OCF_RESKEY_monitor_link="1" \
		/usr/share/cluster/ip.sh start


Global vs. Inline Resources and the Resource Dependency Tree

Resources declared "inline" (or "private resources"), however, may
*NEVER* be reused.  A resource is "global" if it is declared in the
<resources> block.  A resource is "inline" if it is only assigned
attributes in the context of a service.  In our previous example,
192.168.1.2 was a global resource.  In the following example,
192.168.1.2 is an inline (or private) resource:

<rm>
    <resources/>
    <service name="foo">
        <ip address="192.168.1.2" monitor_link="1"/>
    </service>
</rm>

As stated previously, the "primary" attribute for a resource must be
unique across resource types.  So, the following is illegal (the second
instance of 192.168.1.2 will be ignored):

<rm>
    <resources/>
    <service name="foo">
        <ip address="192.168.1.2" monitor_link="1"/>
    </service>
    <service name="bar">
        <ip address="192.168.1.2" monitor_link="1"/>
    </service>
</rm>

Resources may depend on other resources.  What we mean here is that a
user may have a resource "y" depend on resource "x".  The rules are as
follows:

* A resource "y" is dependent on resource "x" if it is a descendent of
resource "y" in the tree.
* Resources must be started before dependent children may start.
* Resources must remain running until all dependent children are
stopped.

Here's a secret to help you remember: <service> is a resource, too.  We
just mask the ability to create it in the <resources> block of
cluster.conf (to eliminate confusion).  So, in order for a service to
be started/healthy, all of its parts must also be started/healthy.