In order to have a well-configured cluster we need to setup the quorum properly, but there’s more…Here is where the Cloud Witness comes to help.
In this article, I’m going to present something that would be very useful if was already been released, but no, I need to anxiously wait for the next version of Windows Server to be released, in order to start implementing this. Even though, I’m going to share with you, SQL Shack reader, why I’m so excited with that small and simple feature.
I’m talking about the new Cloud Witness capability. Yes, the Windows Server is not supporting this yet (we are currently on Windows Server 2012 R2), and yes this is coming in the new release, probably called Windows Server 2016.
Following our hybrid deployments series, I will be showing the benefits and how to implement this new feature that I already tested.
But, what’s the motivation of this?
Do you remember my previous article, about how to build a low-cost disaster recovery solution? This feature could be integrated on that article, as this is going not only to improve the Windows’ capabilities, but also to enlarge the number of options that you have to configure a cluster Quorum in a way that better fits your strategy and your budget!
You should be asking now: “what the heck is this related to SQL Server?” The answer is simple, and comes in the form of other questions…
- Do you have clustered instances?
- Is there any availability groups deployed in your environment?
- Do you have a Disaster Recovery solution sit in an AlwaysOn Failover Cluster?
If you answered yes to one of those questions, this is for you.
What is the benefit of having a cloud witness?
There is nothing better than the real story, to show its benefit…
Basically, I had an experience with the following configuration:
- A multi-subnet cluster composed by 4 nodes
- Two nodes in a datacenter Chicago
- Two nodes in a datacenter Las Vegas
- The cluster witness was a fileshare in the Chicago’s datacenter
- The quorum is configured as “Node and File Share Majority”
An image is worth a thousand words…
On this scenario, we have five voting components, the 4 nodes + the fileshare. This way, we need to have three votes to keep the cluster up and running.
What would happen if the entire Chicago datacenter goes down, for example, because of a power outage?
If you said “the cluster will become offline”, you are right! As we lost two nodes and the fileshare witness, we lost 3 votes… so we cannot have the three votes to keep the cluster up…
In order to avoid this situation, we could do the following:
- Arrange a fileshare in a third location (another datacenter)
- Use this fileshare as witness.
Let’s say that this new fileshare will be in Austin. The cluster representation would be the following:
Having this, even if either the whole Chicago or Las Vegas datacenter go down again, you will still have the minimum number of votes to keep the cluster working. The only way to take the cluster down is to have both Austin and either Chicago or Las Vegas down (and it’s obvious that having Las Vegas and Chicago down nothing would work).
The problem can be solved in this way, but let’s think… In order to just have a simple fileshare in another location, I had to involve another datacenter! This is not that simple and, even less, that cheap. For a big corporation, this could be arranged with a simple request, but what if you are a startup? What would be the option?
Now we can introduce the Cloud Witness, a new kind of cluster witness, which comes in the Windows Server vNext (probably 2016).
The Cloud Witness takes an advantage of Azure and its Blob Storage service. By the way, do you remember the number of things that the Azure Blob Storage is capable to address? This single server can provide an alternative way to do backups, to save your database files, to extend the table partitioning… If you take a look on my previous articles you will be a witness of the Azure Blob Storage power
The big advantage of this feature is that you won’t need a third datacenter. Another good point is that this service is very low-cost as just few read and write operations will be done.
If we start using the Cloud Witness in the environment that we were talking at the beginning of the article, this would be as follows, resolving the voting problem with a simple configuration and a minimum amount of money:
Going back to what matters here… How can I start with this?
You can already test this feature, by downloading the Windows Server 2016 preview. An Azure account is also needed. If you don’t have it, you can create a trial one.
Having Windows Server installed and the Azure account ready, you will need to create an Azure Blob Storage Account. Just click the “New” icon in the bottom-left corner of the portal, and follow the steps shown in the image bellow:
The same Storage Account can be used for multiple Windows failover clusters, as one blob file will be created per cluster.
On the Windows side go to the Cluster Quorum configuration:
Chose the option “Select the quorum witness”:
You will find the “Configure a Cloud Witness” option:
Following the wizard, you will need to fill your account name, storage account key and the service endpoint:
That was the last step! If everything is good, you will be able to find the Cloud Witness icon in your cluster properties, as you can see in the image below:
And that’s it… Azure is bringing more and more tools to make our lives easier and options to reach a good result spending less money than before. As said, I’m eager to have my customers with the new Windows version in production, so I will be able to use this solution in order to improve the availability of their environments.
I hope you liked and keep tuned for more articles!
- Understanding backups on AlwaysOn Availability Groups – Part 2 - December 3, 2015
- Understanding backups on AlwaysOn Availability Groups – Part 1 - November 30, 2015
- AlwaysOn Availability Groups – Curiosities to make your job easier – Part 4 - October 13, 2015