Exchange 2010 - Database Availability Groups - Part 1

This is part one of a two part series on Database Availability Groups, which is the Exchange 2010 High Availability and Disaster Recovery technology.

DAGs are similar to Exchange 2007's SCR and CCR technologies, but mixed together, along with a few key benefits like:

Incremental Deployments - You can start with a single server environment and add hardware later to phase in a DR plan or additional high availability. However, you would need to deploy Exchange 2010 on Windows 2008 R2 Enterprise as DAG's require the Failover Clustering role. In a lab, I wouldn't mind an in place Standard to Enterprise in place upgrade, but your opinion may differ on such an upgrade on a server containing production data.

Automated Cluster Management - In Exchange 2007, CCR Cluster management needed to be pre-configured on server nodes, and there was additional complexity and confusion on what tasks you performed in Cluster Administrator, and which in Exchange Management Console or Shell. In Exchange 2010, this is ALL performed from native Exchange tools, and most can be done from a GUI.

Combined HA and DR plan - In Exchange 2007 CCR was the High Availability solution, while SCR was the Disaster Recovery solution. In order to effectively get both, deploying both was required. There was a combined solution known as "Stretched CCR" where a node would be in a different physical site, but this was fairly complicated and had high bandwidth requirements.

Lower Bandwidth requirements - In Exchange 2007, SCR used SMB (Server Message Block) for transaction log shipping. SMB is well known as being a "fat" network protocol. In Exchange 2010, Exchange Administrators can choose a single TCP port (configurable) for direct TCP connectivity for log shipping.

Less Powershell - If you checked out the Exchange 2007 SCR article I recently published, you see there is a LOT of PowerShell, which is why I wrote the article - there are a lot of steps and places for confusion, mistyping, and mistakes. And in the event of a diaster, that can be pretty harrowing. The Exchange 2010 DAG process, while of course is able to be managed from PowerShell, is not a requirement. Most of the screenshots I will post you will see are done in the GUI.

There is a LOT to be learned about scaling and planning DAG's, and I am leaving this to Microsoft for now. Below are some valuable links on DAGs, DAG planning, and planning disks for your member servers in a DAG.

Planning for High Availability and Site Resilience - the requirements here is pretty much required reading if you are considering implementing Database Availability Groups in your environment.
Mailbox Server Storage Design Recommendations - at the time of this posting, this was marked as "in tech review" - about 1/2 way down you can tell the article is talking about Exchange 2007 more than 2010. There also is still not an Exchange 2010 storage calculator, this will hopefully come soon.
Deploying High Availability and Site Resilience - much of this How to is based on information here.

First off, my environment - Exchange 2010 is ONLY 64 bit, so of course, that is the architecture in play here.

Server	OS	LAN Network	Replication Network
EXCH2010	Windows 2008 R2 Enterprise	192.168.201.62	10.1.1.62
EXCH2010DR	Windows 2008 R2 Enterprise	192.168.201.63	10.1.1.63

Currently, there is one database on EXCH2010 named geodb1 - it contains a single user mailbox. As you can see, I configured this database with non-default paths. While using the default path is fine, if and when you need to specify a path in PowerShell ever, it's easier if its not 50 characters of path to type.



Whatever server is the witness needs to be a member of the Exchange Servers domain group, or you will receive an error message. If you are using a domain controller as your FSW, you need the DC's computer account to be a member of the Exchange Trusted Subsystem group, and your Exchange Trusted Subsystem group must be a member of your domain's BUILTIN\Administrators group. Thanks to Tom Pacyk for this information! If you receive the warning "Insufficient permissions to access file shares on witness server" please review Tom's article.



Once we create the DAG, we can now add servers to the DAG.


Adding both servers is as simple as right clicking the DAG and choosing "Manage Database Availability Group membership." This process may take a while depending on hardware, as during this step is when Failover Clustering is installed and configured on both servers.


This process also created the DAG networks for me, and now my DAG screen looks like this:



I do not want replication enabled on the 192.168.201.x network, I want it explicitly on the 10.1.1.x network, so I disabled replication for DAGNetwork01, and also told the DAG to ignore the network using Powershell:

Set-DatabaseAvailablityGroupNetwork -Identity GEODAG\DAGNetwork01 -IgnoreNetwork:$true -ReplicationEnabled:$false

Now we can add a database to our DAG!

Then right click the database you want a copy of and choose "Add Mailbox Database copy" and choose the server you want to add a copy on.





This will complete, And then you can see the database re-synchronizing, and then come Healthy:




Here, I decided to reboot the EXCH2010, and refreshed the EMC console on EXCH2010DR:



We can see that EXCH2010 failed, and EXCH2010DR now has my data. I logged into OWA and confirmed.

When EXCH2010 came back up, I waited and refreshed again:



Healthy! Very neat.

At this point, we can manage where the data is with the right click context menu on DB copies:



Choosing which, we have several options:



In an "available" scenario Lossless is the best choice.



We can see the status flip and copy queue stack in the other's favor.

In part two of this, I will add a third Exchange server at a DR location to add some DR planning and also show how this affects DAG network planning. In addition, I will hopefully dig in to more failure scenarios and how to address them. Keep in mind, like I said - this is a pretty basic DAG implementation, and no real planning of physical architecture lying underneath it.

Continue Part Two