isplist@xxxxxxxxxxxx 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
