I’m sure this has been covered by many other sources on the internet, but I thought I’d put down my thoughts on the matter as many people still don’t understand why the correct load balancing configuration is important.
I’ve been involved in a number of Exchange Server 2010 deployments during my last couple of months and most of the deployments were upgrades on hosted platforms from Exchange Server 2007 to Exchange Server 2010.
What I noticed in these Exchange Server 2007 deployments were that load on Client Access Servers (CAS) were somewhat skew. And this makes sense, because the load balancing was configured for Source IP persistence.
What does this mean in a hosting environment?
Well, firstly all clients are connecting to the messaging platform over the Internet behind a NATed IP.
You could potentially have a tenant with a 1000 users behind a single IP. The hosting environment won’t have any visibility to the internal IP’s and thus only see the source IP being the external interface on the tenants firewall. If source IP persistence is configured on the load balancer it will basically send all traffic for that source IP to one CAS server (give or take a few connections).
Something like this:
This concept is also the same for corporate enterprises running their own on-premise Exchange Server 2010 solution. The reason I’m saying it effects corporate deployments as well is that most mobile phones connect to the internet via NATed IP’s behind the carrier firewall. So mobile phone ActiveSync connections from a specific carrier will be sent to one CAS box.
So how do we fix this? Configure the correct persistence.
First we check that the load balancer is on the Exchange qualification program for load balancers. The main reason for this is that we’ll know if it was tested and reviewed by Microsoft and the partner for the type of load balancing we want to do. It’s also a very good resource to find deployment guides on the specific load balancer.
When I deployed the Exchange Server 2010 solution we incorporated cookie based persistence on the load balancers for the customer. We did not configure SSL Offloading. To keep things simple we configured an SSL Bridge whereby the load balancer will decrypt the packets, read the cookies then re-encrypt the packets before sending it to the CAS boxes.
Implementing cookie based persistence can be tricky. but it can also be very easy, it really depends on the person responsible for the load balancer, which usually falls into the networking or security team. Personally, I put in a lot of effort to understand how the specific vendors’ load balancer works. I find that this makes discussions with the network engineer easier. If the engineer understands the concepts on the Exchange side and the impact then it makes life very easy to implement the correct solution.
What protocols require persistence?
I’ve detailed the recommendations on the specific services below that will help you determine the correct persistence method for optimal load balancing.
- Exchange Address Book service within the Intranet
- This service provides directory access for clients. Not using affinity results in a significantly higher level of communication between the client and the Client Access servers.
- Recommended persistence type: Source IP.
- Outlook MAPI connections within the Intranet
- Outlook clients on the Intranet assume that all RPC connections are made to the same server. Outlook uses multiple sessions per user and assumes that all sessions connect to the same server.
- Recommended persistence type: Source IP.
- Outlook Web App and Exchange Control Panel
- These services must have affinity to the same Client Access server.
- Recommended persistence type for Outlook Web App: OutlookSession cookie.
- Recommended persistence type for Exchange Control Panel: msExchEcpCanary cookie.
- Exchange Web Services (Load balancer generated cookie or SSL Session ID)
- Microsoft does not support the use of Exchange Web Services without affinity.
- Recommended persistence type: Load balancer generated cookie or SSL Session ID.
- Outlook Anywhere – (RPC over HTTPs)
- Recommended persistence type: User-agent cookie or OutlookSession (Outlook 2010 only) cookie.
- Exchange ActiveSync – (HTTPs)
- Recommended persistence type: Authorization header cookie
- Offline Address Book – HTTPs (Transactional connection)
- Recommended persistence type: SSL Session ID or Source IP
- Autodiscover service – HTTPs ((Transactional connection)
- No affinity is required for Autodiscover.
Hopefully, this helps some administrators/implementer's understand the concept better. As I mentioned earlier, I personally do a lot of research during my planning and deployment phases to help ease configuration on firewalls, load balancers and such.
Some references that you will find very valuable:
- Great load balancing presentation by Andrew Ehrensing:
- Understanding load balancing in Exchange Server 2010:
Until next time…..happy load balancing 🙂