Because email is a mission-critical application, Microsoft has invested a lot of engineering talent as well as money over the years to provide Microsoft Exchange Server with the ability to resist different types of failure and deliver a highly available service. Exchange Server 2007 was a watershed for high availability in many ways because of the introduction of log replication technology in local continuous replication (LCR), cluster continuous replication (CCR), and standby continuous replication (SCR). Now Exchange Server 2010 takes a new approach to high availability by introducing the Database Availability Group (DAG), which is based on many of these same log replication techniques.
However, working with DAGs introduces new concepts, design challenges, and operational concerns that administrators have to understand before bringing a DAG into production. This article covers the underlying concept and explains Microsoft's motivation for the introduction of DAGs in Exchange 2010. A future article from Paul Robichaux will discuss how to build your first DAG.
High Availability Goals for Exchange 2010
Microsoft's first goal with the Exchange 2010 availability story was to improve on the Exchange 2007 high-availability features. The Exchange 2007 implementation is a little immature and overly complex. Having three different types of log replication is confusing, and the lack of automatic failovers and the lack of a GUI to control end-to-end operations from creation to failover are the hallmarks of a V1.0 implementation.
These limitations aside, the basic technology involved all works: copying transaction logs from a source to a target server, validating their content, then replaying that content to update passive copies of databases. Microsoft's decision to focus on continuous log replication as the basis for high availability in Exchange 2010 is understandable, and the developers have delivered a more manageable and complete solution. Exchange 2010 doesn't support LCR, CCR, and SCR, but as we'll see, the DAG is more than an adequate replacement.
Microsoft's second development goal was to include sufficient functionality in Exchange 2010 to let customers build highly available infrastructures without having to invest in expensive third-party add-on products. Although there's no doubt that third-party technology boasts its own set of useful availability features, especially when coupled with high-end storage systems, Microsoft has a large and diverse Exchange customer base, not all of which can afford to invest in the financial and administrative cost of deploying add-on technology. Having a solid set of high-availability features built in to the product and administered through the standard management interfaces—Exchange Management Console (EMC) and Exchange Management Shell (EMS)—increases the attractiveness of Exchange as a platform, removes complexity, and avoids cost for customers in the small-to-midsized business (SMB) segment as well as for a large number of enterprise customers.
Finally, Microsoft wanted to let customers deploy highly available servers in an incremental nature. In previous versions of Exchange, you have to do a considerable amount of preparation to deploy a highly available solution. For example, if you want to deploy clustered Exchange servers, you have to ensure that suitable hardware is available, then install a Windows cluster, then install Exchange with the correct switches to create virtual Exchange servers running on the cluster and connected to cluster resources such as shared storage. This process isn't something that you do without planning.
The concept of incremental deployment as implemented in Exchange 2010 is that you can deploy typical Exchange Mailbox servers first, then decide to include those servers in a DAG as the need arises to incorporate more high availability into the environment. You can also gradually expand the DAG to include more servers or more database copies to add resilience against different failure scenarios as time, money, and hardware allows.
Microsoft introduced storage groups as the basis for database management in Exchange 2000. Databases fitted inside storage groups, which belonged to servers. All the databases in a storage group shared a common set of transaction logs, and transactions from all the databases in the storage group were intermixed in the logs. Storage groups were sometimes convenient, but eventually Microsoft determined that they introduced an extra layer of complication for administrators, and the process to remove storage groups from the product began in Exchange 2007. It therefore comes as no surprise that storage groups disappear in Exchange 2010.
Defining a DAG
Fundamentally, a DAG is a collection of databases and database copies that are shared across as many as sixteen servers. The DAG differentiates between a primary database—the one that you originally create and users currently connect to—and the copies that you subsequently create on other servers. The DAG can swap the database copies into place to become the primary database following a failure of the primary database. The failure might be a complete server failure that renders all of the databases on the server inaccessible or a storage failure that affects just one database. In either case, the DAG is capable of detecting the failure and taking the necessary action to bring appropriate database copies online to restore service to users.
Servers within a DAG can support other roles, but each server must have the Mailbox role installed because it has to be able to host a mailbox database. Servers can also be on different subnets and span different Active Directory (AD) sites as long as sufficient bandwidth is available. Microsoft's recommendation is that all servers in a DAG share a network with a round-trip latency of 250 milliseconds or less. An Exchange 2010 server running the Enterprise edition can support as many as 50 active databases but the Standard edition is limited to 5 databases. When you include passive database copies that a server hosts for other servers, this number is increased to as many as 100 total databases on the Enterprise edition.
The introduction of the DAG smashes the link between a database and the owning server to make portable databases the basic building block for high availability in Exchange 2010. This development is probably the most fundamental architectural change Microsoft has made in Exchange 2010.
Windows Clustering
Underneath the hood, the DAG uses Windows failover cluster technology to manage server membership within the DAG, to monitor server heartbeats to know what servers in the DAG are healthy, and to maintain a quorum. The big differences here from clustering as implemented in other versions of Exchange are that there's no concept of an Exchange virtual machine or a clustered mailbox server, nor are there any cluster resources allocated to Exchange apart from an IP address and network name. Another important management difference is that you never need to manage cluster nodes, the network, or storage resources using the Windows cluster management tools because everything is managed through Exchange.
The dependency on Windows clustering means that you can add Mailbox servers to a DAG only if they're running on Exchange 2010 Enterprise Edition on Windows 2008 (SP2 or R2) Enterprise Edition. It also means that all of the DAG member servers must be part of the same domain. You should also run the same version of the OS on all the DAG member servers; you definitely can't mix Windows 2008 SP2 and Windows 2008 R2 within the same DAG and it makes good sense to keep all the servers in the organization at the same software level.
Previous
Register
