Appendix F: Reviewing Quorum Configuration Options for a Failover Cluster

Applies To: Windows Server 2008

This topic provides an overview of the quorum configuration options for a failover cluster. For more information about how quorum works in a failover cluster, see https://go.microsoft.com/fwlink/?LinkId=125621. For more information about planning for a failover cluster, see Identifying Your Failover Cluster Deployment Goals and Mapping Your Deployment Goals to a Failover Cluster Design.

In a failover cluster running Windows Server 2008, the "quorum" is the number of elements that must be online for that cluster to continue running. In effect, each element can cast one “vote” to determine whether the cluster continues running. The voting elements are nodes or, in some cases, a disk witness or file share witness. Each voting element (with the exception of a file share witness) contains a copy of the cluster configuration, and the Cluster service works to keep all copies synchronized at all times.

It is essential that the cluster stops running if too many failures occur or if there is a problem with communication between the cluster nodes.

Note that the full function of a cluster depends not just on quorum, but on the capacity of each node to support the services and applications that fail over to that node. For example, a cluster that has five nodes could still have quorum after two nodes fail, but each remaining cluster node would continue serving clients only if it had enough capacity to support the services and applications that failed over to it.

This topic provides information about the following:

• Why quorum is necessary

• Overview of the quorum modes

• Choosing the quorum mode for a particular cluster

• Diagrams of quorum modes

Why quorum is necessary

When network problems occur, they can interfere with communication between cluster nodes. A small set of nodes might be able to communicate together across a functioning part of a network, but might not be able to communicate with a different set of nodes in another part of the network. This can cause serious issues. In this “split” situation, at least one of the sets of nodes must stop running as a cluster.

To prevent the issues that are caused by a split in the cluster, the cluster software requires that any set of nodes running as a cluster must use a voting algorithm to determine whether, at a given time, that set has quorum. Because a given cluster has a specific set of nodes and a specific quorum configuration, the cluster will know how many “votes” constitutes a majority (that is, a quorum). If the number drops below the majority, the cluster stops running. Nodes will still listen for the presence of other nodes, in case another node appears again on the network, but the nodes will not begin to function as a cluster until the quorum exists again.

For example, in a five node cluster that is using a node majority, consider what happens if nodes 1, 2, and 3 can communicate with each other but not with nodes 4 and 5. Nodes 1, 2, and 3 constitute a majority, and they continue running as a cluster. Nodes 4 and 5 are a minority and stop running as a cluster, which prevents the problems of a “split” situation. If node 3 loses communication with other nodes, all nodes stop running as a cluster. However, all functioning nodes will continue to listen for communication, so that when the network begins working again, the cluster can form and begin to run.

Overview of the quorum modes

There have been significant improvements to the quorum model in Windows Server 2008. In Windows Server 2003, almost all server clusters used a disk in cluster storage (the “quorum resource”) as the quorum. If a node could communicate with the specified disk, the node could function as a part of a cluster, and otherwise it could not. This made the quorum resource a potential single point of failure. In Windows Server 2008, a majority of ‘votes’ is what determines whether a cluster achieves quorum. Nodes can vote, and where appropriate, either a disk in cluster storage (called a “disk witness”) or a file share (called a “file share witness”) can vote. There is also a quorum mode called No Majority: Disk Only which functions like the disk-based quorum in Windows Server 2003. Aside from that mode, there is no single point of failure with the quorum modes, since what matters is the number of votes, not whether a particular element is available to vote.

This new quorum model is flexible and you can choose the mode best suited to your cluster.

Important

In most situations, it is best to use the quorum mode selected by the cluster software. If you run the quorum configuration wizard, the quorum mode that the wizard lists as “recommended” is the quorum mode chosen by the cluster software. We only recommend changing the quorum configuration if you have determined that the change is appropriate for your cluster.

There are four quorum modes:

• Node Majority: Each node that is available and in communication can vote. The cluster functions only with a majority of the votes, that is, more than half.

• Node and Disk Majority: Each node plus a designated disk in the cluster storage (the “disk witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.

• Node and File Share Majority: Each node plus a designated file share created by the administrator (the “file share witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.

• No Majority: Disk Only: The cluster has quorum if one node is available and in communication with a specific disk in the cluster storage.

Choosing the quorum mode for a particular cluster

The following table describes clusters based on the number of nodes and other cluster characteristics, and lists the quorum mode that is recommended in most cases.

A “multi-site” cluster is a cluster in which an investment has been made to place sets of nodes and storage in physically separate locations, providing a disaster recovery solution.

Description of cluster	Quorum recommendation
Odd number of nodes	Node Majority
Even number of nodes (but not a multi-site cluster)	Node and Disk Majority
Even number of nodes, multi-site cluster	Node and File Share Majority
Even number of nodes, no shared storage	Node and File Share Majority

Diagrams of quorum modes

The following diagrams show how each of the quorum modes affects whether a cluster can or cannot achieve quorum.

Node Majority

The following diagram shows Node Majority used (as recommended) for a cluster with an odd number of nodes.

Node Majority quorum configuration, three nodes

In this mode, each node gets one vote. In certain circumstances, you might want to install a hotfix that lets you select which nodes will have votes. This can be useful with certain multi-site clusters, for example, where you want one site to have more votes than other sites in a disaster recovery situation. For more information, see "Changing the quorum configuration in a failover cluster for unequal node weight" in the Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster.

Node and Disk Majority

The following diagram shows Node and Disk Majority used (as recommended) for a cluster with an even number of nodes. Each node can vote, as can the disk witness.

Node and Disk Majority quorum configuration, four nodes (plus disk)

The following diagram shows how the disk witness also contains a replica of the cluster configuration database in a cluster that uses Node and Disk Majority.

Replicas of cluster configuration in cluster that uses Node and Disk Majority

Node and File Share Majority

The following diagram shows Node and File Share Majority used (as recommended) for a cluster with an even number of nodes and a situation where having a file share witness works better than having a disk witness. Each node can vote, as can the file share witness.

Node and File Share Majority quorum configuration, four nodes (plus file share)

The following diagram shows how the file share witness can vote, but does not contain a replica of the cluster configuration database. Note that the file share witness does contain information about which version of the cluster configuration database is the most recent.

Replicas of cluster configuration in cluster that uses Node and File Share Majority

No Majority: Disk Only

The following illustration shows how a cluster that uses the disk as the only determiner of quorum can run even if only one node is available and in communication with the quorum disk. It also shows how the cluster cannot run if the quorum disk is not available (single point of failure). For this cluster, which has an odd number of nodes, Node Majority is the recommended quorum mode.

No Majority: Disk Only quorum configuration, three nodes