Provided by:
ccs_1.20060222-0ubuntu5_i386 
NAME
cluster.conf - The configuration file for cluster products
DESCRIPTION
The cluster.conf file is located in the /etc/cluster directory. It is
the source of information used by the cluster products - accessed
indirectly through CCS (see ccs(7)). This file contains all the
information needed for the cluster to operate, such as: what nodes
compose the cluster and how to I/O fence those nodes. There is generic
information which is applicable to all cluster infrastructures, as well
as specific information relevent for specific cluster products.
This man page describes the generic contents of the cluster.conf file.
The product specific sections of cluster.conf are left to their
respective man pages. For example, after constructing the generic
content, a user would look at the lock_gulmd(5) man page for specific
instructions if using lock_gulmd as their lock server. Conversely, a
user employing cman and the dlm would look at cman(5) and dlm(5) for
further instruction.
The cluster.conf file is an XML file. It has one encompasing section
in which everything is contained. That entity’s name is cluster and it
has two manditory attributes: name and config_version. The name
attribute specifies the name of the cluster. It is important that this
name is unique from other clusters the user might set up. The
config_version attribute is a number used to identify the revision
level of the cluster.conf file. Given this information, your
cluster.conf file might look something like:
<cluster name="alpha" config_version="1">
</cluster>
A manditory subsection of cluster is fencedevices. It contains all of
the I/O fencing devices at the disposal of the cluster. The I/O
fencing devices are listed as entities designated as fencedevice and
have attributes that describe the particular fencing device. For
example:
<fencedevices>
<fencedevice name="apc" agent="fence_apc"
ipaddr="apc_1" login="apc" passwd="apc"/>
</fencedevices>
Concerning the fencedevice entity, the name and agent attributes must
be specified for all I/O fence devices. The remaining attributes are
device specific and are used to specify the neccessary information to
access the device. The name attribute must be unique and is used to
reference the I/O fence device in other sections of the cluster.conf
file. The agent attribute is used to specify the binary fence agent
program used to communicate with the particular device. Your
cluster.conf file might now look something like:
<cluster name="alpha" config_version="1">
<fencedevices>
<fencedevice name="apc" agent="fence_apc"
ipaddr="apc_1" login="apc" passwd="apc"/>
<fencedevice name="brocade" agent="fence_brocade"
ipaddr="brocade_1" login="bro" passwd="bro"/>
<!-- The WTI fence device requires no login name -->
<fencedevice name="wti" agent="fence_wti"
ipaddr="wti_1" passwd="wti"/>
<fencedevice name="last_resort" agent="fence_manual"/>
</fencedevices> </cluster>
The final manditory subsection of cluster is clusternodes. It contains
the individual specification of all the machines (members) in the
cluster. Each machine has it’s own section, clusternode, which has the
name attribute - this should be the name of the machine. The
clusternode section also contains the fence section. Not to be
confused with fencedevices the fence section is used to specify all the
possible "methods" for fencing a particular machine, as well as the
device used to perform that method and the machine specific parameters
neccessary. By example, the clusternodes section may look as follows:
<!-- This example only contains one machine -->
<clusternodes>
<clusternode name="nd01">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
<device name="apc" port="1:1"/>
</method>
<!-- If the "power" method fails,
try fencing through the "fabric" -->
<method name="fabric">
<device name="brocade" port="1"/>
</method> <!-- If all else fails,
make someone do it manually -->
<method name="human">
<device name="last_resort" ipaddr="nd01"/>
</method>
</fence>
</clusternode>
</clusternodes>
Putting it all together, a three node cluster’s cluster.conf file might
look like:
<cluster name="example" config_version="1">
<clusternodes>
<clusternode name="nd01">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
<device name="apc" port="1:1"/>
</method>
<!-- If the "power" method fails,
try fencing through the "fabric" -->
<method name="fabric">
<device name="brocade" port="1"/>
</method> <!-- If all else fails,
make someone do it manually -->
<method name="human">
<device name="last_resort" ipaddr="nd01"/>
</method>
</fence>
</clusternode>
<clusternode name="nd02">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
<device name="apc" port="1:2"/>
</method>
<!-- If the "power" method fails,
try fencing through the "fabric" -->
<method name="fabric">
<device name="brocade" port="2"/>
</method> <!-- If all else fails,
make someone do it manually -->
<method name="human">
<device name="last_resort" ipaddr="nd02"/>
</method>
</fence>
</clusternode>
<clusternode name="nd11">
<fence>
<!-- "power" method is tried before all others -->
<method name="power">
<!-- This machine has 2 power supplies -->
<device name="apc" port="2:1"/>
<device name="wti" port="1"/>
</method>
<!-- If the "power" method fails,
try fencing through the "fabric" -->
<method name="fabric">
<device name="brocade" port="11"/>
</method> <!-- If all else fails,
make someone do it manually -->
<method name="human">
<device name="last_resort" ipaddr="nd11"/>
</method>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
<fencedevice name="apc" agent="fence_apc"
ipaddr="apc_1" login="apc" passwd="apc"/>
<fencedevice name="brocade" agent="fence_brocade"
ipaddr="brocade_1" login="bro" passwd="bro"/>
<!-- The WTI fence device requires no login name -->
<fencedevice name="wti" agent="fence_wti"
ipaddr="wti_1" passwd="wti"/>
<fencedevice name="last_resort" agent="fence_manual"/>
</fencedevices> </cluster>
SEE ALSO
ccs(7), ccs_tool(8), lock_gulmd(5), cman(5)
cluster.conf(5)