Exchange Server 2010 mailbox servers offer a new function known as Database Availability Groups (DAG). Under a DAG configuration, the mailbox data is replicated across several hosts. The result of this is that in Exchange Server 2010 it is now less important to build in system level redundancy. If a DAG node fails, as opposed to rebuilding it, we can simply build a node, add it as a replica, the data will replicate to it. This has a dramatic impact on the way administrators deploy servers. As opposed to struggling with the price versus performance trade-offs of RAID0+1 vs. RAID5, administrators can now consider simply running basic disks with no redundancy. This means smaller servers are now a viable option as one is not likely to require nearly as many disks in a chassis. Thus administrators can consider moving from complex and expensive SANs back to direct attached storage. This of course is not so much about performance as about simplicity and cost.
When configuring a DAG you should consider using a separate network for replication. DAGs offer the capability to configure nodes to use a specific network for the replication traffic. This provides two benefits. Firstly, in a LAN scenario, users are not competing with the replication traffic for access to the mailboxes over the LAN. Alternatively in a WAN configuration, if the environment has access to multiple networks, the replication traffic
could potentially be movied to a lower cost network. Consider the scenario where a large enterprise has multiple offices connected with an MPLS network. MPLS provides high bandwidth and good performance but is expensive. The large enterprise will also likely have IPSec tunnels set up across Internet connections to provide for a secondary network in the event of a failure of the enterprise’s MPLS links. The cheaper IPSec tunnels could be used for offloading the DAG replication traffic. This will reduce the load on the main network and save the expensive of using the more expensive network.
Another way to optimize DAG performance is to balance the load across the multiple DAG replicas. In Exchange Server 2010 replication is performed at the database level as opposed to the server level. Thus, instead of running in Active/Passive pairs, one can effectively be active for some databases and passive for others on the very same server. Therefore a site may have three DAG members in a single location for redundancy and could be running 1/3rd of the databases as the “master” on Node 1, 1/3rd on Node 2 and the final 1/3rd on Node 3, with the replicas going to the other 2 nodes. Node 1 could be “master” for databases 1-5, the second priority for
the databases 6-10 and third priority for the databases 11-15. therefore in the event of a node failing, the load would be doubled on the remaining two servers instead of tripled on a single node. Administrators can get the best performance out of the server hardware by carefully planning the loads for both a “normal” and a “Disaster Recovery” scenarios.