What’s new in failover clustering: #08 Cloud Witness

This post was authored by Amitabh Tamhane, Program Manager, Windows Server

Introduction

The primary goal of failover clustering in Windows Server is to provide a reliable infrastructure to make workloads highly available. Configuring quorum correctly for failover clusters is an important step in ensuring high availability for the cluster itself. This helps to make applications hosted on clusters to be highly available. With features like Dynamic Quorum, Dynamic Witness, and Node Vote Tiebreaker, the cluster automatically handles quorum vote calculations to provide the most optimal quorum configuration. When cluster quorum witness is specified, it gives an additional quorum vote for the cluster to toggle as needed, providing highest availability.

The recommendation is to simply always configure quorum witness – which effectively lets the cluster determine when to use the quorum witness vote as needed. This greatly simplifies the cluster quorum configuration. The question is: What type of quorum witness should be configured?

Cloud Witness is a new type of failover cluster quorum witness being introduced in Windows Server 2016. Cloud Witness leverages Microsoft Azure’s Blob Storage to read/write a blob file, which is then used as an arbitration point in case of split-brain resolution.

Benefits of using Cloud Witness

There are significant benefits from this approach:

• Leverages Microsoft Azure
  • No need for a third separate datacenter when stretching a cluster across datacenters
• Uses standard publically-available Microsoft Azure Blob Storage
  • No extra overhead of maintaining VMs hosted in the public cloud
• Same Microsoft Azure Storage Account can be used for multiple clusters
  • Single blob file per cluster with cluster unique id as blob file name
• Very low on-going $cost to the Storage Account
  • Very small data written per blob file
  • Blob file updated only once when cluster nodes’ state changes
• Built-in Cloud Witness resource type
  • No extra download/installation steps necessary

Single witness type for most scenarios

If you have a failover cluster deployment, where all nodes can reach the internet (by extension Microsoft Azure), it is recommended to configure Cloud Witness as your quorum witness resource. Here are some sample scenarios where the Cloud Witness functionality can be utilized:

• 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 or Amazon Web Services IaaS VMs (or any other public cloud)
• Failover clusters running inside Guest OS hosted on Enterprise, Hoster, Azure Stack Private Cloud VMs (or any other private clouds)
• Storage clusters with or without shared storage (Storage Spaces Direct clusters, Scale-out File Server clusters, etc.)
• Small branch-office clusters (even 2-node clusters)

Easy to deploy

Our goal when making this feature available was to ensure that it would be a no-brainer to anyone familiar with failover clustering in Windows Server to start using the Cloud Witness option. With that in mind, we made an easy way to deploy Cloud Witness using Failover Cluster Manager GUI or cluster PowerShell:

PowerShell syntax

Set-ClusterQuorum –CloudWitness –AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey>

Microsoft Azure Storage Account considerations

There are a few things you’ll need to consider when using the Cloud Witness option:

• Failover cluster will not store the Azure Storage Access Key, but rather it will generate a Shared Access Security (SAS) Token that is generated using the Access Key provided and stores this SAS Token securely.
• The generated SAS Token is valid as long as the Access Key remains valid. When rotating the Primary Access Key, it is important to first update the Cloud Witness (on all your clusters that are using that Storage Account) with the Secondary Access Key before regenerating the Primary Access Key.
• Cloud Witness uses HTTPS REST interface of the Microsoft Azure Storage Account service which requires the HTTPS port to be open on all cluster nodes.

To try this new feature in Windows Server 2016, download the Technical Preview.

Check out the series:

• #01 Cluster OS Rolling Upgrade
• #02 VM Load Balancing
• #03 Stretched Clusters
• #04 Workgroup and multi-domain clusters
• #05 Resilient private cloud
• #06 Virtual machine start ordering
• #07 SMB Multichannel & Multi-NIC cluster networks