6

I am looking for some guidance on architecting our SQL Server 2016 SP1 Always On Availability Groups HADR solution on Windows Server 2012 R2. We have a primary site A with a primary replica and a secondary replica and a disaster recovery (DR) site B with a secondary replica and a file share witness. Our goal is that if the primary replica server 1 at site A is down, the Always On Availability Group (AG) fails over to the secondary replica server 2 at site A, and if both servers at site A are down, the AG fails over to site B.

We are attempting to do a Node and File Share Majority configuration per https://technet.microsoft.com/en-us/library/cc731739(v=ws.11).aspx and this diagram:

enter image description here

This diagram shows that when one node and the "disk" / file share witness are in communication the cluster runs, but in our testing of this situation, the cluster fails due to a loss of quorum of the WSFC. The automatic AG failover works if we test a failure of one server at a time by disabling the NIC in vmWare since SQL Server 2016 supports two automatic failover target replicas. However, it does not work if we fail both servers at site A at the same time to simulate a point-to-point network failure or a site power failure.

The following approach with manual intervention to force the quorum will work but it is not automatic, which is what we want in the ideal situation:

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode –Name $node –FixQuorum

ALTER AVAILABILITY GROUP SQLServerAO FORCE_FAILOVER_ALLOW_DATA_LOSS;

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode –Name $node

I appreciate any suggestions you can offer and thank you in advance!

5
  • 1
    Your risk with this model right now is that losing connectivity between sites would lose you quorum, and you'd go offline (as there would be no majority based on votes in your primary site). Presumably you are running 2012R2? Dynamic quorum would be good for you to look at. As regards totally losing site 1, you would be in the same position as losing site 2. There is no quorum maintained and you would have to force quorum to bring things online. Auto failover between sites is something I would recommend against, simply because quorum is extremely difficult (read nigh on impossible) to handle.
    – Nic
    Feb 7, 2017 at 18:56
  • What version of VMWare are you using? Feb 7, 2017 at 18:57
  • Thanks, Nic. Yes, we're running Windows Server 2012 R2. Feb 7, 2017 at 19:23
  • Antoine, we're running vmWare 6.0. Feb 7, 2017 at 19:25
  • Not sure dynamic quorum would help much for a sudden loss of connectivity between data centers. I would expect the cluster to go down. From technet.microsoft.com/en-us/library/… Additional considerations Dynamic quorum management does not allow the cluster to sustain a simultaneous failure of a majority of voting members. To continue running, the cluster must always have a quorum majority at the time of a node shutdown or failure.
    – cjsommer
    Feb 7, 2017 at 19:31

3 Answers 3

1

Our goal is that if the primary replica server 1 at site A is down, the Always On Availability Group (AG) fails over to the secondary replica server 2 at site A, and if both servers at site A are down, the AG fails over to site B.

Except for a very specific scenario, this will not work. In all other scenarios you'll lose quorum before you'd ever be able to automatically fail over (which requires... quorum).

The best answer would be to have the DR side be manual failover (it could still be synchronous) with the proper documentation on how to force quorum and bring the AG online.

You could also invest more into VMWare and use their technologies but that assumes the infrastructure, licensing, and ability to implement those products for a specific service such as this.

2
  • Sean, did you have any specific VMWare technologies in mind? Thanks. Feb 8, 2017 at 13:27
  • @MikePetrak well there is the regular DRS that could work for you (might not meet SLA) and there is also SRM which requires quite the investment but may also work for you. Feb 8, 2017 at 13:57
1

You should consider windows server 2016. blogs.msdn - introducing-cloud-witness

1
  • Thanks, Dan. We haven't started experimenting with Windows Server 2016 yet, but that sounds like a neat possibility for the future. Feb 11, 2017 at 19:44
0

We have a primary site A with a primary replica and a secondary replica and a disaster recovery (DR) site B with a secondary replica and a file share witness.

Okay, you have 3 node cluster, 2 nodes are hosted in Site A and one hosted on Site B.

Site A has a primary replica (node1) and a secondary replica (node2)
Site B has a secondary replica (node3)

And your quorum model is: Node and File Share Majority.

By default, each node will have 1 vote and file share witness will have 1 vote.

The total quorum votes will be node1 + node2 + node3 + file share witness = 1 + 1 + 1 + 1 = 4 and the current quorum majority will be 4 out of 4, i.e. 100% survival.

Let’s assume there is network connectivity issue between subset (2,2) of the cluster nodes, now the quorum majority will be 2 out 4, i.e. 50 % chance for survival. The problem here is, each subset will think, it has majority and it will try to own the resource groups to keep the cluster up and running, but **Windows Server Failover Cluster (WSFC)** supports only one active nodes at a time, two subset of nodes trying to access to same resource end up in conflicting issue, this is called split-brain scenario.

So having even number of nodes in cluster is not the right approach.

SQL Server 2016 SP1 Always On Availability Groups HADR solution on Windows Server 2012 R2

To avoid the above mentioned issue, Windows Server 2012 R2 introduced a new feature called Dynamic Witness.

In your case, (starting from Windows Server 2012 R2) the default voting will be as follows:

node1 + node2 + node3 = 1 + 1 + 1 = 3 & File Share Witness = 0

Here, the total quorum votes will be 3 and majority is 3 out of 3. There is no voting for File Share Witness to keep the total voting as odd number.

If there is a failure of node, the cluster will assign a vote to the File Share Witness dynamically. The process of assigning or revoking quorum vote to witness dynamically called as Dynamic Witness.

And the new quorum will be calculated dynamically post failure of node. For example, if a node is failed, and witness has a vote, the quorum will be 3 out of 3, i.e. node2 + node3 + File Share Witness. The process of adopting quorum after subsequent failure is called Dynamic Quorum.

Our goal is that if the primary replica server 1 at site A is down, the Always On Availability Group (AG) fails over to the secondary replica server 2 at site A, and if both servers at site A are down, the AG fails over to site B.

So let see the failure scenario for your case:

Default:

node1 node2 node3 File Share Witness Quorum Majority
1       1    1          0               3 out of 3 100 %

1 node failure:

node1 node2 node3 File Share Witness Quorum Majority
0       1    1          1               3 out of 3 100 %   

--> **`Dynamic Quorum and Dynamic Witness`**

In this case, the cluster become, 2 node cluster with witness.

Here, the default quorum configuration will be node2 + node3 + File Share Witness = 1 + 1 + 1 = 3 out of 3 (because dynamically quorum updated as 3)

Let’s assume another node fails (node2)

node2 node3 File Share Witness Quorum Majority
0        1          1               2 out of 3 66.66 % 

  --> It has majority - more than 50% - the cluster will survive

Now the new cluster will be:

node3 File Share Witness Quorum Majority
1      1                   2 out of 2                        --> Dynamically quorum updated as 2

In case of another node failure, the cluster will be down. I hope this is clear. Any node may fail in any order, but the quorum majority is calculated same as above.

Having cloud witness will be better option, but it will not solve your problem, still it is just an option. Please check my page for deeper understanding of Windows Server Failover Cluster Quorum

To setting up DR, I suggest a simple solution:

On Site A set up Always On Availability Group (AG) with 2 node cluster and configure quorum model as Node and File Share Majority.

On Site B set up SQL Server Standalone instance and configure - automated backup and restoration / log shipping from Site A.

There will be different options, this was the one, I have used earlier. In this case, failover should be performed manually. Consider your business requirement and design the DR strategy.

Few points to be noted while designing HADR solutions:

  • Recovery Time Objective (RTO)
  • Recovery Point Objective (RPO)
  • Scalability
  • Retention Policy,
  • Failover, etc...

I recommend you to check my page for better understanding. I hope this answer helps, thank you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.