Of NICs and DAGs in Exchange 2010

Tony posted a blog article discussing the tradeoffs inherent in choosing a number of NICs for your Exchange 2010 DAG members. While I don’t disagree outright with anything he said, I think there are some additional factors that are worth mentioning.

Bottom line: I always recommend– and practically require– two NICs in all DAG members. Why? The answer is threefold, but to get there we have to do a bit of digging.

It’s important to understand that DAG members process two distinct types of network traffic: "MAPI traffic" to and from CAS servers (and AD, and pretty much everything else) and "replication traffic" to and from other DAG members. (See this TechNet topic for more on the distinction between the two.) First, the way DAGs handle network traffic is that you can specify separate networks for replication traffic and normal traffic. It’s perfectly supported to put both types of traffic on the same NIC. However, if you segregate the traffic onto two separate NICs, you get a bonus– think of it like a saving throw against failover. A failure of the MAPI network will trigger a DAG failover, but a failure of the replication network will merely move replication traffic onto the MAPI network without a failover.

With that in mind, here’s why I think you should plan on using two (or possibly more) NICs in your DAG members.

First, you get additional protection against several potential points of failure. Provided that you’ve designed your environment properly, having two NICs means that you’re protected against failure of a single cable, switch port, or switch. (This assumes, of course, that you haven’t just plugged every DAG member into the same physical switch!) Even if you’re using the tried-and-true method of linking two DAG servers together with a simple crossover cable, having a second NIC insulates you against failure of that cable.

Second, you gain flexibility. All other factors being equal, I’d rather have the ability to shift MAPI or replication traffic to a different physical path when necessary.

Third, the vast majority of modern servers (where by "modern" I mean those sold since the release of Exchange 2007) already include at least two, and often four, onboard NICs. Many IT staffers are suspicious of the quality of onboard NICs due to various problems with chipsets and drivers of old, but I have seen many perfectly stable and well-functioning Exchange environments using modern NICs and drivers so this seems like a legacy concern to me.

Tony makes an important point when he says that companies who have the ability to notice and respond to outages quickly will be OK running a single NIC. I don’t disagree, but I’d point out that even such companies would rather not have outages in the first place. Admittedly, a failure of the MAPI NIC in a DAG member will trigger a failover, but it’s a simple matter at that point to reconfigure the network to use the replication NIC if need be, or to replace or repair the failed NIC if it makes more sense to do so.

If it costs you literally nothing extra to gain the additional benefits of flexibility and protection, in my opinion you’d be well advised to grab those benefits with both hands.

Advertisements

Comments Off on Of NICs and DAGs in Exchange 2010

Filed under UC&C

Comments are closed.