As I noted in a previous blog post “Windows Server 2012 R2 for the DBA: 10 Reasons It Matters”, Windows Server 2012 R2 introduces a new quorum concept: dynamic witness. In fact, the whole notion of quorum has changed a bit in Windows Server 2012 R2 (I’ll save that for another time). In this post I want to focus on dynamic witness only.

For those who don’t know, a witness in context of quorum is that additional “voter”/tie breaker in cases where you have an even number of nodes to ensure that you always have an odd number of votes. Prior to Windows Server 2012 R2, if you lost a node in a Windows Server failover cluster (WSFC), you would manually have to readjust quorum. For example, if you have a three-node WSFC and lost one node, you would still be up and running, but you would be down to two nodes and to get back to odd, you’d have to add some sort of witness in manually. Managing quorum is one of the most important administrative tasks for deploying WSFCs, and one of the most common things I see most environments not do well.

Enter Windows Server 2012 R2. By default, you create a witness when the WSFC is formed no matter how many nodes you have. However, the WSFC will not use the witness unless it needs it. I’m going to show you an example to illustrate how all of this works. In this case, I have a three node WSFC named STYX with the node names of DENNIS, TOMMY, and JY. I have a single clustered instance (FCI) of SQL Server 2014 named GRANDILLUSION that is currently running on JY. Figures 1 and 2 show this configuration.

The interesting thing as shown in Figure 1 is that there’s a new parameter for the WSFC: WitnessDynamicWeight. This will either be set to 0 or 1. If it’s 0, no witness is in play. With 1, a witness is being used. It’s really that simple.

 

Let’s say we lose JY which is currently hosting GRANDILLUSION. JY fails over to TOMMY as shown in Figure 3.

Now this is where things get interesting. With Windows Server 2012 and earlier, at this point you would see warnings noting with the loss of a node, you would go down. If you look at Figure 4, note that JY is down as I stated, but WitnessDynamicWeight has a value of 1 since we have an even number of nodes, making the total number of voters 3. This means it is using the witness I configured during the initial setup of the WSFC. In other words, the WSFC is managing quorum for me.

Now we lose TOMMY and GRANDILLUSION is running on DENNIS as shown in Figure 5. Wait, what? We’re down to one node – last man standing – and still running? You bet! This concept is not 100% new – last man standing was possible with Windows Server 2012 in many cases.

Figure 6 shows that both JY and TOMMY are down, but DENNIS is left standing alone with the witness disk.

Can you override dynamic witness? Sure. Let’s assume you have the same three node WSFC and you want the old behavior. Just get rid of the witness. In the Cluster Cluster Quorum Wizard dialog shown in Figure 7, select the option Do not configure a quorum witness.

Figure 8 shows the warning that Microsoft gives you when you have no witness in Windows Server 2012 R2.

Now let’s look at a similar scenario as above. We lost JY, and GRANDILLUSION is on TOMMY as shown in Figure 9. Note that WitnessDynamicWeight has a value of 0 and there is no quorum resource (nee witness) configured.

Finally, in Figure 10 we see that TOMMY is down for the count, and DENNIS owns GRANDILLUSION. The reason I show the value for WitnessDynamicWeight and no quorum is to show I wasn’t making this up; you’re literally down to last man standing again.

Like my quick glance at using CSVs with SQL Server 2014, this is a sneak peak at how Windows Server 2012 R2’s dynamic witness along with dynamic quorum introduced in Windows Server 2012 can increase the availability of your FCIs and AGs.