In this article, I want to discuss the reasons why Load Balancing is important to Exchange 2010 and what you can do about it. There seems to always be a big discussion with the customers I work with on why this is necessary, what needs to be balanced, and how to do it.
So, why is this needed?
Load balancing is a way to manage which of your servers receive traffic. Load balancing provides failover redundancy to ensure your users continue to receive Exchange service in case of computer failover or switchover. It also enables your deployment to handle more traffic than one server can process while offering a single host name for your clients.
Several changes in Exchange 2010 make load balancing important for your organization. The Exchange RPC Client Access service and the Exchange Address Book service on the Client Access server role improve the user’s experience during Mailbox failovers by moving the connection endpoints for mailbox access from Outlook and other MAPI clients to the Client Access server role instead of to the Mailbox server role. In earlier versions of Exchange, Outlook connected directly to the Mailbox server hosting the user’s mailbox, and directory connections were either proxied through the Mailbox server role or referred directly to a particular Active Directory global catalog server. Now that these connections are handled by the Client Access server role, both external and internal Outlook connections must be load balanced across the array of Client Access servers in a deployment to achieve fault tolerance.
A load-balanced array of Client Access servers is recommended for each Active Directory site and for each version of Exchange. It isn’t possible to share one load-balanced array of Client Access servers for multiple Active Directory sites or to mix different versions of Exchange or service pack versions of Exchange within the same array.
Key Concept for Load Balancing Exchange 2010
Understand the key technology differences in load balancing solutions. These can affect the Performance, Manageability, Failover detection and automation, and Affinity options available.
So why can’t I use Windows NLB?
There are a few scenarios in which you will not want to or cannot use WNLB.
WNLB can’t be used on Exchange servers where mailbox DAGs are also being used because WNLB is incompatible with Windows failover clustering. If you’re using an Exchange 2010 DAG and you want to use WNLB, you need to have the Client Access server role and the Mailbox server role running on separate servers.
Due to performance issues, we don’t recommend putting more than eight Client Access servers in an array that’s load balanced by WNLB.
WNLB doesn’t detect service outages. WNLB only detects server outages by IP address. This means if a particular Web service, such as Outlook Web App, fails, but the server is still functioning, WNLB won’t detect the failure and will still route requests to that Client Access server. Manual intervention is required to remove the Client Access server experiencing the outage from the load balancing pool.
WNLB configuration can result in port flooding, which can overwhelm networks.
Because WNLB only performs client affinity using the source IP address, it’s not an effective solution when the source IP pool is small. This can occur when the source IP pool is from a remote network subnet or when your organization is using network address translation.
Your organization has a reverse proxy server that communicates directly with the Client Access server and not through the WNLB virtual IP address. The reverse proxy server hides the client IP addresses from the Client Access server array. Therefore, source IP affinity won’t work as expected. However you may still want to use WNLB to load balance internal traffic.
Your organization has many clients accessing your Client Access servers through a very small set of IP addresses. WNLB tends to affinitize an entire class C subnet to one Client Access server.
Ok, so I want to use a Hardware Load Balancer. Now what…
You need to review what capabilities, as mentioned above your solution has. Is it a reverse proxy based solution such as Forefront Threat Management Gateway or Unified Access Gateway? What Affinity options does it support? These could be (more details are available at http://technet.microsoft.com/en-us/library/ff625247.aspx) :
- Cookie Based Affinity
- SSL Session ID
- Source IP
- or No Affinity
Microsoft has published at summary of Load Balancer Options which you will want to review prior to making your decision.
If you need help finding hardware load balancer options, Microsoft has a qualification program for vendors to signup for which then gets their product listed on the Microsoft site for Unified Communication Load Balancers. This list is available at http://technet.microsoft.com/en-us/office/ocs/cc843611.aspx.