The Database Availability Group (DAG) is probably the best Exchange 2010 feature from both an impact and technology perspective. Microsoft took a really good decision by not limiting the DAG to enterprise editions of Exchange, even if you can only mount five databases on a server (counting both active and passive) with this edition and still require Windows 2008 Enterprise (because of the dependency on Windows Failover Clustering). The reason why it’s such a good decision is that it allows DAGs to be deployed to protect Exchange 2010 deployments from the very smallest to the very largest, which can’t be a bad thing.
Of course, another good thing about the DAG is that it hides much of the complexity involved behind the Exchange Management Console (EMC). Sure, you can plunge into mano-a-mano combat with the finer points of the DAG through the command line but there’s no good reason to do this unless you really must tune something that cannot be reached through EMC, such as sorting out networks automatically generated when a DAG is formed – the rule is that you can only have one MAPI network while several replication networks are supported.
MAPI networks are used to connect DAG member servers to network services such as Active Directory and for connections between a mailbox server and the CAS. These networks are registered in DNS, use the default gateway, and are enabled for Microsoft networks file and print sharing. Replication networks are used to transfer transaction logs between servers and are not registered in DNS, do not use the default gateway, and disable Microsoft networks. A server can survive with just the MAPI network (single NIC) as Exchange will route all traffic across this network, but if the MAPI network fails it forces a server failover within the DAG.
The Add-DatabaseAvailabilityGroupServer cmdlet (run manually or by the EMC Create New DAG wizard) attempts to make things easy for administrators by scanning for network cards known to the cluster service when a server joins a DAG (note that if you add a NIC to a server after it’s in a DAG or change the subnets used by the DAG, you can force Exchange to discover the NIC by running the Set-DatabaseAvailabilityGroup cmdlet with the -DiscoverNetworks parameter. For example:
Set-DatabaseAvailabilityGroup -Identity DAG1 -DiscoverNetworks
During enumeration, each NIC is assigned its own DAG network entry. If a server has multiple NICs, it’s possible that the enumeration and creation of DAG networks will end up with some entries that have a single endpoint and that just won’t work. The DAG will continue to function because Exchange contains fall-back logic that will instruct the DAG to use the only network that’s registered in DNS, meaning that all traffic will be routed across the MAPI network. However, it’s not good to persist with this situation and an administrator will have to sort it out by collapsing the networks so that you end up with the various subnets allocated correctly to the right DAG networks and the superfluous networks removed. This kind of complex one-off work is best done with EMS as you couldn’t expect the EMC UI to cater for every possible situation that might arise. See MSDN for more information about the creation of DAG networks.
In any case, this post is not about the finer points of DAG networks. In fact, I just wanted to share an unusual hiccup that EMC displayed the other day.
Even a hugely active database is hardly likely to create so many transaction logs that it would accumulate such a massive copy queue length (9,223,372,038,654,775 is the figure shown in the screen shot). Of course, this is the result of a transient glitch that EMC took seriously – a quick refresh exposed the true state of affairs and the copy queue length came up with the expected zero value. But isn’t it nice to know that Exchange 2010 is designed to deal with such a long queue – or at least that EMC is ready to display the good news about such a queue to an administrator!
Where would we be without a glitch to make the day go by faster?