[ClusterLabs] Antw: [EXT] Stonith failing

Andrei Borzenkov arvidjaar at gmail.com
Mon Aug 17 03:19:33 EDT 2020

17.08.2020 10:06, Klaus Wenninger пишет:
>>> Alternatively, you can set up corosync-qdevice, using a separate system
>>> running qnetd server as a quorum arbitrator.
>> Any solution that is based on node suicide is prone to complete cluster
>> loss. In particular, in two node cluster with qdevice surviving node
>> will commit suicide is qnetd is not accessible.
> I don't think that what Reid suggested was going for nodes
> that loose quorum to commit suicide right away.
> You can use quorum simply as a means of preventing fence-races
> otherwise inherent to 2-node-clusters.

Can you please show the configuration example how to do it? Sorry, but I
do not understand how is it possible.

>> As long as external stonith is reasonably reliable it is much preferred
>> to any solution based on quorum (unless you have very specific
>> requirements and can tolerate running remaining nodes in "frozen" mode
>> to limit unavailability).
> Well we can name the predominant scenario why one might not want to depend
> on fencing-devices like ipmi: If you want to cover a scenario where the
> nodes don't
> just loose corosync connectivity but as well access from one node to the
> fencing
> device of the other is interrupted you probably won't get around an
> approach that
> involves some kind of arbitrator.

Sure. Which is why I said "reasonably reliable". Still even in this case
one must understand all pros and cons to decide which risk is more
important to mitigate.

More information about the Users mailing list