All we need is an easy explanation of the problem, so here it is.
We are looking to build a 3-node AlwaysOn Windows 2012 R2 failover cluster with 2 nodes in our primary datacenter for HA, and a 3rd node replica in our DR datacenter for reporting.
Given this is a multisite cluster, is there any way to configure this in a way which automatic failover will occur if the primary and DR sites lose connectivity or if the primary site goes down entirely? Or would we have to add a 3rd site with a file share witness to the mix to make that possible?
How to solve :
I know you bored from this bug, So we are here to help you! Take a deep breath and look at the explanation of your problem. We have many solutions to this problem, But we recommend you to use the first method because it is tested & true method that will 100% work for you.
The simplest answer is, no, you won’t be able to facilitate this with a 3 node cluster in the manner described.
The reason is due to quorum. Assuming the 3 nodes, 2 at Primary and 1 at DR with Windows Server 2012R2. Dynamic quorum is on by default, this will automatically adjust node weights in case of a node failure. Dynamic witness is also on by default which will change the witness vote to keep the number of total votes odd.
The thing is that dynamic quorum only works if less than half of the nodes go down simultaneously. If 50% or more voting nodes go down at once there won’t be enough voters left to keep quorum or for dynamic quorum to decide that this isn’t a split brain scenario.
How could you potentially achieve this?
If it would be possible to put 2 nodes at the Primary site, 2 nodes at the DR site, and a witness at a 3rd site then it should do what you’re looking for.
is there any way to configure this in a way which automatic failover will occur if the primary and DR sites lose connectivity or if the primary site goes down entirely?
These look the same from the perspective of the DR site. Whether it loses connection with the servers at the primary site or whether the primary site goes down doesn’t look any different. In each case they no longer can “see” the other nodes, only the local ones. This results in the race to acquire the lock on the witness. Whichever side attains the lock first, wins.
There is an additional setting in Windows Server 2012R2 called
LowerQuorumPriorityNodeID which can be used to weight one side or the other when these types of situations happen.
Note: Use and implement method 1 because this method fully tested our system.
Thank you 🙂