peshkova - Fotolia

Manage Learn to apply best practices and optimize your operations.

Failover cluster quorum considerations for Windows admins

Microsoft introduced Cloud Witness in Windows Server 2016, which adds a new wrinkle to its quorum model for failover clusters, but it might not be a good fit for some enterprises.

Windows Server's failover clustering keeps the business running smoothly, unless the failover cluster quorum does not line up with the organization's framework.

Most companies can't abide downtime with their business applications. A properly configured failover cluster keeps these vital services running if server hardware breaks. Administrators need to weigh all the failover cluster quorum models before they push a cluster into production to avoid data loss or service disruptions.

Microsoft introduced a new quorum model in Windows Server 2016 that enlists the cloud to add a layer of reliability.

How the failover cluster quorum model works

Windows failover clustering uses a quorum to select a node that manages the cluster. A cluster needs more than half of its nodes online to avoid overloading the remaining nodes when a failover occurs.

In some circumstances, the administrator will select a quorum witness to keep a cluster active even if a planned event or hardware failure leaves less than half of the servers in the cluster running. A failover cluster keeps a copy of the cluster configuration in the quorum location, such as a file share, a disk or a cluster node.

Quorum model
The failover cluster configuration wizard offers different options for the quorum witness.

Consider the available failover cluster quorum models

During the Windows failover cluster setup, a wizard prompts the user for a quorum model and suggests a model based on the number of nodes in the cluster. Here is an explanation of each quorum model and when to use each one.

No majority, disk witness only. With this model, the cluster continues to run if all the cluster nodes fail except for one, and if the disk that holds that quorum configuration is online. Because the disk represents a single point of failure, production teams should carefully consider if this is the right quorum model for them, unless the disk is on a SAN device.

How to set up high availability in
Windows Server 2016

Node and file share majority. In this setup, the cluster stores its configuration on a file share that is visible to all the cluster nodes. If a failure occurs, the cluster looks for the node that owns the file share with the cluster configuration. Use this model for clusters that span multiple sites with an even number of nodes. In this scenario, the file share gets a vote.

The Cloud Witness quorum model requires that all cluster nodes can reach the Azure container that hosts the cluster configuration

Node and disk majority. In this quorum model, all cluster nodes and the disk that holds the cluster configuration have a vote. This model suits organizations with a cluster that runs in one location with an even number of nodes. For example, if there are five nodes in the cluster and three go down, the cluster will stay active if the disk that holds the cluster configuration remains online. The cluster configuration wizard generally recommends this quorum model.

Node majority. Microsoft recommends this model for Windows failover clusters with an odd number of nodes at a single site. In this arrangement, a cluster can sustain the failure of two nodes if the cluster contains five nodes, or the loss of one node if the cluster contains three nodes. The advantage of this model is it doesn't keep the cluster configuration copy on a central disk or file share.

The following table breaks down the quorum models in Windows Server 2016 and recommendations based on each cluster's characteristics.

Quorum model


When cluster is active

When to choose this model

Node majority

Only nodes can participate in the cluster voting.

If more than half of the nodes are available.

If the cluster contains an odd number of nodes.

Node and disk majority

Cluster nodes and the disk participate in the cluster voting.

If more than half of the nodes are available.

If the cluster contains an even number of nodes.

Node and file share majority

The cluster nodes and file share participate in the clustering voting process.

If more than half of the nodes are available.

If the cluster contains an even number of nodes. This is typically used when a cluster spans multiple sites.

Disk only

Only the disk participates in the voting process.

Only if the disk is online.

If the cluster contains an even number of nodes without shared storage.

Windows Server 2016 debuts Cloud Witness

Windows Server 2016 introduced a new failover cluster quorum model for Windows failover clusters called Cloud Witness. This model stores the cluster configuration in an Azure storage blob container that acts as the cluster witness.

The Cloud Witness quorum model requires that all cluster nodes can reach the Azure container that hosts the cluster configuration. This model might not work for enterprises with security policies that prevent a production cluster that holds business applications from connecting to the internet.

However, if the failover cluster resides in Azure, it makes sense to use Cloud Witness. This quorum model eases the workload of the IT staff because the Azure infrastructure takes the place of an on-premises device.

There are different requirements and resources available for every organization. It can require some deep investigative work to determine the right quorum configuration.

Dig Deeper on Windows Server Clustering

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What are some tips that are worth sharing with other administrators regarding the set up and maintenance of failover clusters in Windows Server?
Hi All,
In Windows 2003, a standard quorum will use a quorum log file located on a disk hosted on shared storage, accessible by all members of
the cluster
In Windows 2003, esp in MNS, each node will have its own copy of the quorum database.
My understanding is that In  Windows 2003, quorum log in standard quorum is same as Quorum database on each node in MNS.
Where is the quroum database located in Windows 2008/ R2/ Windows 2012?
Does it store locally on each node along with Diskwitness & Fileshare ( incase if we configure it ?
Where does it save all the quorum configiuraions esp when we select options like Node Majority/ Node Majority with Disk/File?
How does all the nodes will have access to the quorum database incase if we are not using shared storage ?
I been trying to understand all these conecpts , any help is appreciated.