Windows Server 2012 R2 failover clustering: Understanding quorum improvements

Windows Server 2012 R2 includes some impressive improvements to failover clustering

Since the October 2013 release of Windows Server 2012 R2, much has been said about the array of upgrades to the new cloud-aligned server operating system. Much of the focus has been on improvements to virtualization, PowerShell and group policy.

However, in my opinion improvements to failover clustering have been the most impressive. Upgrades to installation and configuration functionality, make the maintenance of failover clusters in Windows Server 2012 R2 an altogether better experience for IT professionals.

Dynamic Witness

The launch of Windows Server 2012 R2 has brought a complete overhaul of the cluster quorum process. In the past choosing which quorum model to use when creating a cluster was a complex decision that required careful consideration. Depending on the number of nodes in your cluster (an even number or an odd number) you had a veritable plethora of quorum models to choose from including Node Majority, Node and Disk Majority or Node and File Share Majority amongst others.

Now, that choice has been made much simpler: you need only decide whether to use a Disk Witness or a File Share Witness? Unlike previous versions of Windows Server, using a Witness for our failover clusters is now recommended. Gone are the days when a failed Disk Witness could bring down a cluster.

With Windows Server 2012 R2, we simply add a Witness when we create our cluster, which then decides whether it is necessary to use the Witness or not. Therefore, if we have two members in our cluster (or any even number) the File Share or Disk Witness will be given a vote to maintain an odd number of votes, a requirement if we are to maintain a cluster.

If we were then to add a third member to our cluster (or any odd number) the Witness' vote is removed, as it is no longer needed.

Tie Break for 50% Node Split

Let’s look at a more complex example with a cluster that has four members, each having a vote along with a Witness that also has a vote.

If the Witness goes offline then one of the cluster members will be chosen and their vote will be removed. This leaves us with a cluster that has three votes’, and we attain the odd number of votes necessary to maintain our cluster. This dynamic functionality is particularly useful for a geographically dispersed cluster.

Where a four node cluster is split across two sites and the File Share Witness goes offline, one node is chosen and its vote is removed. Again, we are left with three votes and the cluster is maintained. If the two sites were then loose connectivity, the side of the cluster that has two votes would remain up and keep the cluster running.

Although this behaviour is automatic, we can influence the choice of which cluster member loses its vote my using the new LowerQuorumPriorityNodeID Property. Assigning this property to a node at the disaster recovery (DR) site, we can make sure our primary site stays up.

Force Quorum Resiliency

There may come a time when we will need to force quorum on a DR site that doesn’t have majority and is currently offline. For example, your primary site with three votes has failed and your DR site with two votes hasn’t come online automatically because it doesn’t have enough votes. In a Windows Server 2012 R2 cluster we can start the cluster service with the /FixQuorum switch (also known as the /FQ switch), this partition is then considered the authority for the cluster.

When network connectivity is restored, you can bring the three nodes at your primary site back online, which will re-join the cluster automatically without any intervention. In Windows Server 2012, once connectivity is resorted, you would need to restart the failed servers with the /PQ switch to prevent quorum.

The above examples demonstrate some key improvements that are now at your fingertips, I hope you find them useful. If you have any questions or want to find out more, please don’t hesitate to leave a comment below.

Mike Brown is a Microsoft Certified Trainer (MCT) and lead Windows Server Instructor for Firebrand Training. When not teaching in the classroom or developing courseware, Mike creates a series of technical How-to guides for the Server community.

Tags Windows Server 2012Windows Server 2012 R2

More about MCTMicrosoft Pty Ltd

Comments

Comments are now closed

White hat hacker returns to Australia for the NBN

READ THIS ARTICLE
DO NOT SHOW THIS BOX AGAIN [ x ]