Hi, On Wed, Jan 18, 2012 at 10:08:28AM -0500, Digimer wrote: > On 01/18/2012 08:15 AM, Dejan Muhamedagic wrote: > >>> Is there a possibility to express > >>> fencing nodes simultaneously? > >> > >> No. Its regular boolean shortcut semantics. > > > > As digimer mentioned, it is one common use case, i.e. for hosts > > with multiple power supplies. So far, we recommended lights-out > > devices for such hardware configurations and if those are > > monitored and more or less reliable such a setup should be fine. > > It would still be good to have a way to express it if some day > > somebody actually implements it. I guess that the schema can be > > easily extended by adding a "simultaneous" attribute to the > > "fencing-rule" element. > > If I may restate; > > Out of band management devices (iLO, IPMI, w/e) have two fatal flaws > which make them unreliable as sole fence devices; They share their power > with the host and they (generally) have only one network link. If the > node's PSU fails, or if the network link/BMC fails, fencing fails.
I thought we were talking about computers with two PSU. If both fail, that's already two faults and (our) clusters don't protect from multiple faults. As for the rest (network connection, etc) it's not shared with the host and if there's a failure in any of these components it should be detected by the next monitor operation on the stonith resource giving enough time to repair. In short, a fencing device is not a SPOF. > A PDU as a backup protects against this, but is not ideal as it can't > confirm a node's power state. Why is that? If you ask PDU to disconnect power to the host and that command succeeds how high is the probability that the CPU is still running? Or am I missing something? > This is why I strongly recommend for > people to use ordered fencing; out-of-band management should always be > tried first because if it works, you know for certain the node is dead. > The PDU must be available as a backup, but only be used as such. > > This is why I argue so strongly for ordered fencing. > > >>> I'd rather use "stonith-resource" than "device", because what is > >>> referenced is a stonith resource (one device may be used in more > >>> than one stonith resource). > >> > >> Can you rephrase that? I don't follow. Are you talking about a group > >> of fencing devices? > > > > No, just about naming. The element/attribute name "device" > > doesn't seem right to me, because it references a stonith > > resource. One (physical) device may be used by more than one > > stonith resource. Even though "device" certainly sounds nicer, > > it isn't precise. What I'm worried about is that it may be > > confusing (and we have enough confusion with stonith). > > (Or did I completely misunderstand the meaning of "device"?) > > > > Thanks, > > > > Dejan > > Red Hat clusters call these "Fence Methods", with each "method" > containing one or more fence "devices". With the IPMI, there is only one > device. With Redundant PSUs across two PDUs, you have two devices in the > "method". All devices in a method must succeed for the fence method to > succeed. > > It would, if nothing else, help people migrating to pacemaker from rhcs > if similar names were used. Pacemaker is already using terminology different from RHCS. I'm not at all against using similar (or same) names, but it's too late for that. Introducing RHCS specific names to co-exist with Pacemaker names... well, how is that going to help? Thanks, Dejan > <fence> > <method name="ipmi"> > <device name="ipmi_an01" action="reboot" /> > </method> > <method name="pdu"> > <device name="pdu1" port="1" action="reboot" /> > <device name="pdu2" port="1" action="reboot" /> > </method> > </fence> > > -- > 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 _______________________________________________ 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
