If you’re a regular reader of this blog, you’ll know that I produce the free Exchange 2010 Virtual Load Balancer, based on HAProxy. However, that’s really aimed at lab use, so you might wonder what I usually recommend in it’s place..
So, it’s about time I wrote about the KEMP LoadMaster, ran through a quick overview of how it works and re-iterate why you really should consider load balancing Exchange Server 2010 with a load balancer rather than Windows Network Load Balancing.
Why use a load balancer?
With Exchange Server 2010 clients in a highly-available environment need a resilient point to communicate with Exchange client access servers. In Exchange 2010, not only do clients like web browsers, mobile devices and Outlook Anywhere clients (e.g. Outlook!) connect to the Client Access servers, but also traditional MAPI clients too. The “Client Access Array” within Exchange Server provides a single name that is used by MAPI clients as the Exchange Server name, and because of this it is very important that this is highly available and in the event of failover or switchover clients are not disconnected.
When you listen to the advantages of Exchange Server, one of the areas where benefits are apparent over previous versions is in this area – the ability to perform maintenance on servers without affecting end-users. The real benefit to you as an IT admin is that you can patch Exchange during the working day instead of waiting until a scheduled out-of-hours maintenance period in the evening. It’s kind of like the vMotion of Exchange.
However if you’re just relying on Windows Network Load Balancing, you kind of only get half of that advantage. Common problems using Windows Network Load balancing are issues like some Outlook clients not automatically reconnecting to the NLB after one node is removed and this often means you are back at square one when it comes to performing maintenance.
The second more fundamental set of reasons lie in scalability, service awareness and session affinity. Rather than re-iterate what I’ve written about in the past, check out my article Exchange Team no longer recommend Windows NLB for CAS load balancing.
Finally if you’re building out a new Exchange 2010 environment, hardware costs and licensing are real considerations. As an example, let’s look at two options for building out a small but resilient Exchange infrastructure:
Option 1, using NLB:
- 2 x Client Access / Hub Transport Servers
- 2 x Mailbox Servers forming a Database Availability Group
Option 2, using a Load Balancer:
- 1 or 2 Load Balancers, depending on requirements
- 2 x Combined Client Access, Hub Transport and Mailbox Servers forming a Database Availability Group
So, with Option 1 we’re possibly looking at the following additional servers just to support Windows NLB on the Client Access/Hub Transport roles:
- 2 x Exchange Server Standard Edition Licences
- 2 x Windows Server Standard Edition Licences
- 2 x Servers with probably 8GB RAM each, RAID 1 storage and Xeon CPUs with multiple NICs, redundant PSUs.
But with option 2, we’re replacing all that with a load balancer (bear in mind that in a typical environment the combined role Exchange servers will have a lot of spare CPU cycles available and not need as much additional memory as standalone CAS/HT servers).
Now, traditionally with load balancers like the F5 and the Cisco ACE I’ve found that it’s not easy to justify the benefits when the primary application may just be Exchange, and possibly Lync – they are just too expensive and completely overshadow the hardware and licensing costs of CAS/HT servers.
However I think this is where KEMP have found a good niche in the market – not only are they now an established player with a lot of people in the Exchange community using them, the price point fits the bill perfectly. Even in a virtual environment where there’s no additional hardware and Windows licences to purchase, the KEMP is still competitive against Exchange Server Standard edition licences.
So for the same ballpark price, it’s an easier implementation, easier to manage and it’s a nice compact straightforward design. For example, using a load balancer fits in quite well with the idea of using combined role servers as “building blocks” to scale Exchange simply as your requirements grow.
Overview of the KEMP Virtual LoadMaster
A good start when you’re looking at the KEMP LoadMaster is the Virtual LoadMaster, or VLM for short. There’s a few different models in the KEMP range – and the VLM is a good one to get a demo of to see what it’s actually like in practice. You’ve got the Exchange specific ones and generic ones which can balance pretty much anything.
For this example, I’ve drawn a quick diagram to illustrate what we’ll be attempting to do. You’ll see the HTTP/S namespace for exchange (mail.exchangelabs.co.uk) and the CAS Array name (outlook.exchangelabs.co.uk) both pointing internally at the KEMP VLM. Behind it is three Exchange Servers, all hosting the Client Access, Hub Transport and Mailbox roles as part of a Database Availability Group:
Initial setup of the KEMP LoadMaster is straightforward – but in overview you need to perform the following steps:
- Installation of the VHD of VMDK into your Virtual environment.
- First boot and access of the VLM via HTTP
- Configuration of network interfaces.
- Installation of my Wildcard SSL certificate onto the LoadMaster.
Next it’s onto the configuration of the environment to match the diagram above. I’ve configured two network interfaces, bridging the above two VLANs/LAN segments shown. This allows the LoadMaster to act in a transparent fashion and report the original client IP addresses to the Exchange Servers themselves. I’ve then configured the Exchange Servers, covered in detail within the KEMP Exchange 2010 deployment guide:
- Using the LoadMaster as the default gateway on each Exchange server hosting the CAS role (all of them, in our scenario).
- Configured SSL Offloading on each Exchange server hosting CAS.
- Configured Static RPC ports for MAPI and the Address Book Service on each Exchange server hosting CAS.
I’ve then added services for HTTPS, and the two RPC services, as shown below:
As you can see, it’s a fairly straightforward configuration, and we can add more services under different ports, or different IP addresses as required; for example to publish SMTP services, or indeed other servers such as Lync.
Similarly, when it comes to management of the devices and services, we’ve got an easy to use interface to disable the real Client Access Servers from receiving traffic:
Finally, we can examine statistics about the Loadmaster itself, client connections and the traffic sent to each Exchange Server:
So, we’ve had a quick look at the KEMP and as you can see, it’s fairly straightforward to administer and look after. It’s certainly a lot easier to get to grips with than, say a Cisco ACE (something I’ve had some experience with) and that means it’s likely to be more than just some “black box” that you don’t ever log into, or are worried about breaking something if you use. And if you’re implementing it for someone else, you’ll be able to hand over the unit confident in the knowledge that you won’t get a phone call next time someone needs to disable one of the servers for patching.
But the one thing that makes KEMP especially attractive is the combination that it’s a well known product, with decent support and a decent price. There are free solutions out there (like my own!) but I wouldn’t use them in a production environment simply because you need quality support available if there is an issue.
A final note – KEMP did ask me to write about their Load Balancer but I’d like to make it clear that I didn’t receive any compensation for it, apart from a Not For Resale (NFR) demo copy of the VLM to use for the review. What their marketing people didn’t know when they asked me to write about their Load Balancer is that I already recommend KEMP to my customers – in fact I’m implementing another for a new deployment in a couple of weeks time, so I figured.. why not