[Linux-cluster] Cluster.conf

[James Parsons]

isplist at logicore.net wrote:

>>>>http://sources.redhat.com/cluster/doc/cluster_schema.html
>>>>        
>>>>
>
>I've been looking at this and searching the net high and low and just can't 
>seem to find enough information to build a proper cluster.conf file. I'm 
>almost sure that it is the cause of some of the problems I am still suffering 
>months into this cluster learning.
>
>For example, I've seen all sorts of uses for "method name" but have not found 
>ONE single document showing/explaining all of the possible choices or why on 
>each one.
>
>That goes for MANY other areas of this file. Is there not any documentation 
>for building this file other than the above? It's just not enough for me at 
>least.
>
>Mike
>
>  
>
Man cluster.conf.

The method tag block denotes a fence group level. The only attribute 
that can be specified for a method tag block is a name attr. This just 
needs to be distinctive from all other method block names below a 
specific clusternode fence block. The name can be any string - it just 
does not matter. system-config-cluster generates unique interger values 
for each method block and converts them to strings in order to set 
method name attributes.

A method block allows you to group one or more fence types at a specific 
level of fencing; for example, if you  wish to employ power fencing as a 
first measure for a node, you would insert an initial method block 
within a clusternode's fence block, referencing power fence devices with 
instance specific attributes such as port numbers. Let's say that 
clusternode 'A' has dual power supplies...this is what the xml would 
look like:

<clusternode name="A">
  <fence>
    <method name="1">
      <device name="my_apc" port="1" option="off"/>
      <device name="my_apc" port="2" option="off"/>
      <device name="my_apc" port="1" option="on"/>
      <device name="my_apc" port="2" option="on"/>
    </method>
  </fence>
</clusternode>

While the defauly action for every fence agent is to reboot, the 
'option' atr is used above in the case of dual power supply nodes to 
insure both power supplies are off at the same time - making certain 
that the node is fenced.

Now, let's say that you are paranoid, and that you do not trust your 
power switch 100%. You can add a second level of fencing (as additional 
insurance) like so:

<clusternode name="A">
  <fence>
    <method name="1">
      <device name="my_apc" port="1" option="off"/>
      <device name="my_apc" port="2" option="off"/>
      <device name="my_apc" port="1" option="on"/>
      <device name="my_apc" port="2" option="on"/>
    </method>
    <method name="2">
      <device name="my_brocade" port="12"/>
    </method>
  </fence>
</clusternode>

The above sets up a primary fence method in he first method block. If 
that block fails to fence the node, then the next block will be 
attempted.  There is no limit that I know of for how many method blocks 
you wish to employ -- but 1 or 2 is the norm...anymore tends to suggest 
paranoid tendencies ;-)

As additional information on this subject, the following is from the 
schema doc that is mentioned above:


        A Note On Fencing


Fencing is specified within the cluster.conf file in two places. The first
place is within the <fencedevices> tag. Any device used for fencing a node
must be defined here as a <fencedevice> first. This applies to power
switches (APC, WTI, etc.) with multiple ports that are able to fence multiple
cluster nodes, as well as fabric switches and baseboard management fence
strategies (iLO, RSA, IPMI, Drac, etc.) that are usually 1 to 1 in nature; 
that is, one specified fence device is able to fence only one node.

After defining the fence devices to be used in the cluster, it is necessary to
associate the fence device listings with specific cluster nodes. The second 
place that fencing is specified within cluster.conf is within the <clusternode>
tag. Beneath the <clusternode> tag, is a <fence> tag. Beneath the <fence> tag is
one or more <method> tag sets. Within a <method> tag set, is a <device> tag set.
This is where the actual association between <fencedevice> and node takes place.
A <device> tag has a required "name" attribute that refers to the name of one
of the <fencedevice>'s specified in the <fencedevices> section of cluster.conf. 

More about <method> blocks: A method block is like a fence level. If a 
primary fence method is selected, yet the user wants to define a backup method
in case the first fence method fails, this is done by defining two <method>
blocks for a cluster node, each with a unique name parameter. The fence daemon
will call each fence method in the order they are specified under the
<clusternode><fence> tag set.

Fence specification within cluster.conf offers one other feature for 
customizing fence action. Within a <method> block, it is allowable to list 
more than one <device>. This is useful when fencing a node with redundant
power supplies, for example. The fence daemon will run the agent for each
device listed within a <method> block before determining success or failure.

I hope this sets you up with all that you need.

-J

>
>--
>Linux-cluster mailing list
>Linux-cluster at redhat.com
>https://www.redhat.com/mailman/listinfo/linux-cluster
>  
>