Cloud Witness in Windows Server v.Next

Last week, I attended the session “Did you vote today? A DBA’s guide to cluster quorum” at PASS Summit, by Allan Hirt.
Interesting stuff, and I learned that my quorum configuration is already done correctly according to what Allan explained.

Another interesting part was that Allan announced that there is a new type of quorum in Windows Server v.Next.

Cloud Witness!

Instead of using a File Share Witness or Disk Witness, you can now also choose Cloud Witness.
Basically it’s going to create a file on your Azure Storage which counts as a quorum vote.
This cloud witness can be really helpful in case of multi-site clusters.
With multi-site clusters, there is always the question in which datacenter you are going to put the file share witness.
In fact, to configure it correctly, you should put your file share witness in a third datacenter. But that’s really too expensive for most companies just for a file share witness. The cloud witness provides a good alternative for this problem.

The only “issue” that I see with this cloud witness, is that your cluster nodes must have connection with the internet. And honestly, I haven’t seen much SQL Servers or cluster nodes that are able to connect to the internet.
But with the appropriate firewall settings, you should be OK.

I’ve already installed a 2 node Windows vNext Failover Cluster and tried it out.
It’s actually really easy to configure.

Start with opening the Failover Cluster Manager and connect to your cluster.
Right click on the cluster name à More Actions à Configure Cluster Quorum Settings…

In the “Select Quorum Configuration Option” windows, select “Select the quorum witness”

In the “Select Quorum Witness” windows, select “Configure a cloud witness”

To configure the cloud witness, you need to specify your storage account and your Azure storage account key.

This information can be found on the Azure Portal. Just go to the storage option. On the bottom of your screen you will see a button called Manage Access Keys.

Click on that button, copy one of the 2 keys and paste it in the Azure storage field of the cloud witness configuration

Your configuration should look similar like this screen shot below

Finally, complete the wizard and if all went well you have now configured your cloud witness.

When you look at your storage account in the Azure Portal, you will notice that a new container, “msft-cloud-witness”, is created with 1 blob file inside.

Pretty cool if you ask me 😀 !



Denali Multi-Site Cluster – DNS Latency Issues During Failover – How to change HostRecordTTL

While I was playing around with my Denali Multi-Site Cluster, I noticed that sometimes you can have DNS Latency Issues During a Failover.

When the SQL Server cluster instance fails over to another subnet, the online IP address changes accordingly. Windows failover cluster issues a DNS update immediately after the network name resource name comes online. However the client connections will not reflect the DNS update due to the local DNS cache on the client machines, and possible DNS replication latency if the cluster nodes and the client machines are not using the same DNS server. Therefore, the client machines cannot resolve the network name causing connection failure until the DNS replication is complete and the local DNS cache is timed out.

To minimize the client downtime, Microsoft recommends setting the HostRecordTTL to 60 seconds for most multi-subnet clustering environment.
The default value of the network name resource private property HostRecordTTL is 1200 seconds. Before making the HostRecordTTL value change, please consult your DNS server administrator to make sure your DNS server can handle the increased query request from database client machines.

You can find more details here

Below you can find the procedure how I changed the HostRecordTTL on my Denali Multi-Site Cluster

Step 1: Login on your active cluster node
Open the Failover Cluster Manager.  Below you can see a screenshot of my cluster

Step 2: Retrieve your Network Name Resource.

For me, the Failover Cluster Manager is not very clear, so I looked it up with the following command in a command prompt:

cluster res

After you executed the command, you find a list of all your cluster resources.  Look for the cluster resource that start with “SQL Network Name”.  See screenshot below

Step 3: Retrieve the current value of the HostRecordTTL

To retrieve the HostRecordTTL current setting, I executed the following command:
cluster /cluster:DENALLICLUSTER res “SQL Network Name (DENALISQL)” /priv

Remark: Change the cluster name and resource name according to your installation

After you executed the command, you find a list of all the properties of the resource.  Look for the HostRecordTTL properties and check the value.
Default value is 1200 seconds. See screenshot below.

Step 4: Change the HostRecordTTL value

To change the HostRecordTTL value, execute the following command

cluster /cluster:DENALLICLUSTER res “SQL Network Name (DENALISQL)” /priv HostRecordTTL=60

Remark: Change the cluster name and resource name according to your installation

After you have executed the command, you will get a warning stating that you have to bring your resource off line before your new setting will take affect. See screenshot below.

Step 5: Verify if your new value

To confirm that your new setting will be applied, execute the following command again:

cluster /cluster:DENALLICLUSTER res “SQL Network Name (DENALISQL)” /priv

Remark: Change the cluster name and resource name according to your installation

Step 6: Take your resource offline and online

Take the clustered service or application offline and bring it back online, using the method that you are most familiar with