Microsoft Exchange DAG: How it works
by Josefine.Fouarge, on May 11, 2015 3:43:09 PM
Lately NovaStor’s sales department has been getting asked a lot more about Exchange DAG support and if our backup software is able to backup and restore the Exchange in this configuration. That’s why I thought, I tell you a little bit about Exchange DAG itself, what it does and how NovaBACKUP DataCenter takes care about the DAG’s databases backup and restore.
What is an Exchange DAG (Data Availability Group)?
Referring to Microsoft, Exchange DAG is a high availability cluster for Exchange server. Since Exchange 2010 users are able to cluster up to 16 mailbox servers inside a single DAG. The Active Manager, the management tool for the DAG, replicates the mailbox databases and takes care about the failover and switchover mechanism.
How does it work?
The DAG replicates the mailbox databases between the mailbox servers. The more server are included, the more copies can be shared throughout the DAG group. As typical for a cluster, it also contains a heartbeat, cluster networks, and the cluster database.
The DAG group always has one active server. The rest is set on passive. That means, depending on the structure that is setup:
- The mailbox databases are spread across multiple DAG members --> that ensures that no two servers have the same mix of databases.
- The databases of the active server are replicated to the passive server --> direct copy of the active server
- The DAG replicates the data on a remote server --> also called site resilience, as it guarantees a ‘remote copy’ of the data
Does the active server need a software upgrade, the administrator can easily put the server in maintenance mode. The next passive server in line then becomes active. As the server does have all current databases, the switch causes no problem at all. The new active server continuous to replicate the mailbox databases to the rest of the passive servers. Is the administrator done with the maintenance, the old active server will request all changed databases and is able to continue his job.
But no matter which scenario is the one of your choice, they all have the same background operations running. These include the data and the transaction logs. Here are two ways of replicating both:
- All databases are replicated continuously. In addition the transaction log files are updated on every passive server afterwards. This is called a file mode replication and comes with some negative aspects. For example, if the active DAG server crashes while all data is already transferred, but the log files are not yet updated, the replicated data is worthless.
- The block mode replication writes the data to the log buffer on the active server and copies it to all passive servers in the DAG. These create their own transaction logs based on the buffer data. In case the active server is not reachable all passive servers have a current state of the data and the transaction logs.
There is one more feature running in the operation, the quorum. You actually don’t need to know how the quorum works, because Exchange takes care of it, but I think it’s pretty interesting. Imagine the quorum as a group of viewers that have access to the DAG members and resources. “Quorum is important to ensure consistency, to act as a tie-breaker to avoid partitioning, and to ensure cluster responsiveness.” But how does it ensure that the three tasks are fulfilled properly?
Ensuring consistency --> The quorum checks, if every member of the cluster is able to access the current state of the data and settings. In case a member is not able to load the ‘cluster hive’ the luster service won’t start. Thus, all DAG member have to meet the requirements at all times, otherwise they are not allowed to join the cluster.
Acting as a tie-breaker --> In DAG’s with an even number of members, the quorum needs an extra vote. This extra ‘ghost member’ is called a quorum witness resource. It is used to prevent data or availability inconsistencies based on a lost service, but still running cluster members. The first cluster member that is able to place a note inside the ‘Server Message Block’ on the witness server, will get an extra vote to keep quorum. All other members that are able to reach the witness server will get just one vote. Members who are not able to connect, loose quorum.
Ensuring responsiveness --> To run a DAG minimum two members are needed, the active server and a passive server that contains a copy of the data. In case there is just one member left, the DAG is not able to operate.
Why backup at all?
Why do I setup a HA cluster? To have my data available in a disaster, correct? Yes, but that doesn’t mean it is a backup of your data. The replication in a DAG cluster only delivers the last state of the database, no older snapshots. In case you have e.g. a virus on your system that is already replicated to the passive members, you would have to setup everything from scratch. Thus, a replication is not a backup!
Usually it is sufficient to back up the active DAG member. The active member contains all the important data and transaction logs to restore the database in case of failure or loss. But depending on your sense of security, you can back up all nodes, just every second one, or another pattern of your choice.
The database won’t be harmed, neither will the transaction logs. The management software in the background will take care that every transaction log is replicated to the passive members before deleting them.
And how does NovaStor DataCenter solve the issue? NovaStor DataCenter is DAG aware, and must be installed on each member of the group. When a backup of one of the databases starts NovaStor DataCenter will back up the DAG member that has that actively mounted database. Full backups along with log level backups are also possible, depending on how you have your logging in Exchange configured. NovaStor DataCenter’s Exchange item level recovery option will allow you to recover single mailboxes along with single pieces of email even when dealing with Exchange DAG configurations.
Some interesting websites about Exchange DAG (I also used those as sources for this article):
Information on Exchange DAG inside a VMware environment
If you haven't already, sign up to receive information about the technology behind NovaStor DataCenter, NovaStor's technology partners, Webinar invitations, and general network backup and restore knowledge.
Learn more about NovaStor DataCenter.