Understanding quorum in Windows Server 2008 clustering

All those in favor, signify by saying "aye."

If you've ever wondered about quorum and the quorum drive in Windows Clustering, think for a minute about what probably happens every week at your local Kiwanis meeting.

The rules of parliamentary procedure require that a predefined minimum number of people are present at any meeting for voting decisions to be made. Typically that minimum number is 50% plus one –- or a majority –- of the total members in the club. Without that minimum number of people in attendance, the group cannot make important voting decisions.

Ensuring a quorum in a Kiwanis meeting makes a lot of sense. Unless a sizeable enough group of members are present, it's too easy for a small group of people to make decisions that affect the club as a whole. The very same concept holds true with clustering in Microsoft Windows.

Windows clusters are designed to ensure high availability of critical network services. Services hosted atop a cluster, as we talked about in my last article on failover clustering, enjoy a set of benefits that tends to increase their uptime during certain events, such as hardware outages, software problems or patching. But since a cluster involves more than one computer system, there must be a sense of "agreement" by all of the systems involved if the cluster is to operate.

Since a cluster involves more than one computer system, there must be a sense of "agreement" by all of the systems involved if the cluster is to operate.

Your cluster's quorum drive is one of the resources with a vote in determining whether the cluster agrees that it is, indeed, a cluster. If there are not enough votes being cast within your Windows cluster, then the components that make up that cluster cannot recognize that they're actually part of a fully-functioning cluster. The result is that the entire cluster and all its hosted resources are forced to shut down. You can read more detailed information about how this process works in this Microsoft TechNet.

Like with the Kiwanis, there are multiple ways in which this quorum can be measured using Windows Server 2008. One club member can simply count the number of people present, or members can raise hands as a test vote. With the large number of people making up the United States legislature, quorum there is determined by each member punching a button to vote "present."

Clustering in Windows Server 2008 adds an architectural improvement over previous versions of Windows in that its quorum can be determined through multiple ways, with the mechanism of that count defined by the administrator. Which mechanism you use will depend on how you set up your server cluster, what you want to do with it and how many nodes there are.

Let's take a look at the four ways of determining quorum in Windows Server 2008:

• Node Majority-- With the Node Majority model, each of the nodes that make up the server cluster gets a vote that counts toward quorum. The quorum disk itself does not have a vote. The cluster will function when more than half of the nodes in the cluster are operational, which means this model is used only when there are an odd number of nodes in the cluster. Remember that although the Node Majority model doesn't give its disk a vote, that disk is still a requirement for cluster operations.
• Node and Disk Majority -- The vast majority of Windows clusters are two-node clusters. This has traditionally been the case because of the complexities of creating multi-node clusters as well as their cost. Two-node clusters cannot be created using the Node Majority mode -- as they have an even node count -- so in this alternate architecture, the disk resource itself also gets a vote. Used for server clusters that have an even number of nodes, the Node and Disk Majority requires more than half of the nodes plus the quorum drive itself to be operational for quorum to be achieved.
• Node and File Share Majority -- Windows Server 2008 now includes support for geographically distributed clusters, those that are not bound by the length of the physical cables separating the nodes. Among other things, this support comes about with the conversion of cluster heartbeat communications from broadcast traffic to TCP-based traffic, which allows that portion of cluster communication to span subnets.

However, to create such a geo-cluster, both nodes can no longer functionally share the same storage. Thus, a special type of quorum drive was created that resides on a file share that is accessible by both nodes. This special cluster type also works for workloads that do not require shared storage, such as Exchange CCR clusters and some limited Hyper-V clustering arrangements.

• No Majority: Disk Only -- This last quorum model relies only on the availability of the shared disk itself for determining quorum. It is effectively the same as what's used in older versions of Windows clustering. Because of its single point of failure reliance on the disk's presence, this model is rarely recommended for use in production environments.

The model you base your server cluster upon is usually set during your initial installation and configuration. In some cases, however, it is possible to change quorum models down the road. This may happen if you later change the number of nodes in the cluster or the desired workloads it supports. You can do this by right-clicking the cluster name in the Failover Cluster Management console and selecting More Actions → Configure Cluster Quorum Settings. As with any major midstream configuration shift, you'll want to test the change prior to its implementation.