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. _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
