Creating a Database Availability Group in Exchange 2010 – Part 4



In part 3 of this series, we configured the replication networks for the DAG, as well as add database copies to the DAG.  In Part 4, the final part of this series, I’ll show you how to move the active copy between different servers, and how this affect’s the end user. 

Remember way back in Part 1 of this series, I mentioned that Outlook client’s now connect to a Client Access Server to connect to their respective mailbox’s, instead of connecting directly to the Mailbox server?  We’ll, part of the reason why, is that in Exchange 2010, Microsoft wanted the failovers to be less than 30 second’s, no matter what.  By moving the Outlook client to connect to the CAS server’s, you can meet this threshold.  Client Access Server’s are notified about a database move, and thus can redirect their client’s accordingly.

Take our user, Paul A. Ponzeka, who’s mailbox is is located on the Accounting database we created in part 3.  The active copy of the database is on NYDAGNODE1. 

32 Jul. 06 20.10

When we create his profile in Outlook, look at the server he connects to:

33 Jul. 06 20.13

34 Jul. 06 20.13

Notice how the Outlook client connects to the CAS server, and not the mailbox server, which in this case would be NYDAGNODE1.  Everything, except public folder connections, are proxies through a CAS server.

Okay, so now let’s move the active copy to the London server, LNDAGNODE1. We can do this through the console, or the shell.  In the console, navigate to Organization Configuration –>Mailbox->Database Management.  Simply right click on the database in question, and select “Move Active Mailbox Database”.  Fill out the menu, with which server you want to move it to.  The override mount dial allows you to specify an override for the amount of data loss your willing to accept.  We don’t have a need to change this, so just leave it be and hit move:

35 Jul. 06 20.17

So now the system will move the database, and if you note, in our example, it took 6 seconds, also note the command shell you could have run to get the same effect:

36 Jul. 06 20.17

Now the accounting database will go to Mounted on LNDAGNODE1 and healthy under copy status on NYDAGNODE1:

37 Jul. 06 20.19

There you go, all set!  Again, the threshold will be 30 seconds according to Microsoft for the failovers!

So in wrapping, I wanted to touch on a couple of the core differences between Exchange 2010 DAG’s, and CCR clusters, both normal and stretched.

First, in 2007 CCR clusters, when you perform the initial seeding, you need to have every transaction log for that particular storage group, otherwise seeding will fail.  This is no longer true with 2010.  You can add a DAG at ANY POINT.  Second, in 2007, once you moved the active copy to the passive node, you had to re-seed the previously active copy from the passive node before that node could ever be brought back on line.  This is again no longer true in 2010.  You can move back and forth without reseeding.

Third, CCR’s were limited to just 2 nodes, you are limited to 16 members of a DAG in 2010!  In 2007, even if you were doing a stretched cluster with 2008, both nodes had to be members of the same AD site.  This had to do with the nodes having to speak to the same set of Hub Transport servers to avoid data loss.  With 2010 and the inclusion of the new Shadow Transport feature, this is not needed.  So you can have any number of DAG members, in any number of different AD sites.  The outlook client’s will just be redirected to a CAS server in the local site of the now active mailbox server copy, again in under 30 seconds!

Another huge difference, is that since the database’s are no longer members of the servers, the failovers are on a per database level.  What this means is if a server in NY, has three databases, and all of them are active, and you have a situation where only one of the database’s go offline, only that database will be activated on another copy in the DAG, leaving the previous two untouched!

In this four part series, we went over the theory of the Database Availability Group feature of Exchange 2010, as well as how to configure and test the DAG.  Overall, it is a great improvement for both the High Availability, and Site Resiliency model for Exchange.