In part 2 of this series, I provided a high level overview of how the witness server for a database availability group (DAG) is used with Datacenter Activation Coordination (DAC) mode in the scenario when only a single member remains after a datacenter switchover. The witness server, and in particular its boot time, are very important when the system determines whether or not automount consensus has been reached.
When a datacenter switchover is performed and a single DAG member remains in the recovered datacenter, the restore-databaseavailabilitygroup cmdlet configures the cluster with a Node and File Share Majority quorum. The witness server in use is the alternate witness server configured for the DAG or specified when running restore-databaseavailabilitygroup. You can use get-databaseavailabilitygroup –status | fl name,*witness* to verify the witness in use, as illustrated below.
C:\>Get-DatabaseAvailabilityGroup -Identity DAG -Status | fl name,*witness* Name : DAG WitnessServer : dc-1.exchange.msft WitnessDirectory : C:\DAGFileShareWitnesses\DAG.exchange.msft AlternateWitnessServer : dc-2.exchange.msft AlternateWitnessDirectory : C:\DAGFileShareWitnesses\DAG.exchange.msft WitnessShareInUse : Alternate
This configuration, although automatic, may seem strange at first. In general, a Windows failover cluster only leverages the Node and File Share Majority quorum model when the cluster contains an even number of members. Although this configuration is normal and expected in this case, it can raise some concerns when administrators use Failover Cluster Manager to verify the status of the remaining cluster. Even more confusing is the warning on the cluster summary page that states that a failure of a node to access the defined file share witness may result in cluster instability.
The main concern for DAGs is the risk of losing the witness server (either by failure or reboot) but still have the Exchange environment stay running. Fortunately, in this configuration, when a single DAG member exists and the cluster is configured to use the Node and File Share Majority quorum model, the status of the witness server is ignored. Thus, even if the witness server is lost for any reason, the Exchange environment will continue to function. The decision to use this quorum model is partially based on the importance of the witness server in determining automount consensus in a single surviving member configuration. By configuring the quorum model as node and file share majority, we can leverage the cluster’s ability to monitor the witness server, and to accurately report status of this machine.
Thus, it is expected that after a datacenter switchover, DAGs with a single surviving member will leverage the Node and File Share Majority quorum model.
Datacenter Activation Coordination Series:
Part 1: My databases do not mount automatically after I enabled Datacenter Activation Coordination (http://aka.ms/F6k65e) Part 2: Datacenter Activation Coordination and the File Share Witness (http://aka.ms/Wsesft) Part 3: Datacenter Activation Coordination and the Single Node Cluster (http://aka.ms/N3ktdy) Part 4: Datacenter Activation Coordination and the Prevention of Split Brain (http://aka.ms/C13ptq) Part 5: Datacenter Activation Coordination: How do I Force Automount Concensus? (http://aka.ms/T5sgqa) Part 6: Datacenter Activation Coordination: Who has a say? (http://aka.ms/W51h6n) Part 7: Datacenter Activation Coordination: When to run start-databaseavailabilitygroup to bring members back into the DAG after a datacenter switchover. (http://aka.ms/Oieqqp) Part 8: Datacenter Activation Coordination: Stop! In the Name of DAG... (http://aka.ms/Uzogbq) Part 9: Datacenter Activation Coordination: An error cause a change in the current set of domain controllers (http://aka.ms/Qlt035)
Just noticed this situation after evicting a server from a two-node DAG, leaving me with one (testing datacentre switchover scenarios) and wondering why it kept insisiting on using a witness. Great article!
I'm glad you found the article helpful!