Forget everything you've ever learned about Exchange Server high availability. Exchange Server 2010 changes it all. In Exchange Server 2010, Microsoft replaced local cluster replication, continuous cluster replication and standby continuous replication with a feature called database availability groups (DAG). And with DAGs comes another major architectural change that you need to be aware of.
In Exchange Server 2007, the client access server acted as the entry point for Outlook Web Access (OWA) and ActiveSync traffic, but Outlook bypassed the client access server and established a MAPI session directly with the mailbox server. This behavior has changed in Exchange Server 2010. All client sessions -- including MAPI -- now pass through the CAS, which then proxies the request to the mailbox server.
This new architecture greatly reduces the amount of time it takes mailbox server failover to occur because mailbox servers no longer rely on client connections. The CAS seamlessly redirects client requests to the appropriate mailbox server.
According to Microsoft, failover from one mailbox server to another has been reduced to less than 30 seconds in Exchange Server 2010. Under ideal conditions, a failover in Exchange Server 2007 took about two minutes to complete.
Database availability groups
In Exchange Server 2007, failover happened at the clustered mailbox server level. This was often problematic for clustered
This caused an interruption of service for users whose mailboxes weren't on the failed database. In Exchange Server 2010, however, Microsoft has taken a database-centric view of clustering. Because the server is designed to failover at the database level, databases that aren't affected by the failure aren't required to failover.
Since Exchange Server 2007 clustered mailbox servers failover at the server level, many organizations limit each clustered mailbox server so that it hosts a single Exchange Server database. Since CCR requires clustered mailbox servers to work in active/passive server pairs, server hardware often was not used to its full capacity.
DAGs do away with these limitations. In fact, in database availability groups, multiple databases per mailbox server are not only permissible, they are expected. Database availability groups can also contain up to 16 mailbox servers, and each of which can contain multiple databases.
Not every server replicates its databases to every other server in the group though. Instead, you can pick and choose which replicas reside in which mailbox servers within the DAG. You don't need a single server to host multiple high-demand databases.
Another thing that makes database availability groups different from cluster continuous replication is that there are no longer active and passive nodes. Each server within the DAG may contain a mixture of active and passive databases.
Database availability groups can also be configured to span multiple subnets. By doing so, you can have servers in local and remote data centers. If you use this approach to create a disaster recovery data center, you'll need a CAS in each data center since the CAS proxies user requests to mailbox servers.
ABOUT THE AUTHOR:
Brien M. Posey, MCSE, is a seven-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
This was first published in April 2010