A database availability group (DAG), together with mailbox database copies, can provide automatic recovery from a variety of server, storage, network and other hardware failures. A DAG can also provide a site resilience solution so that you can perform a datacenter switchover in the event of a site-level disaster. But even a comprehensive, intelligent, and robust solution such as a DAG can't protect you from all possible disasters, including disasters that affect an entire DAG. For example, consider a two-member DAG deployed in a single datacenter. If the datacenter experiences a flood, fire, or other cataclysmic event that destroys the DAG, the entire DAG will need to be rebuilt from scratch. How do you do that?
A few days ago, we published a new feature article on TechNet, by Tim McMichael, titled Rebuild an Entire Database Availability Group. In this article, Tim describes how to rebuild a DAG that has been completely lost. He walks you through the entire process, step-by-step, including examples along with way. For details, check out this excellent article.
We also published some updated guidance around required network latency between Mailbox servers that are members of a DAG. Our old guidance was as follows:
Regardless of their geographic location relative to other DAG members, each member of the DAG must have round trip network latency no greater than 250 milliseconds (ms) between each other member.
Our new guidance is now:
Regardless of their geographic location relative to other DAG members, each member of the DAG must have round trip network latency no greater than 500 milliseconds (ms) between each other member. As the round trip latency between two mailbox servers hosting copies of a database increases, the potential for replication being not up-to-date also increases. Regardless of the latency of the solution, customers should validate that the network(s) between all DAG members is capable of satisfying the data protection and availability goals of the deployment. Configurations with higher latency values may require special tuning of DAG, replication and network parameters, such as increasing the number of databases or decreasing the number of mailboxes per database, to achieve the desired goals.
And of course, as we stated previously and continue to state, round trip latency requirements may not be the most stringent network bandwidth and latency requirement for a multi-datacenter configuration. You must evaluate the total network load, which includes client access, Active Directory, transport, continuous replication, and other application traffic, to determine the necessary network requirements for your environment.
DAGs and Bitlocker Drive Encryption
There is another support change that we made recently (although the documentation has not been updated because the support change occurred after this last document refresh) with respect to using Bitlocker on DAG members. Our old guidance (which will remain on TechNet until our next document refresh, even though the new guidance now applies) was as follows:
Windows failover clusters can't have BitLocker enabled.
Our new guidance (and what the updated article will say when published), is as follows:
Windows failover clusters require Windows 2008 R2 and the following hotfix: KB2446607 (or subsequent service pack). BitLockered Exchange volumes are not supported on Windows failover clusters running earlier versions of Windows.
This means that if your DAG is running Windows Server 2008 R2 or later, once you download and install the QFE from 2446607, it is supported to use BitLocker for Exchange database and log file volumes in the DAG.
Scott Schnoll
