Unless you’ve been living under a rock, you should have heard by now that Windows 10 was announced in late September and is due sometime in 2015. A new version of the Windows client always means another version of Windows Server. At the same time the Windows 10 Technical Preview was made available, so too was its Windows Server counterpart. If you have a MSDN subscription, it’s there. More info and where else to get it can be found here. The release will most likely not be called Windows Server 10, so we’ll have to speculate on what they will call it.

With a new version of Windows Server comes changes – usually for the better. I love what both Windows Server 2012 and 2012 R2 brought to the table for clustering especially with things like dynamic quorum and witness, last man standing, the tie breaker, and more. Until now, I’ve been under NDA not to talk about some topics related to vNext, but today I got the thumbs up on the one I care about the most which would impact things like AG deployments.

One problem with multi-site (or even hybrid) scenarios for AGs or FCIs is that if you need to use a witness resource, where do you put it? There’s a lot to say on that topic which I put into one of the two quorum chapters in the book, but the bottom line is that you basically have two options: have a witness at one of the sites (known as asymmetric witness) or stick it somewhere that all sites can see such as another data center or somewhere in the cloud if you have the right networking. Today’s version of putting a witness in the cloud is the traditional file share witness (FSW). In vNext, you have a new tool in the drawer: cloud witness. It is early days, so there is always a chance this feature may not make the final cut but I sure hope it stays!

This option can easily be seen in Figure 1 in the Configure Cluster Quorum Wizard. It was hiding in plain sight, but like I said, I couldn’t talk about it until today.

Figure 1. Cloud witness option

This is not a FSW – let me be clear. On the next dialog shown in Figure 2, you have to enter your credentials for Azure storage. Yes, it’s Azure only – sorry Amazon or Google lovers. What this also means is that you need to have the cluster nodes connected to the Internet (not always possible), but this does NOT require the special hybrid networking you would need to normally bridge Azure to on premise deployments. That alone reduces many complexities intruduced with standard hybrid or disaster recovery solutions for SQL Server.

Figure 2. Entering the account information for the cloud witness

After the cloud witness is created, Figure 3 shows what you will see in Failover Cluster Manager (you can also see things in PowerShell, but this looks nicer in a blog post!). The cloud witness is a resource in the WSFC’s cluster group just like a disk or file share witness would be.

Figure 3. Cloud witness and how it looks in Failover Cluster manager

Finally, on the backend in Azure, it creates a GUID associated with the WSFC similar to that of a FSW. Figure 4 shows what this would appear like.

Figure 4. What the cloud witness looks like in Azure

Want to know more about quorum and witness? It’ll be in the book, but if you’ll be at PASS Summit next week, come see my session “Did You Vote Today? A DBA’s Guide to Cluster Quorum” (DBA-311) on Friday, November 7, at 8:15 AM in room 6E. It is a 75 minute session. “Did You Vote Today?” was also selected to be broadcast on PASStv, so even if you’re not at Summit, you can watch it live on the Web. No pressure, right? I may take questions live from Twitter – that has yet to be determined.