Microsoft adds new features to every Exchange Server release. Some of these features are destined to be quietly ignored and eventually retired—remember the Exchange Network News Transfer Protocol (NNTP) server? Others go out in a quick blaze of glory, such as active/active clustering. Still others introduce fundamental changes in the way we design and deploy Exchange. Exchange 2010’s new database availability group (DAG) feature falls into that last category. The idea of providing mailbox resiliency by distributing multiple copies of mailbox databases throughout the Exchange organization is solid, and its implementation in Exchange 2010 marks a major change for high-availability designs.
Tony Redmond’s “Exchange 2010: High Availability with DAGs” (InstantDoc ID 102925) describes the technical fundamentals behind DAGs. If you’re not familiar with the basic underlying concepts, it’s worth a read before tackling this article, in which I’ll focus on how to deploy simple DAGs. But first, let's talk about prerequisites and other considerations.
DAG Prerequisites
The first, and biggest, prerequisite for DAG deployment is simple: You must be using Windows Server 2008 or 2008 R2 Enterprise Edition. If you have Standard Edition deployed, you won’t be able to place DAGs on that server unless you reinstall Windows. There’s no in-place upgrade from Standard to Enterprise. Unfortunately, that means that if you have a Standard Edition server that’s already running Exchange, that server can't be a DAG member server until you upgrade it. This predicament has affected many sites that have experimented with early deployments of Exchange 2010 on Server 2008 Standard, intending to upgrade their mailbox servers to DAG membership later.
From a network standpoint, DAG prerequisites are fairly straightforward. Exchange 2010 uses slightly different terminology from Exchange 2007. The MAPI network on a DAG member is for communicating with other Exchange servers and Active Directory (AD), whereas the replication network is for database replication traffic. In a significant change from Exchange 2007, Exchange 2010 now supports the use of a single network interface for both MAPI and replication networks, although the preferred design is still to use separate NICs and networks for those two functions. If the MAPI network interface fails, the server will fail its databases over to another DAG member. However, if the replication interface fails, replication traffic will silently move over to the MAPI network, reverting to the replication network when it becomes available again.
You can specify multiple replication networks, which is useful for complex topologies. However, every member of a given DAG must have the same number of networks defined. All members of a DAG should be able to communicate with no more than 250ms of network latency, but Microsoft warns that overall network performance is important, too—not just the latency measurements.
There are a couple more restrictions to keep in mind. All the members of a given DAG must be members of the same AD domain, although different DAGs can be members of different domains. And DAG names must be unique within the organization, and they must be 15 characters or fewer in length. (DAGs are the last remaining vestige of WINS remaining in Exchange. Perhaps the next version will get rid of them altogether.)