The high availability feature for Exchange Server 2013 Mailbox servers is the Database Availability Group.
Exchange 2013 Database Availability Groups (DAGs) are very similar to Exchange 2010 DAGs, but also deliver a series of improvements and new features for customers.
In this series of articles we will walk through an overview of Database Availability Group concepts, demonstrate how to deploy a new Database Availability Group, and explore some of the operational tasks associated with running and maintaining a DAG.
Overview of Exchange Server 2013 Database Availability Groups
A Database Availability Group consists of up to 16 Exchange 2013 Mailbox servers, and optionally one or more additional non-Exchange servers that may be required to act as a File Share Witness (more on this shortly).
The Mailbox servers within a DAG are capable of hosting a copy of a mailbox database from another DAG member; up to the Exchange 2013 limit of 50 mailbox databases per server (that includes both active and passive database copies).
A simple example of a Database Availability Group would be as follows.
In the example above the server EXMB1 hosts the active copy of database DB1, and the other DAG members EXMB2 and EXMB3 host passive copies of the database.
The DAG members work together to maintain the availability of the mailbox database. If the server that hosts the active database copy experiences a problem, for example a hardware failure, one of the remaining DAG members is able (under the right conditions) to make it’s copy of the database active so clients are still able to connect to their mailbox data.
A Mailbox server that is a member of a DAG can host a mixture of active and passive database copies for which it participates in replication. Whether a given database is active or passive on a particular DAG member is independent of the active/passive status of other databases that are also hosted on that DAG member.
In the above example a DAG with three members and three mailbox databases is shown with the active database copies evenly distributed across the available DAG members.
Continuous Replication in Exchange Server 2013 Database Availability Groups
Each DAG member hosting a copy of a given mailbox database participates in a process of continuous replication to keep the copies consistent.
Database replication occurs between Exchange Server 2013 DAG members using two different methods:
File Mode replication – each transaction log is fully written (a 1MB log file) and then then copied from the DAG member hosting the active database copy to each DAG member that host a passive database copy of that database. The other DAG members then replay the transaction log file into their own passive copy of the database to update it.
File mode replication has an obvious downside in that a transaction log that hasn’t already been copied to the other DAG members may be lost if the DAG member hosting the active database copy becomes unavailable. Although there are other recovery mechanisms to minimise the impact of this scenario, this is a reason why file mode replication is used only during the initial seeding of a database copy.
After seeding is complete the database switches automatically to block mode replication.
Block mode replication – as each database transaction is written to the log buffer on the active server and also sent to the log buffer of DAG members hosting passive copies of the database. As the log buffer becomes full member of the DAG is then able to build their own transaction log file for replay into their passive database copy.
Block mode replication has advantages compared to file mode replication when there is a failure in the DAG, because less transaction log data is likely to be lost.
Quorum for Exchange Server 2013 Database Availability Groups
An Exchange 2013 DAG utilizes Windows Failover Clustering and the quorum model. This underlying cluster is managed automatically for you by Exchange, so you don’t need to worry about it much other than to be aware of how quorum works.
If the concept of quorum is new to you just think of it as a voting process in which a majority of voting members must be present to make a decision. The decision in the case of a DAG is basically whether the DAG should be online of offline.
Because a majority of votes is required for quorum there are two different quorum models used depending on how many DAG members you have.
For a DAG with an odd number of members the Node Majority quorum mode is used.
In the above example a three member DAG is able to maintain quorum during a single server failure, but quorum is lost when two servers are unavailable.
For a DAG with an even number of members the Node and File Share Majority quorum mode is used. This mode involves an additional server referred to as the File Share Witness. It is typically another Exchange server located in the same site as the DAG members.
In the above example a four member DAG is using an additional server as the File Share Witness (FSW). The DAG is able to maintain quorum with up to two server failures, but quorum is lost when three servers are down.
Database Availability Networks
A DAG network refers to a collection of one or more IP subnets that the DAG members are connected to and are used for client and replication traffic.
Every DAG has one network for client traffic, and then it can also optionally have a number of networks dedicated to replication traffic.
Dedicated replication networks can help reduce bandwidth utilization on the client-facing network which may prevent network-related performance issues for the clients.
High Availability and Site Resilience
Exchange Server 2013 Database Availability Groups can be deployed to provide both high availability and site resilience.
A DAG deployed for high availability will typically exist within a single Active Directory Site, or datacenter.
A DAG deployed for site resilience will span multiple datacenters. The objectives of a Database Availability Group deployed for site resilience are usually to provide availability of mailbox services after the complete failure of the primary datacenter. In other words, a true disaster.
As such there are a lot more technical and business considerations for a site resilient Database Availability Group. There is also less automation and more administrator attention required for a full site failover scenario.
For the purposes of this article series we’ll be focusing on Database Availability Groups deployed within a single datacenter for high availability.