By: Edwin Sarmiento | Comments (5) | Related: > Clustering
Problem
In a previous tip on Step-by-step Installation of SQL Server 2016 on a Windows Server 2016 Failover Cluster - Part 1, we have read about how we can leverage Azure blob storage as a witness type for our Windows Server 2016 Failover Cluster. We are deploying a Windows Server 2016 Failover Cluster (WSFC) across multiple data centers to support our SQL Server Availability Groups. We would like to test using Azure blob storage as a witness type. How do we do it?
Solution
With the increasing demand for multi-data center deployments for SQL Server Availability Groups, the need for a more stable and reliable WSFC has become even more important. Properly configuring the quorum is a very important step in ensuring high availability for the WSFC. In a single data center deployment, configuring the WSFC quorum type is much simpler since all of the nodes reside in a single data center. In multi-data center deployments, it’s a bit complicated. A common recommendation for multi-site WSFC deployments is to configure a file share witness that is on a separate location where the WSFC nodes reside. This means setting up a file server on another data center that can host the file share witness. However, this is not practical. Not only do you need a file server to host the file share witness, you also need to join the file server to the same Active Directory domain as your WSFC and configure networking to allow all of the WSFC nodes to connect to the file server – all of this just for an extra vote that can count towards the quorum and maintain availability of the WSFC. My recommendation - for practical reasons - has always been to simply host the file share witness on the same location as what you are trying to protect – the production data center. If the production data center becomes unavailable, there is a much bigger problem that needs to be solved other than worrying about the availability of the file share witness.
Cloud Witness in Windows Server 2016 Failover Cluster
The ability to use Azure blob storage as a witness type for a WSFC was introduced in Windows Server 2016. You can think of this as a special type of file share witness. But instead of using a file share configured on a file server running on a different data center, it is hosted on an Azure blob storage that is publicly available worldwide. If you are already using Microsoft Azure resources, you can simply add another Azure storage account specifically for your Windows Server 2016 Failover Clusters. A diagram of a multi-site WSFC that leverages Azure blob storage as a witness type is shown below.
Side note: I still have some reservations on using Azure blob storage as a witness type. For one, it is on a public cloud. This means that you need to allow your WSFC nodes – the very platform you use to run your highly available, mission-critical databases – access to the internet. Cloud witness uses the HTTPS REST interface of the Azure storage account service. Which means it requires the HTTPS port (port 443) to be opened on all cluster nodes or allowed on the network proxy servers. This is not to say that Microsoft’s infrastructure is not secure. It is. My concern is mostly due to organizations – specifically small and medium-sized enterprises - that do not have security policies in place to protect digital assets and properly educate the staff. A misconfigured firewall rule that opens ports to the public internet can pose potential security risk. User education is very important.
Configuring Cloud Witness in Windows Server 2016 Failover Cluster
To configure Cloud Witness in a Windows Server 2016 failover cluster, you need to:
- Create an Azure storage account to use as a Cloud Witness
- Configure Cloud Witness as a quorum type for your WSFC
Create an Azure Storage Account
To create an Azure storage account:
- Sign in to the Azure portal.
- In the Azure portal, Click +New. On the Azure Marketplace window that appears, click Storage. In the Featured window that appears, select Storage account – blob, file, table, queue.
- In the Create storage account window that appears, do the
following:
- Provide a name for the storage account
- Specify the deployment model to be used. Resource Manager is recommended.
- Select the type of storage account. General purpose should be used for Cloud Witness.
- Select the replication option for the storage account. Locally-redundant storage (LRS) should be used.
- Select the subscription in which you want to create the new storage account.
- Specify a new resource group or select an existing resource group.
- Select the geographic location for your storage account.
- Click Create.
Another way to create an Azure storage account is by using the New-AzureRmStorageAccount PowerShell cmdlet as described in this previous tip. Be sure to create the Azure resource group first by using the New-AzureRmResourceGroup PowerShell cmdlet.
New-AzureRmResourceGroup -Name "WSFC2016" -Location "eastus" New-AzureRmStorageAccount -ResourceGroupName "WSFC2016" -Name "wsfc2016cloudwitness" -SkuName "Standard_LRS" -Kind "Storage" -Location "eastus"
When you create an Azure storage account, Azure generates two 512-bit storage access keys, which are used for authentication when the storage account is accessed. You will need a storage access key so you can configure Cloud Witness on your WSFC. Imagine your WSFC accessing the Azure blob storage by using the storage access key with the storage account name.
To retrieve that Azure storage account access keys,
- In the Azure portal, navigate to your storage account.
- In the Storage Account window that appears, click Access keys under Settings.
- In the Access keys window that appears, select either key1 or key2. In this example, key1 is used. Copy it for your reference. You will provide this value later when you configure Cloud Witness for your WSFC.
Another way to retrieve the key1 storage account access key value is by using the Get-AzureRmStorageAccountKey PowerShell cmdlet. The Value property returns an array of objects – in this case, key1 and key2. Index zero is used to obtain the first element in the array.
(Get-AzureRmStorageAccountKey -ResourceGroupName "WSFC2016" -AccountName "wsfc2016cloudwitness").Value[0]
Configure Cloud Witness as a Quorum Type
Prior to configuring the WSFC quorum type, be sure that all of the nodes can access the Azure blob storage by allowing traffic to HTTPS port (port 443) be opened or allowed on the network proxy servers. Enlist the assistance of your network engineers to accomplish this task, making sure that WSFC is not accessible from the public internet.
To configure Cloud Witness as a quorum type:
- Open the Failover Cluster Management console
- Select the name of the WSFC you have just created. Right-click, select More Actions, and click Configure Cluster Quorum Settings... This will open up the Configure Cluster Quorum Wizard.
- In the Select Quorum Configuration Option dialog box, select the Select the quorum witness option. Click Next.
- In the Select Quorum Witness dialog box, select the Configure a cloud witness option. Click Next.
- In the Configure cloud witness dialog box, provide the Azure storage account name for the Azure storage account that you created and its corresponding Azure storage account key. Click Next.
- In the Confirmation dialog box, verify that the cloud witness configuration for the quorum/witness is correct. Click Next.
- In the Summary dialog box, verify that the entire configuration is successful. Click Finish.
Another way to configure Cloud Witness is by using the Set-ClusterQuorum PowerShell cmdlet as described in this previous tip.
Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey>
You can verify that the WSFC quorum setting is now configured to use the Cloud Witness by looking at the Cluster Core Resources section.
Another way to view the WSFC quorum setting is by using the Get-ClusterQuorum PowerShell cmdlet as described in this previous tip.
Get-ClusterQuorum
In this tip, you’ve leveraged Azure blob storage to configure Cloud Witness for your Windows Server 2016 Failover Cluster.
Next Steps
- Read more on the following topics
About the author
Edwin M Sarmiento is a Microsoft SQL Server MVP and Microsoft Certified Master from Ottawa, Canada specializing in high availability, disaster recovery and system infrastructures.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
