Re: Cluster.conf

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

 



Not sure if thanks does it but this is very helpful and will now be part of my 
own documentation. Thank you! 

Mike

>> 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. 

> 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

[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux