On 01/03/2012 01:19 AM, Andrew Beekhof wrote: > Does anyone have an opinion on the following schema and example? > I'm not a huge fan of the index field, but nor am I of making it > sensitive to order (like groups). > > Please keep in mind that the new topology section is optional and > would only be defined if: > - you wanted to specify the order in which multiple devices were tried, or > - if multiple devices need to be triggered for the node to be > considered fenced. > > Most people will /NOT/ need to add this section to their configuration.
A common configuration (at least in my world) is to use IPMI/iLO/etc + switched PDU for fencing. When ever possible, the IPMI fencing should be primary device, because it has the ability to confirm a node's "off" state making it more trustworthy than fencing via PDU. When a PDU is needed though (ie: node lost it's PSU so the BMC is down), with redundant power supplies, two separate PDUs need to both successfully cut power to consider the fence complete. I mention this to show that ordered and multiple device fencing isn't that unusual. :) > -- Andrew > > <fencing-topology> > <!-- pcmk-0 requires the devices named disk + network to complete --> > <fencing-rule id="f-p0" node="pcmk-0"> > <device id-ref="disk"/> > <device id-ref="network"/> > </fencing-rule> > > <!-- pcmk-1 needs either the poison-pill or power device to complete > successfully --> > <fencing-rule id="f-p1.1" node="pcmk-1" index="1" device="poison-pill"/> > <fencing-rule id="f-p1.2" node="pcmk-1" index="2" device="power"> > > <!-- pcmk-1 needs either the disk and network devices to complete > successfully OR the device named power --> > <fencing-rule id="f-p2.1" node="pcmk-2" index="1"> > <device id-ref="disk"/> > <device id-ref="network"/> > </fencing-rule> > <fencing-rule id="f-p2.2" node="pcmk-2" index="2" device="power"/> > > </fencing-topology> > > Conforming to: > > <define name="element-stonith"> > <element name="fencing-topology"> > <zeroOrMore> > <ref name="element-fencing"/> > </zeroOrMore> > </element> > </define> > > <define name="element-fencing"> > <element name="fencing-rule"> > <attribute name="id"><data type="ID"/></attribute> > <attribute name="node"><text/></attribute> > <attribute name="index"><text/></attribute> > <choice> > <attribute name="device"><text/></attribute> > <zeroOrMore> > <element name="device"> > <attribute name="id-ref"><data type="IDREF"/></attribute> > </element> > </zeroOrMore> > </choice> > </element> > </define> > > </grammar> I wish I was more familiar with pacemaker to make an intelligent comment. However, this looks good to me. I don't see an example of a multi-port fence device, but I am assuming that's abstracted away for the simplicity of the example? Cheers! -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
