Understanding Database Availability Group(DAG) in Exchange 2010MustBeGeek

Spread the love

Mailbox databases and the data they contain are most critical components of an. Exchange organization. In Microsoft Exchange Server 2010, you can protect mailbox databases and the information they contain by designing your mailbox databases for high availability. Exchange 2010 lessens the cost and complexity of deploying exceptionally available and service resilient messaging platform. This article will focus on Understanding Database Availability Group(DAG) in Exchange 2010.

Understanding Database Availability Group(DAG) in Exchange 2010

Database Availability Groups(DAGs) in Exchange 2010 is data redundancy, high availability and disaster recovery feature. Adding Multiple mailbox servers to the DAG and replicating all mailbox databases with other member servers provides automatic failover recovery at the database level. You will need just two Mailbox Server to start with the high-availability features of Exchange 2010. The database switch-over time is less than 30 seconds which will significantly improve the overall up-time. Any server in the DAG can host a copy of a mailbox database from any other server in the DAG.

Following are the End-to-End Availability Features of Exchange 2010

Shadow Redundancy – provides redundancy for messages for the entire time they are in transit. The solution involves a technique like the transport dumpster.
Online Move Mailbox – Exchange 2010 includes a new feature that enables you to move mailboxes asynchronously.
Flexible Mailbox Protection – The ability to have multiple copies of a database hosted on multiple servers means that if you have a sufficient number of database copies, you can use these copies as your backup.
Incremental Resync – feature that automatically corrects divergences in database copies.
Third-Party Replication API – Third-party replication API that enables organizations to use third-party synchronous replication solutions instead of the built-in continuous replication feature

Incremental Deployment, Backup and Redundancy:

DAGs uses the concept of incremental deployment, which allows you to deploy service and data availability for all Mailbox servers and databases. After you deploy Exchange 201o Mailbox servers, you can create a DAG, add Mailbox servers to the. DAG, and then replicate mailbox databases between the DAG member servers.

A DAG is initially creates as an empty object in Active Directory. This directory object is used to store relevant information about the. DAG, such as server membership information and some DAG configuration settings. Adding a server to DAG will also create a failover cluster automatically for the DAG. By default, DAG will use the built-in continuous replication feature to replicate mailbox databases among servers in the DAG.

After creating the DAG, you can add the mailbox servers to the DAG. When the first server is added to the DAG, a cluster is formed for use by the DAG. DAGs make use of Windows failover clustering such as the cluster heartbeat, cluster networks, and the cluster database. As each subsequent server is added to the DAG, it’s joined to the underlying cluster, Exchange adjusts the cluster’s quorum model automatically, and the server is added to the DAG object in Active Directory.

Active Manager :

Active manager is a role that runs on a mailbox server. A single active manager role “Standalone. Active Manager” which runs on a mailbox server that has no high-availability. Two active manager roles will be in use when the mailbox server is a member of a DAG; Primary Active Manager (PAM) and Standby Active Manager (SAM). The SAM provides information on which server hosts the active copy of a mailbox database to other components of Exchange that are running an Active Manager client component (for example, RPC Client Access service or Hub Transport server).

The SAM detects failures of local databases and the local Information Store. It reacts to failures by asking the PAM to initiate a failover. A SAM does not determine the target of failover, nor does it update a database’s location state in the PAM. PAM is the Active Manager in a DAG that decides which database copies will be active and passive. PAM is responsible for getting topology change notifications and reacting to server failures.

Quorum in Database availability group (DAG) :

Failover Clusters use the concept of quorum, which uses a consensus of voters to ensure that only one subset of the cluster members is functioning at one time. Quorum is important to ensure consistency, to act as a tie-breaker to avoid partitioning, and to ensure cluster responsiveness. DAGs with an even number of members use the failover cluster’s Node and File Share Majority quorum mode, which employs an external witness server that acts as a tie-breaker. This will also avoid the Split-Brain Syndrome in which the DAG members believes they own the same resource and they are authoritative of that resource. The witness server must be external to the mailbox database servers that are the members of a DAG.

How it works?

Following is an illustration on how DAG can provide High Availability on the mailbox database. In the following scenario I have four member DAG, each member holding two database copies from other member servers.

Now, assume that there was a catastrophic hardware failure on MBX01, now the system will automatically activate the copy of DB1 hosted on MBX02. To learn about how the system will decide which database to activate and to understand the role of active manager read the article Understanding the Role of Active Manager in Exchange 2010. Following diagram illustrates the scenario.

When you recover the server MBX01 from hardware failure, the databases will updates itself with the the copy of respective active mailboxes.

Once all the databases are healthy, you can switch the active database as it was earlier. In my scenario, this DAG will function with all four online databases even if are two servers are offline.

Using DAG for Site Resilience:

Apart from providing high-availability with in a Active Directory Site or Datacenter, you can also extend the DAG to one or more datacenter and configure them such that it provides Site Resilience with one or more data centers. You can use the incremental deployment to extend the DAG to a secondary datacenter. You must also deploy necessary supporting resources like an Active Directory server and a DNS server. Below is the representation of this scenario.

Less complex site resilience, just by expanding the DAG to multiple physical locations. The transition between the primary datacenter and a stand-by datacenter in case of disaster in the primary datacenter is seamless and do not require any additional instructions for the end users, separate set of credentials or URLs. DAG is configured on a mailbox server role with maximum of 16 Exchange 2010 Servers.

Key Points to remember when working with DAGs in Exchange 2010:

Each Server with mailbox role must have two network interfaces, one for DAG replication and another is for MAPI traffic
There are only up to 16 database copies per DAG
Unlike Exchange 2007, Mailbox Servers can also be configured with other Exchange 2010 Roles.
Each Databases will have its own transaction logs
DAG can be utilized to use less than 50% of I/O on Direct attached storage.
Logs shipping is done using distinct TCP sockets for each Database.
Creating a new Database Availability Group will also install failover clustering.