Exchange 2010 Database Mobility

In today's post I'm going to write about Exchange 2010 Database Mobility and the changes that have been made to the mailbox server role.

If you have been following exchange, you will remember with the coming of Exchange 2007 Administrative Groups are GONE and the administrative delegation structure has been vastly changed as a result of this. One thing still remained, the existance of Storage Groups which in my opinion was stupid because of the following reason. Exchange 2007 standard lets you have 5 storage groups and 5 mailbox databases per server. Exchange 2007 enterprise let you have 50 storage groups and 50 mailbox databases per server. Microsoft's best practice was to always place each mailbox database in its own storage group as transaction logs are setup on a storage group basis and when doing a restore you want the logs to be associated with just that one database your restoring (not all databases). So whats the point of keeping storage groups? Now in Exchange 2010 Microsoft has finally completely got rid of storage groups.

Another big change is that mailbox databases are now seen as an organisational object and no longer a server object. This means mailbox database settings can be found under organisational configuration and no longer server configuration under exchange management console. The reason behind this lies with Microsoft's new high availability with mailbox databases in Exchange 2010 with the use of DAG's (Database Availability Groups). Also on this note, because mailbox databases are at an organisational level now, database names must be unique. You can no longer have multiple servers with the same mailbox database called "Mailbox Database" or something generic. This is something I wanted for a while because when your in a large organisation and you use Get-MailboxDatabase its very annoying when every mailbox database that is returned is called the same thing!

What are Database Availability Groups?

Database Availability Groups are groups of database servers. It is essentially a boundary for mailbox database replication. You can have up to 16 servers per DAG, but you can create multiple DAGs in your exchange organisation. What DAGs let you do is have a mailbox database on multiple servers. I made a diagram below to help explain this. Below is a DAG called My Mailbox Servers.



With DAGs a mailbox database can only be active on one server at a time - the way its always been with Exchange High Availability. The rest of the database copies are marked as healthy (hopefully). Inside a DAG you can distribute a mailbox database out to whichever servers you want. A DAG is not constrained to a physical site, they can replicate databases over site links for offsite redundency. Depending on business needs you choose which database will reside on what servers. Only one database will be active at a given time however having multiple copies of the database is fantastic. A database is able to reside on all servers if you wish (maybe the executive's database) - or if you want all databases can reside on all servers. One thing to keep in mind is the more servers a database resides on the more replication traffic will occur and the more storage you will require. In the above diagram I have DB6 available on all three mailbox database servers.

Failover time is about as fast as CCR (Continious Cluster Repliation) was in Exchange 2007 (approximately 30 seconds) - but still very fast. Users logged into outlook web access will not even notice a failover occured as they maintain their connection to the client access server while the client access server in the backend changes which mailbox server its communicating with for that given mailbox user. For outlook clients a simple bounce of the outlook client will bring them back up and running. No mail is lost during failovers and failovers can occur during business hours with no impact on business productivity.

Another fantastic thing about DAG's is you can incrementally add servers. Before in Exchange 2003/2007 high availability mailbox clusters had to be setup using the cluster administrator MMC and all the cluster resources such as the hostname, IP address etc all had to be created before hand. Once the cluster was setup, you would then install Exchange in cluster mode for the mailbox role. When a mailbox server was in place, you could not simply convert it into a cluster setup. This is because a clustered mailbox server was a special setup! With Exchange 2010 DAG's you can simply add a stand alone mailbox server into a DAG then specify which mailbox databases are going to be replicated to which servers giving administrators huge amounts of flexability.

Exchange 2007 CCR used SMB (Simple Message Block) to replicate transaction logs between mailbox servers. With Exchange 2010 DAGs SMB is no longer used. Exchange 2010 uses its own TCP/IP socket to replicate logs between servers inside a DAG. Administrators can set which port is going to be used for log replication between servers using powershell along with things like data encryption for repliation traffic.

With Exchange 2007 as soon as a mailbox server became a high availability mailbox server in either a SCC or CCR cluster, you could no longer have any other roles on it. ie - you could not have a clustered mailbox server that was also running a hub transport role. With DAG's you can now have mailbox servers that are also hub transport or client access etc. A great thing about this is you can setup a simple whitebox with RAID5 for a branch office so users can access their mailbox over highspeed LAN. Wack all the exchange roles on the single box, configure the exchange server to be part of your DAG and repliate the branch offices mailbox databases back to your corporate headquaters and back it up there - meaning no backup is required onsite. You could even make this single whitebox server a DC if you wish with DFS-R on important file shares. If this whitebox was to fail then failover would occur and users would continue working just accessing their mailbox accross the WAN link instead of highspeed local access (which in most cases is perfectly fine).

The great thing about DAG's is failover is completely automatic. If one database server completely dies - provided all mailbox databases on that server exist on at least one other server you won't even need to get out of your chair. Automatic failover will occur and users will continue working as normal.

What do DAGs Require?

Database Availability Groups still Windows Cluster Services. You need to ensure that the "Windows Failover Clustering" Feature in the features pane under server 2008 server management is installed. When you create a new DAG and add the first server to the DAG the following is automatically setup:
- A failover cluster is automatically created in the background with a majority node quorum using the name you specified for the DAG as the cluster name.
- The mailbox server gets added to the DAG object in the Active Directory Database.
- A clustered network computer account is automatically created in the computers built-in container in Active Directory.
- An IP Address is assigned to the DAG using DHCP (but you can manually specify this after to be a static address or use a DHCP reservation).
- The name and IP address of the cluster gets registered in DNS.
- The cluster information for the DAG.. ie the Quorum is updated with current mounted databases on the mailbox servers.

For each additional server that gets added to the DAG from here the following things occur:
- The server is added to the DAG object in Active Directory
- The cluster database is updated with mounted mailbox databases on the mailbox server.
- The Quorum model is automatically ajusted.

All this clustering stuff is done for you automatically, creating a DAG is simply a process of giving it a name, and clicking create. You then add which servers are going to be a member of the DAG. In previous versions of exchange you had to configure all this manually in cluster administrator. I can see this leading to exchange clustering being used widely by many organisations but administrators not understanding the fundimental knowledge of how a windows cluster works! All may be fine but when problems arise with out this knowledge it could lead to large amounts of downtime.

As I mensioned above the ability to incrementally add servers to a DAG is fantastic without having to rebuild the cluster each time you want to make changes but what is also really good is Exchange 2010 automatically updates the quorum model. If you have an odd number of nodes in the DAG at a given time it will set it to a majority quorum model. However if you then go add another node and have an even number a file witness share will be required. All you need to do is provide it with a sharename and Exchange 2010 automatically changes the cluster configuration between file share quorum's and majority quorum's for you.