cluster.conf - The configuration file for cluster products

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>

ccs(7), ccs_tool(8), lock_gulmd(5), cman(5)