Part 1: Active Manager, Activate!
Part 2: Datacenter Activation Coordination Mode
In the first two articles I discussed on Exchange 2010 Active Manager and Datacenter Activation Coordination (DAC) mode in Exchange 2010 RTM. But Exchange 2010 Service Pack 1 (SP1) introduces changes related to DAC, which I’ll discuss in this post.
To start with, DAC mode support has been extended in Exchange 2010 SP1 to support all 2 DAG configurations with 2 or more members. This is great, since you can now enable DAC mode for 2-member DAGs. Like I explained in the 2nd part, split brain syndrome isn’t unlikely, all the more with 2 nodes given the 50/50 situation. Implementing SP1 enables you to leverage DAC mode for the simplest form of mailbox database resilience, using DAGs with 2 members over 2 sites configurations. When required, DAC in SP1 will use the Witness Server to provide the necessary arbitration.
Another thing is that SP1 doesn’t have the requirement of being enabled for DAGs in at least 2 Active Directory sites. This is good news for customers who have their Active Directory organized in a single site located over multiple locations, e.g. stretched VLANs.
When implementing SP1 on DAG members, you must implement SP1 on all DAG members as soon as possible. Reason is that DAG members running Exchange 2010 RTM can move their databases to a DAG member running Exchange 2010 SP1, but not vice versa. So, do not postpone implementation of SP1 on additional DAG members after implementing it on the first, as it impacts your failover and switchover options. Worst case when not doing so, is ending up in the situation where you cannot activate databases on a server because it doesn’t contain SP1.
Alternate Witness Server
In SP1 you can configure the Alternate Witness Server and Directory using the Exchange Management Console. This location can be used to preconfigure the Alternate Witness Server used during switchover or failover to the secondary datacenter. The configured value will be picked up automatically using the Restore-DatabaseAvailabilityGroup cmdlet during a datacenter switchover, when not explicitly specifying AlternateWitnessServer and AlternateWitnessDirectory there.
Note that this location could already be configured in Exchange 2010 RTM using the Set-DatabaseAvailabilityGroup using the AlternateWitnessDirectory and AlternateWitnessServer options.
DAC is a useful option that each administrator running DAGs on Exchange should consider enabling. But be aware of the caveats, like the requirement of all nodes to be able to communicate with each other during start up. All in all, DAC is a helpful option as it not only prevents issues like split brain syndrome, but it also makes the process of switching datacenters easier and less prone to error. Exchange 2010 SP1 extends the number of possible configuration in which to implement DAC, making DAC an option for the masses.
I hope you found this 3-part post useful, if you still got questions do not hesitate asking me.
Pingback: DAC: Datacenter Activation Coordination Mode (Part 2) « EighTwOne (821)
Pingback: DAC: Active Manager, Activate! (Part 1) « EighTwOne (821)
Thx for some good article, however if we are in an environment with active and passive databases is both datacernters. Are we still going for DAC use?
DAC seems to simplify the time it takes (reduce the steps) to bring the second datacenter to a fully “active” state. But In my scenario it’s already active since we host active copies of a DAG database there aswell. (2 mailbox servers within the DAG with 5 Databases)
In that case there is no real “primary” data center, so let’s call them Site A and Site B. Assuming a 3/2 distribution, I’d advise to create a second DAG for the databases active in the site B, with a FSW also located in Site B; passive databases for that DAG are in Site A. This way users in Site B are independent of Site A and the connection between both sites. Then enable DAC mode for both DAGs (DAC is activated per DAG) for its benefits. Since you have 5 members, I’d only add two passive copies in Site A for the databases of Site B. This way the 2nd DAG’s majority of the nodes + FSW are located in Site B.
Regarding your question, for a single DAG with active/passive mix on both data centers I’d still use DAC (since the minority of the nodes is in Site B you’d still have do recovery).
Where does the CAS Array fit in with an Active/Passive, two datacenter model. We can get to the same common name for our current CAS so I think we’re good. Our plan is to have one active datacenter and one passive datacenter. Also, you mentioned a caveat of all the DAG members to be online. How is that if a datacenter is offline? Also if the passive datacenter goes offline then we would just lose the DAG syncronization. We only have one copy of each database. Great articles by the way.
1) Depends. Restrictions are each (AD) site can only have 1 CAS array, and CAS arrays can’t span (AD) sites. Given that, it depends on the purpose of that 2nd, passive DC. If it’s resilience (ie standby), you’d need to switch over to the 2nd DC after determining primary site failure. Procedure for that depends on whether you’ve implemented DAC mode or not.
Guidance on procedures is given here:
Sample setup and writeup by Henrik Walther here:
2) If a DC is offline, that classifies IMHO as site failure so I assume you’re in switchover mode (see “Site Resilience” in DAC part 2)
3) Just sync, when there’s majority in the primary DC (all depending on your design ofcourse).
I hope this answers your questions.
Very nice and useful series
You are great man
I am trying to design a setup like your example with a DAG and two nodes across two data centers and a single AD site. The AD site spanning the two data centers is connect via fiber and servers in the two DCs share a subnet via layer 2 routing.
I would plan on having the file share witness at Data Center A.
So if Data Center A has a power loss, would the Exchange databases at Data Center B go active automatically? Would you still need to run steps for a data center failure.
Great write ups.
The Exchange DAG member in DC B wouldn’t be able to obtain quorum (no FSW access required for majority) so databases won’t go online automatically.
Thanks a lot.
Really very nice and useful articles.
Save me a lot time to understand how it works.