Deploying a Azure Cloud Witness for a Failover Cluster in Windows Server 2016

Cloud Witness is a new type of Failover Cluster quorum witness being introduced in the Windows Server 2016. This topic provides an overview of the Cloud Witness feature, the scenarios which it supports and the instructions about how to configure a cloud witness for a Failover Cluster that is running Windows Server 2016.

Organizations mostly do not have a third separate data center to help to back the File Share Witness to host the File Server.This means organizations primarily host the File Server in one of the two data centers which by extension, make that data center the primary data center. Let us take a scenario where there is a power outage in the primary data center, then the cluster which goes down as the other datacenter would only have 2 votes which are below the quorum majority of 3 votes needed. The customers who maintain a third separate data center for hosting the File Server, it is an overhead to maintain the highly available File Server backing the File Share Witness. Virtual machines are hosted in the public cloud that contains the File Server for File Share Witness running in Guest OS is a significant overhead in terms of both setup & maintenance.

A new type of Cloud witness- Failover Cluster quorum witness that leverages Microsoft Azure as the arbitration point. It uses Azure Blob Storage to read/write a blob file which is then used as an arbitration point in case of split-brain resolution.
There are significant benefits which this approach:

1. It Leverages the Microsoft Azure (does not require third separate datacenter)
2. Uses standard available Azure Blob Storage (no extra maintenance overhead of virtual machines hosted in public cloud)
3. Single Azure Storage Account can be utilized for multiple clusters (one blob file per cluster; cluster unique id used as blob file name)
4. Very low on-going $cost to the Storage Account (very small data written per blob file, which is updated only once when cluster nodes’ state changes)
5. Built-in Cloud Witness resource type

Cloud Witness: Supported scenarios for single witness type

If you have a Failover Cluster deployment, where all nodes can reach the internet (by extension of Azure), it is recommended that you configure a Cloud Witness as your quorum witness resource.
Some of the scenarios that support the use of Cloud Witness as a quorum witness are as follows:

• Disaster recovery stretched multi-site clusters
• Failover Clusters without shared storage (SQL Always On, Exchange DAGs, etc.)
• Failover Clusters running inside Guest OS hosted in Microsoft Azure Virtual Machine Role (or any other public cloud)
• Failover Clusters running inside Guest OS of Virtual Machines hosted in private clouds
• Storage clusters with or without shared storage, such as Scale-out File Server clusters
• Small branch-office clusters (even 2-node clusters)

Starting with Windows Server 2012 R2, it is recommended to always configure a witness as the cluster automatically manages the witness vote and the nodes vote with Dynamic Quorum.

Set up a Cloud Witness for a cluster

To set up a Cloud Witness as a quorum witness for your cluster, complete the following steps:

1. Create an Azure Storage Account to use as a Cloud Witness
2. Configure the Cloud Witness as a quorum witness for your cluster

Create an Azure Storage Account to use as a Cloud Witness

In this section, we will see how to view and copy endpoints URLs by creating a storage account and access keys for that account.

For the configuration of Cloud Witness, you require a valid Azure Storage Account that can be used to store the blob file (used for arbitration). Under Microsoft Storage Account, a well-known Container msft-cloud-witness is created by Cloud Witness.Cloud Witness writes a single blob file with corresponding cluster’s unique ID used as the filename of the blob file under this msft-cloud-witness container. This means that you can use the same Microsoft Azure Storage Account to configure a Cloud Witness for multiple different clusters.

When you use the same Azure Storage Account for configuring Cloud Witness for multiple different clusters, a single msft-cloud-witness container gets created automatically. This container will contain one-blob file per cluster.

To create an Azure storage account

1. Login to your Azure Portal account
2. In home page click New and select Storage and then select Storage account

3. In the Create Storage account page enter required details

1. Enter a name for your storage account
2. Storage account names must be between 3 and 24 characters in length and may contain numbers and lowercase letters only. The storage account name must also be unique within Azure
3. For Account kind, select General purpose
4. You can’t use a Blob storage account for a Cloud Witness
5. For Performance, select Standard
6. You can’t use Azure Premium Storage for a Cloud Witness
7. For Replication, select Locally-redundant storage (LRS)
8. Failover Clustering uses the blob file as the arbitration point, which requires some consistency guarantees when reading the data. Therefore you must select Locally-redundant storage for Replication type

Navigate to the storage and click Access key.

When you create a Microsoft Azure Storage Account, it is associated with two Access Keys that are automatically generated – Primary Access key and Secondary Access key. Primary Access Key is used to create Cloud Witness for the very first time. There is no restriction regarding which key to use for Cloud Witness.

Configure Cloud Witness as a quorum witness for your cluster

Cloud Witness configuration is well-integrated within the existing Quorum Configuration Wizard built into the Failover Cluster Manager.

To configure Cloud Witness as a Quorum Witness

Conclusion:

Deploying a Cloud Witness for a Failover Cluster is very simple and In case of power outage in one datacenter, then an equal opportunity is given to the cluster in another data center to keep it running. It is recommended to host the quorum witness in a location other than the two datacenters. This typically means requiring a third separate datacenter (site) to host a File Server that is backing the File Share which is used as the quorum witness (File Share Witness)

Got questions? Email us at: vembu-support@vembu.com for answers.

Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.