When a cluster has an even number of members, a witness resource is a server, network endpoint, or other device that is used to establish and maintain quorum. When employing cluster majority, a cluster with an odd number of members can arbitrate majority membership using all of the cluster server’s members instead of a witness resource.
A resource (device, system, block storage, file storage, file share, etc.) that is used to arbitrate the cluster status and membership is known as a quorum resource. Quorum is a cluster resource that some cluster managers use or demand in order to make decisions about the cluster’s membership and condition. Quorum serves as a tie-breaker in other cluster managers to prevent split-brain.
The right deployment of quorum/witness resources is crucial for HA systems given the important role of quorum; thankfully (or sadly), there is no one, ideal approach to deploy quorum. Your witness and quorum resources’ behavior may be influenced by a number of variables. These elements consist of:
Customers will have more alternatives for quorum and witness capabilities by deploying in an on-premises datacenter with extra storage devices, such as fiber channel storage, power control devices or connections, or conventional stonith devices, which may not be present in the cloud. The deployment options and use cases that quorum can be used to prevent differ in cloud and hybrid systems.
Furthermore, the kinds of devices and resources that can be used in a quorum/witness setup may be constrained by latency specifications and variations. When planning and architecting your quorum and witness resources, it’s crucial to keep recovery objectives in mind. What is the highest priority for recovery when node A loses connectivity to node B in an example two-node cluster (node A and node B)? Node A may stay up but be cut off from clients if the witness/quorum resources are in the same network, leaving node B unable to determine quorum and takeover.
