OK, So maybe my blog title is a little harsh. The Microsoft Exchange products have been pretty scaleable since Exchange 2007.
Exchange 2010 had some vast improvements and you could tell that the Microsoft engineers had put a lot of effort into trying to ease the painful mess that was load balancing an Exchange 2007 cluster. They even started recommending hardware load balancers and certifying vendors for Exchange 2010 compatibility.
But with Exchange 2013 they appear to have started from scratch and written it properly! They actually sat down and said “What do we need to have a scaleable Exchange email cluster?”. Funnily enough they came up with the same answer that Loadbalancer.org has been banging on about for last 10 years. In order to have a scaleable cluster, each node in the cluster must be able to handle any user session at any time; i.e. no messing around with persistence, sticky plasters, and hack jobs.
Well done Microsoft!
But please can you put the same infrastructure architects on your LYNC team?
Seriously, who puts 3 DMZs in an enterprise product? I had to put Rob (who made sure Loadbalancer.org gained Microsoft Lync certification) on suicide watch …
“Our DMZ is so secure we cant even get into it!”
Better get back to discussing the point of this blog I guess …
In order to gain high-availability for an application a load balancer is fairly fundamental, because a load balancer gives you:
Resilience: A load balancer continuously monitors your application servers and, if it detects a problem with them, it moves the traffic onto another server in the cluster. This was not possible before Exchange 2013 without a brief interruption of service. Now it’s easy. Tony Redmond has some good points about how important flexible health monitoring of Exchange 2013 still is.
Maintainability: You can’t have 100% uptime on every server, eventually they will break or at least need security updates or software updates. With a load balancer you simply drain the connections, perform the maintenance, and then bring the server back online. Exchange 2013 makes software upgrades easy as discussed by Rand Morimoto.
Performance: This one is often misunderstood. Contrary to popular belief you don’t need a super fast load balancer to increase your performance – you just add more backend servers to the cluster! However this requires that the cluster can handle horizontal scaling which also was not possible before Exchange 2013.
Kemp Technologies (one of our main competitors) is going to be gutted by the changes in Exchange 2013. They made this lovely sell up tool which shows how much horse power you need to SSL terminate in front of Exchange 2010 clusters. Don’t get me wrong they have a great product; it’s just that with Exchange 2013, customers will no longer need any SSL termination on the load balancer so their cheapest product will handle the load easily.
F5 – who are very deservedly the market leader in the load balancing space – are mounting a defensive PR reaction to Exchange 2013 improvements already. BTW: This post by Ryan Korock is terrible; at least come up with some real reasons to use F5, i.e. awesome logging, monitoring, snmp interrogation, L7 performance based re-directing, re-direct on failure of connections. Come on man … L7 rocks when you have the capability of an F5!
Anyway long story short but if you are in the middle of an Exchange 2010 migration then do yourself a favour: Stop now! Whatever the initial cost to move to Exchange 2013 right now, it’s awesome!
PS: Dimitrios Kalemis agrees with me …
Important Note: Please make sure you use at least Exchange 2013 CU2 Build 15.0.712.24. This build includes a number of stability improvements and bug fixes that effect the ability to reliably implement a load balancing solution. Please refer to this Microsoft link for details on the initial release of CU2 and this Microsoft link for details on the updated release.