Provided by: ccs_1.20060222-0ubuntu5_i386 bug

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)