[Pacemaker] Proposed new stonith topology syntax

[Andrew Beekhof]

On Wed, Jan 4, 2012 at 12:28 AM, Digimer <linux at alteeve.com> wrote:
> 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. :)

What you describe is already quite complex relative to "but I don't
/any/ fencing" :-)

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

Right, the devices are defined elsewhere and do support multi-port switches.
This section defines how those devices are used in combination with each other.

(Similar to how resources are defined together and then the
constraints describe how they relate to each other).

> 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