Database Availability Group Design Examples

The ability of a database availability group (DAG) to contain as many as 16 Mailbox servers, combined with the ability to extend a DAG across multiple physical locations and Active Directory sites, provides a large number of architectural design possibilities for DAGs.

You can use design examples for DAGs in a variety of environments:

• Two-member DAG, which is suited for small office and branch office deployments
• Four-member DAG that provides high availability within a single datacenter by locating all members in the same datacenter
• Four-member DAG that provides high availability within a single datacenter, and site resilience for that datacenter, by locating two of the members in the primary datacenter and two of the members in a second datacenter

The design you use for your DAGs and the distribution of mailbox database copies will be based on your organization's service level agreements (SLAs) and the recovery time objective and recovery point objective for the mailbox service and data as stated in those SLAs.

Looking for management tasks related to high availability and site resilience? See Managing High Availability and Site Resilience.

Contents

Two-Member DAG in Single Datacenter/Active Directory Site

Four-Member DAG in a Single Datacenter/Active Directory Site

Four-Member DAG in Two Datacenters/Active Directory Sites

Two-Member DAG in Single Datacenter/Active Directory Site

A two-member DAG is the smallest possible DAG that can provide high availability. Two-member DAGs are best suited for organizations that require some form of high availability for mailbox services and data, but that don't require site resilience. This configuration works especially well in small office and branch office deployments because it enables redundancy for the Client Access, Mailbox, and Hub Transport server roles using only two Exchange servers. The following figure illustrates this configuration.

Two-member database availability group

There are several aspects worth noting about this configuration:

• In this design, only the Client Access, Mailbox, and Hub Transport server roles are co-located. Although it's supported to co-locate the Unified Messaging server role, that configuration isn't recommended for performance reasons.
• To achieve high availability for Client Access and Hub Transport server roles, some form of load balancing should be used between the clients and those server roles. Because these server roles are co-located with a Mailbox server that's a member of a DAG, Windows Network Load Balancing (NLB) can't be used (because NLB and Windows failover clustering can't be installed on the same server). Instead, a non-Windows NLB solution must be used (for example, a hardware load balancer or a third-party software-based load balancer).
• As with all DAGs that contain an even number of members, a two-member DAG requires a witness server to maintain quorum. The witness server (not pictured) is a Windows server that isn't and will never be a member of the DAG. Quorum is maintained as long as more than half of the quorum voters are available and in communication. A two-member DAG with a witness server provides three quorum voters (each DAG member and the witness can vote whenever they are available and in communication). Therefore, a two-member DAG can survive the failure or outage of a single voter (for example, either of the DAG members, or just the witness server) without an interruption in service. However, the loss of two of the voters (for example, a DAG member and the witness server), will result in a loss of quorum, which will result in an interruption in service.

Return to top

Four-Member DAG in a Single Datacenter/Active Directory Site

A four-member DAG in a single datacenter deployment provides greater resilience to failures than a two-member or three-member DAG. Larger DAGs inherently provide greater resilience because they can sustain more failures without an interruption in service. Whereas a two-member or three-member DAG can sustain the loss of only a single voter without losing quorum and compromising service, a four-member DAG, which by definition has five quorum voters, can sustain the loss of two voters without losing quorum and compromising service.

The following figure illustrates a four-member DAG with all members located in a single datacenter.

Four-member database availability group

Using a four-member DAG, you can create a maximum of four copies of each database. This is a sufficient number of database copies to enable the use of alternate data protection scenarios, such as flexible mailbox protection. Flexible mailbox protection enables you to combine the Exchange 2010 high availability and Extensible Storage Engine (ESE) resilience features with other built-in protection features, such as lagged mailbox database copies, retention policies, the Recoverable Items folder, and the hold policy, to create a solution that can reduce the need for other forms of protection, such as using Redundant Array of Independent Disks (RAID) or making data backups. For more information about flexible mailbox protection, see Understanding Backup, Restore and Disaster Recovery. For more information about using replication for your backups and using just a bunch of disks (JBOD), see Mailbox Server Storage Design.

Return to top

Four-Member DAG in Two Datacenters/Active Directory Sites

A four-member DAG extended across two datacenters provides both datacenters high availability and site resilience for the mailbox services and data. This configuration is illustrated in the following figure.

Four-member database availability group extended across two sites

There are several aspects worth noting about this configuration:

• The witness server for the DAG should be located in the primary datacenter. Generally, the primary datacenter is the datacenter containing the majority of the user population. Using a witness server in the primary datacenter enables continued functionality for the majority of the user population in the event of a wide area network (WAN) outage.
• There is no direct routing that allows heartbeat traffic from the replication network on one DAG member server to the MAPI network on another DAG member server, or the reverse, or between multiple replication networks in the DAG.
• In this example, the Exchange server roles are deployed on dedicated hardware. Because the Client Access and Hub Transport server roles aren't co-located with the Mailbox server in the DAG, Windows NLB is used to load balance the Client Access and Hub Transport server roles.

Return to top