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
