Database availability groups are more flexible than any other high availability options in Exchange 2007. Even so, I've seen many organizations use DAGs the same way they used cluster continuous replication. There's no doubt that DAGs are complex; still Exchange shops should use as many of their features to get the most out of them. Here's a look at three DAG features you should use.
Active database distribution
If you create a CCR cluster in Exchange 2007, it will contain both an active mailbox server and a passive mailbox server. Exchange uses databases on the active mailbox server, while the passive mailbox server acts as a standby, causing failover at the server level.
More on DAGS
Examining multisite database availability groups in Exchange 2010
DAGs work much differently. Instead of using active and passive servers, DAGs use active and passive databases, meaning failover occurs at the database level.
This means you don’t have to place all your active databases on the same mailbox server. You can distribute active databases across multiple mailbox servers so no single server needs to host all the databases. Distributing active databases across multiple servers allocates server workloads across multiple servers, resulting in better performance.
In a failure situation, a mailbox server may have to host more active databases than normal. So make sure each mailbox server has adequate hardware resources to accommodate a failure.
Exchange 2010 lets you place up to 16 mailbox servers within a DAG. Those mailbox servers don't need to exist within the same Active Directory (AD) site. They do, however, need to exist within the same Active Directory domain.
Having your mailbox servers in the same AD domain creates site resilience and lets you design a DAG to span multiple physical locations. It also gives you up-to-date copies of all of your Exchange Server databases on a server in another facility, protecting you from a data center crash.
Database replication and failover go a long way to prevent downtime, but they’re not enough. Suppose a user forwards a virus to every mailbox in your organization, for example. If several recipients open the virus, it can wreak havoc.
If a mailbox server is part of the DAG architecture you created to protect the mailbox database, the DAG will not provide any security. Infected messages will be replicated to the other database copies, just as an uninfected message would.
DAGs use a feature called replay lag to prevent such a widespread infection. If you don’t need all 16 mailbox servers in your DAG, you can move a few into the DAG and use them as lag servers.
Using replay lag, transaction logs are immediately replicated to the mailbox server, just as they would with any other server. However, transaction logs are not immediately replayed into the database. Therefore, if a virus destroys a mailbox database, you don’t have to restore a backup. You simply can eliminate any transaction logs on the infected lag servers and then replay the logs back to before the contamination occurred. This lets you roll the database back to a previous state without restoring a backup.
ABOUT THE AUTHOR:
Brien Posey is a seven-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.