Tim McMichael

Navigating the world of high availability...

Network port design and Exchange 2010 Database Availability Groups

Network port design and Exchange 2010 Database Availability Groups

  • Comments 1
  • Likes

(An Exchange 2007 version of this article can be found here:  http://blogs.technet.com/b/timmcmic/archive/2009/04/27/network-port-design-and-exchange-2007-clusters.aspx)

A question that has come up is how many network ports should I have in my DAG members and how should I use them. 

I generally see three different hardware configurations:

  • Two network ports.
    • Usually two onboard <or> 1 onboard / 1 add-on.
  • Three network ports.
    • Usually 2 onboard / 1 add-on.
  • Four network ports.
    • Usually 2 onboard / 2 add-on.

In some hardware there are now 4 port cards.  The information contained here can be expanded to include additional hardware / port configurations as they become available.

You’ll note that there is no configuration with a single network port – I personally do not recommend having only a single network port even though this is now a supported implementation.  (Note:  VLANS to a single port are not two network interfaces).

Network Teaming

In the recommendations I’ll outline next you will see references to the use of network teaming.  It’s important to note that Microsoft does not support network teaming as this is hardware vendor supported and designed technology.  What it is though is a recognition that in absence of anyway to provide multiple client facing ports for Exchange network teaming does have a valid place in the overall high availability design.

When using network teaming, only the client facing network should be a teamed adapter and at all times the team created for NETWORK FAULT TOLERANCE.  Do not, for an Exchange instance, use any type of load balancing between ports.

For non-client facing networks it is not necessary to implement at network team (these would typically be your “heartbeat” networks).  Windows clustering has the ability to balance and use all interfaces on the cluster designated for cluster use without the need to establish teaming for cluster / heartbeat communications.

From a support perspective any customer that establishes a teamed interface for the client side network should recognize that they may be asked to dissolve the team to support troubleshooting efforts.

MAPI Networks

For Exchange 2010 DAG MAPI networks I recommend using a network fault tolerant team consisting of two ports.  More ports maybe utilized if they are available.

Replication Networks

After a team has been utilized for the MAPI network the remaining network interfaces can be divided into replication networks.  I do not recommend that any form of network teaming be utilized on replication networks.  Utilization of teaming on replication networks – although supported – is redundant.  Both the replication service and cluster service have the ability to switch between these additional networks as necessary.  All additional networks must be on their own subnet, subnets between networks may not overlap on the host.

Cluster Networks

There is no reason to establish dedicated cluster heartbeat networks with Exchange 2010 DAG members as cluster can utilized all configured interfaces between hosts for heartbeat exchange.

==============================

Updated – 6/2/10 – It is supported to use teaming on non-client facing networks although in theory this is redundant as both the replication service and cluster service have the ability to utilize multiple secondary interfaces.

==============================

Comments
  • Are there any snapshots that you can post on how to configure networks , in EMC

    i have 4 NIC Cards and teamed.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment