• Insights

The Evolution of Exchange High Availability and Site Resiliency: Exchange 2010 Database Availability Groups

Joseph Hoegler

2 min read

All Insights

High availability and site resiliency have evolved a great deal from early versions of Exchange through Exchange 2007.  While Exchange 2007 introduced the concepts of Single Copy Clustering (SCC) and Cluster Continuous Replication (CCR) for high availability and Standby Continuous Replication (SCR) for site resiliency, each had very specific benefits and drawbacks.  CCR gradually became Microsoft’s and the industry’s preferred solution for high availability because of its robust availability capabilities but concerns about manageability, scalability, and associated storage cost were all factors when settling on a design.  SCR extended CCR technology to provide a robust and cost effective solution for site resiliency but many firms were frustrated by the configuration and database activation processes and that all administration must be completed via cmdlets.

Fortunately, Microsoft built upon the technologies introduced in Exchange 2007 and improved many of the drawbacks with features introduced in Exchange 2010.  SCC functionality has been completely deprecated and CCR/SCR/LCR have been combined and evolved into the concept of the Database Availability Group (DAG).  DAGs combine high availability and site resilience into a single technology and management point to dramatically improve configuration, management, and scalability.  In addition, while a DAG does leverage some basic elements of Windows Failover Clustering, these are merely done for membership management, heartbeat, and information distribution amongst DAG members.  At its core, Exchange 2010 is essentially no longer a cluster-aware application and the concept of the CMS has been removed.  Instead, as enabled by the new requirement that all clients connect through CAS role (see my blog post here), the Mailbox server on which a user’s database exists no longer matters and can be easily adjusted based on server availability.

A DAG is essentially a group of Mailbox servers between which an administrator wants the ability to replicate mailbox databases.  A DAG can contain up to 16 Mailbox servers across multiple sites (each with their own copy of replicated databases) and, once servers are a member of a DAG, the administrator can choose how many copies of a specific database is desired, where those copies should be stored, and how far behind (if at all) replication should lag between copies.  The administrator can also define an activation preference such that, if the server hosting the active copy of a database or the database itself fails, Exchange will attempt to bring other copies online in a specific order.

Please refer to the table below for a brief comparison of features between the high availability capabilities of SCC, CCR, and DAG.  A few additional key points to note are that high availability failovers can occur for individual databases (as opposed to whole servers in Exchange 2007), DAG management is facilitated entirely by Exchange tools, and other roles can now be hosted on the same server as the Mailbox role when configured as a DAG member.

High Availability Comparison between Exchange 2007 and Exchange 2010

 

Feature

 

SCC (2007)

 

CCR (2007)

 

DAG (2010)

 

Failover Granularity

 

Server-level

 

Server-level

 

Database-level

 

Max Copies of Data

 

1

 

2

 

2 to 16

 

Failover time

 

~2 min

 

~2 min

 

~30 sec (estimated)

 

Failover Mgmt

 

Windows Cluster

 

Windows Cluster

 

Exchange Server

 

Data Replication

 

Partner Replication or SCR

 

Continuous Replication

 

Continuous Replication

 

Management Tools

 

Separate

 

Separate

 

Unified

 

Host other roles?

 

No

 

No

 

Yes

There is much more to talk about with DAGs and I plan to post more information about them in the future.