On Wed, 2021-07-28 at 08:51 -0400, john tillman wrote: > > Technically you could give one vote to one node and zero to the > > other. > > If they lose contact only the server with one vote would make > > quorum. > > The downside is that if the server with 1 vote goes down the entire > > cluster comes to a halt. > > > > > > That said, if both nodes can reach the same switch that they are > > connected to each other through, why can't they reach each other? > > > > "... why can't they reach each other?" My question as well. > > It feels like a very low probability thing to me. Some > blockage/filtering/delay of the cluster's "quorum packets" while ping > packets were allowed through, perhaps caused by network > congestion. But > I'm not a network engineer. Any network engineers reading this care > to > comment?
It's not necessarily that they can't reach each other, but that one is unresponsive. A kernel driver temporarily blocking activity, CPU or I/O overload, or losing an essential disk drive (which won't affect networking) can all cause a server to become unresponsive to cluster traffic while still potentially having the ability to cause trouble if resources are recovered elsewhere. Having a separate network interface for fencing device access (ideally on a separate physical card) is a good idea, so the interface is not a single point of failure. Connecting that interface via a dedicated switch, on a different UPS than the main switch, improves it even more. A hardware watchdog is a good way to do fencing without all that trouble. > Thanks for echoing my thoughts and that interesting quorum-weight > idea. > > > > > > On 7/26/21 12:21 PM, john tillman wrote: > > > They would continue running their resources and we would have > > > split > > > brain. > > > > > > So there is no safe way to support a two node cluster 100% of the > > > time. > > > But when all you have are two nodes and a switch ... well, when > > > life > > > gives > > > you lemons ... > > > > _______________________________________________ > > Manage your subscription: > > https://lists.clusterlabs.org/mailman/listinfo/users > > > > ClusterLabs home: https://www.clusterlabs.org/ > > > > > _______________________________________________ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/users > > ClusterLabs home: https://www.clusterlabs.org/ > -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
