[ClusterLabs] Antw: [EXT] Stonith failing

[Andrei Borzenkov]

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.