I recently wrote a five part series about Exchange Server 2007 high availability, describing each of the HA features (LCR, SCC, CCR, and SCR) in detail and demonstrating their uses, strengths and weaknesses.

With the release of Exchange Server 2010 these high availability features are no longer available.  The features have now been replaced by a single high availability option known as Database Availability Groups (or DAGs for short, admittedly a horrible acronym for what is truly the product’s finest feature).

A little background is required to fully understand the evolution of Exchange storage architecture to its current incarnation in DAGs.  Going back to Exchange Server 2003 the product was limited to a maximum of 4 Storage Groups, each containing a maximum of 5 databases.  This meant a maximum of 20 databases (of either Mailbox or Public Folder type) per Exchange server.

Exchange Server 2007 improved on this in two ways.  Firstly, the product was limited to 5 Storage Groups and 5 databases for the Standard Edition, and up to 50 Storage Groups and databases for the Enterprise Edition.  The best practice with Exchange Server 2007 was to use one Storage Group per database, unlike Exchange Server 2003.

Naturally this lead to the question of why have Storage Groups at all?  Exchange Server 2010 answers this question by doing away with the concept of Storage Groups entirely.  Databases are now Organization-level objects that contain both the transaction logs and the database itself.

Exchange Server 2010 then introduces the Database Availability Group to provide high availability.  A DAG is a group of Mailbox Servers (up to 16 per DAG) that replicate databases and perform automatic failover and recovery for either individual database or entire server failures.

So how does this compare to Exchange Server 2007 high availability?  An immediate advantage is that DAGs unify Exchange high availability into a single feature and management toolset, unlike Exchange Server 2007 which had 4 different features each managed with different tools.

Let’s take a more detailed look at each of the features to see how they compare to DAGs.Firstly, Local Continuous Replication (LCR) was ultimately a pretty useless feature.  LCR protected from failure of a single database by replicating it to other local disk storage.  Most servers already use some form of RAID or highly available storage such as SAN, so protecting from storage failures was usually not necessary.  LCR was also cumbersome to activate in a failure scenario.  In comparison, DAGs offer more useful replication of databases to an entirely different server which can also be located at a different site, offering both host and site resilience.  The failover is also automatic.

The two cluster models, Single Copy Cluster (SCC) and Cluster Continuous Replication (CCR) also carried some limitations.  Failover occurred at the server level instead of the database level, so the failure of a single database for any reason caused all of the databases to failover to the passive cluster node.  DAGs on the other hand offer database-level failover.  Exchange Server 2007 also required that an underlying failover cluster be configured first.  Exchange Server 2010 configures the underlying cluster automatically when the first server is added to a DAG, allowing what is called incremental deployment (ie, you can make any Mailbox Server a member of a DAG without having to rebuild it as a cluster first).

Standby Continuous Replication (SCR), which did offer site resilience for Exchange Server 2007, was cumbersome to deploy, manage, and activate in the event of a disaster.  Failover to the passive replica was not automatic and required manual intervention.  It also required manual modification of user mailbox attributes using scripts.  Again DAGs provided automated failover, but in addition to this the redirection of user Outlook clients occurs automatically.

Finally one of the most attractive features of Exchange Server 2010 high availability is that it does not require that other server roles be located to separate servers.  Exchange Server 2007 cluster nodes were Mailbox Servers only and could not also be Client Access or Hub Transport servers.  Exchange Server 2010 allows these roles to stay on the Mailbox Server even when it becomes a member of a DAG.  This greatly lowers the hardware and software costs of deploying a highly available Exchange environment.

Overall the Database Availability Group is one of the killer features of Exchange Server 2010 and is sure to be a popular deployment option for Exchange Server users.