Differences in Exchange Load Balancing recommendations by Microsoft and vendors
*** See my followup here Exchange, Load balancers and recommendations:
At TechEd North America 2011 Andrew Ehrensing (Solution Architect form Microsoft) presented the session “Load Balancing with Exchange Server 2010” (EXL307) for which the video and slides can be found here. It was an excellent session, a lot of useful information even if you don’t have to load balance with Exchange per se.
For me it was an extra interesting session, as we just had implemented a load balancer with Exchange, which resulted in some issues (bad performance, third party monitoring software failed etc.). I already thought that our setup had some design flaws and was looking for configuration recommendations. Unfortunately, I couldn’t find any in-depth information on Microsoft TechNet, except for basic information.
I will not go into the session in detail in this post (perhaps in another), but the session basically had the recommendation that in an One-arm Load Balancing setup Source NAT (SNAT) should be used, even with clients or servers in the same subnet. Alternatively putting the Load Balancer as Default Gateway (LBDG) is also a valid option. Direct Server Return (DSR) wasn’t advised, as you have to add a loopback adapter with the Virtual IP (VIP) to all CAS Exchange Servers behind that specific Load Balancer. SNAT is least intrusive to the configuration of your Exchange Servers.
As I dug deeper in manuals and recommendations, I found discrepancies in the recommendations. Why is this important? It is a matter of getting adequate support. Do you get support from your vendor if you follow Microsoft recommendations, when they are different?
In this specific case we were using a VLM-100 from Kemp Technologies and are quite happy with the value for money they supply. In previous situations we did not have any issues, but that were different environments.
Digging deeper in the Kemp Manual (PDF) I found that they primarily recommended a Load Balancer as Default Gateway with optional DSR configured. As we had poor experiences with this setup and in this case we would be required to implement LBDG with DSR, instead we opted for SNAT.
However, in the manual for basically the same scenario where Microsoft recommended SNAT, Kemp mentions SNAT does not make any sense and recommends LBDG and which in some cases implies DSR. See for references from the TechEd session video time code ~9:04 and ~19:00 and slides 7 and 15. Compare with page 12 of the Kemp Load Balancing manual.
I contacted Kemp for this difference in stance, pointed them to the TechEd video and slides and am currently awaiting a call from their Developer team. I will update this post when I receive new information.
During this mail exchange, they also pointed out that the static ports we configured could be changed to a wildcard Virtual Server (VS) on their load balancers. It would work better, was the motivation. Not very convincing IMHO, especially as Andrew in the same session pointed out that it is better to have static ports as this would putt less strain the load balancer (video time code 35m30s). This is also the configuration as Exchange MVP Henrick Walther has described in several blogposts, but specifically in this one.
Curious how other vendors recommend their product in combination with Exchange, I stumbled upon the loadbalancer.org deployment guide for Exchange 2010 (PDF). In this guide they recommend “Least Connection” as distribution method as Microsoft recommends plain Round Robin (see page 12). Also with reason: Microsoft found issues when a CAS server is re-introduced in the CAS Array and as Load Balancing “node”, it could be overwhelmed when using any weighted, least connection or similar method. (video time code 34m09s). I will contact loadbalancer.org on this issue shortly.
I haven’t found any other discrepancies yet, but will update or follow up this post when an interesting difference comes to my attention. If you found one yourselves, feel free to mail or comment with specifics.
I did not check any of the other vendors and their recommendations. But this situation is very interesting as the products from Kemp Technologies are tested and qualified by Microsoft. Apparently that does not mean the recommendations have to correspond… I find that a bit disappointing and devalues the qualification IMHO.
TechEd North America 2011 Load Balancing with Exchange Server 2010 (EXL307)
Understanding Load Balancing in Exchange 2010
Uncovering the new RPC Client Access Service in Exchange 2010 (part1)
Load Balancing Exchange 2010 Client Access Servers using an Hardware Load Balancer Solution (part1)
Kemp Technologies Load Master Manual (PDF)
LoadBalancer.Org Exchange Deployment Guide (PDF)
Exchange Server 2010 Load Balancer Deployment (Qualified Vendors and products)