[Pacemaker] Proposed new stonith topology syntax
Digimer
linux at alteeve.com
Tue Jan 3 13:28:26 UTC 2012
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: digimer at 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
More information about the Pacemaker
mailing list