Issue link: https://epubs.iltanet.org/i/27653
DAG STANDS UP TO THE RESILIENCY CHALLENGE On the other hand, you can have multiple DAGs in an Exchange organization. Finally, the design of the Exchange 2010 network can either be a challenge or relatively straightforward depending on your VLAN design and switch configuration. Microsoft recommends that you use two separate networks on a DAG member server, one for the Messaging Application Program Interface (MAPI) traffic, and the second for the replication traffic. The reason for this recommendation is that it allows the replication network to be isolated from MAPI traffic, and provides redundancy for the replication network. However, you can use a single network on the DAG member servers if there are limiting factors preventing a dual-homed configuration. BEYOND THE BASIC DAG With Exchange 2010 Database Availability Groups, there are a few options outside of the basic configuration that give you added flexibility: • Determine the order of failover among the DAG member servers when you have more than two copies of a database in the group. If you want to provide site resiliency — as well as local resiliency — for your mailbox copies, this option gives you the flexibility to guarantee that the local copy takes over first if it is available. • Allow the Exchange administrator to configure a lag in the log replay time on individual database copies, up to a 14-day delay. Why could this be important? If third-party applications have caused logical corruption in your Exchange database, the delayed replay time could save restore time from a more traditional backup. • By default, Exchange 2010 DAG servers will truncate log files on passive database copies after they are truncated on the active database copy, and the log replay lag time has passed. The log truncation delay adds another buffer to the deletion time of the passive database log files. • For firms that have a need for the most efficient use of network bandwidth for DAG replication, especially over a WAN, Exchange 2010 offers network compression of replication traffic. In addition, for IT administrators that must follow specific security policies for cross-server traffic, Exchange 2010 also allows network encryption of the replication data. Both of these options obviously come with some increased CPU overhead for the DAG member servers. Exchange 2010 Database Availability Groups are a great new feature of Exchange 2010. It drove us to implement the new Exchange version as soon as third-party support for our major applications allowed it, and has resulted in immediate value in our Windows update management strategy and DR recovery time objectives. With proper planning and a full consideration of the requirements, the Exchange 2010 DAG feature has provided Arnall Golden Gregory with a robust and modular solution to the application resiliency challenge for e-mail services. ILTA www.iltanet.org Exchange 2010 33