What is Exchange DAC?
First introduced in Exchange 2010 SP1, Exchange Datacenter Activation Coordination or Exchange DAC is a new property of the Database Availability Group (DAG) that will help solving a specific problem which is (split brain in case of data center switch over), that is when you have your DAG stretched between two or more sites, and you are performing manual switch over.
When shall I use it?
You can benefit from Exchange DAC when you have DAG stretched between two sites or data centers. Enabling Exchange DAC, will help prevent split brain when you perform Data center switch over. Split brain in this case is when different copies of the same database get mounted in the primary and secondary data centers, causing divergence.
Exchange DAC Configuration?
DAC is a property of the DAG (Database Availability Group) and it is disabled by default.
Who controls DAC?
Active Manager controls and coordinate the functionality of Exchange DAC, by maintaining a bit in memory that can be set to 0 or 1.
When Exchange DAC become important
The first thing to understand is that DAC solves certain scenarios and it will not add anything if you have single Exchange installation in one site, or if you don’t have DAG stretch between two sites. Saying that, I will quote from TechNet the following example about the DAC usage:
“Consider the two-datacenter scenario. Suppose there is a complete power failure in the primary datacenter. In this event, all of the servers and the WAN are down, so the organization makes the decision to activate the standby datacenter. In almost all such recovery scenarios, when power is restored to the primary datacenter, WAN connectivity is typically not immediately restored. This means that the DAG members in the primary datacenter will power up, but they won’t be able to communicate with the DAG members in the activated standby datacenter. The primary datacenter should always contain the majority of the DAG quorum voters, which means that when power is restored, even in the absence of WAN connectivity to the DAG members in the standby datacenter, the DAG members in the primary datacenter have a majority and therefore have quorum. This is a problem because with quorum, these servers may be able to mount their databases, which in turn would cause divergence from the actual active databases that are now mounted in the activated standby datacenter.”
In summary, Exchange DAC prevents split brain scenario in case disconnected stretch DAG between two sites.
Suppose we have DAG stretched between two datacenters JFK and LON. DAG has four mailbox servers, two at JFK site, and two at LON site, and a witness share in JFK site. A database has two copies, one on JFK mailbox server and one on LON mailbox server.
Now let us assume that JFK site is down, and the administrator decided to bring LON datacenter up by forcing the quorum (LON contains two servers which are two votes out of five. So forcing the quorum is necessary). Now our database is mounted on LON datacenter and everything is fine.
Suddenly, JFK is back again and the mailbox servers at JFK site are booting. The WAN link is still down. JFK servers are all up now, and they still cannot communicate with LON site, so they only have three votes (two mailbox server and a witness share), so JFK servers believe they have the majority and they have quorum state, so our database get mounted on JFK server. At this moment, we have the same database mounted in two different datacenter. DAG is invented to solve this behavior.
Exchange High Availability Guide
I hope by know you understand the problem that Exchange DAC is invented to solve. The practical implementation of DAC during datacenter switch over is available in my Exchange HA guide.