[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] Cluster.conf



isplist 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 redhat com
https://www.redhat.com/mailman/listinfo/linux-cluster



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]