During TechEd 2010 in Berlin Ross Smith IV from Microsoft suddenly announced that Microsoft recommends using a hardware load balancer for Exchange Server 2010 instead of using Windows Network Load Balancing. You can check the presentation online on Channel9: http://channel9.msdn.com/Events/TechEd/Europe/2010/UNC311.

NLB has some known issues when it comes to Exchange Server 2010 like scalability issues, lack of service awareness, a full reconnect of all clients when adding or removing a new NLB member and only the option of Source IP for persistence.

Hardware load balancers, or Application Delivery Controllers (ADC) as they are sometimes referred to are a much better solution for protocol load balancing in Exchange 2010. In this article I would like to spend some time on load balancing principles and in a follow up article on Kemp Technologies, a 3^rd party vendor that makes Exchange Server 2010 certified load balancers. And more interesting, the Kemp load balancers are available as hardware solutions and software solutions (as a Virtual Machine).

Hardware Load Balancers

There are quite a number of hardware load balancers for Exchange 2010 available, but most have the stigma of “very expensive” on them. That might be true (after all, some are expensive) but at the same time these solutions are targeted towards large Enterprise or Hosting environment. For the smaller and medium sized businesses Kemp offers interesting solutions starting at only € 1.900,-. For a complete overview of the Kemp load balancers check this link: http://www.kemptechnologies.com/en/loadbalancingresource/microsoft-exchange-2010.html

A hardware load balancer, or application delivery controller is basically a device that intercepts client traffic (MAPI, HTTPS, POP3/IMAP4 and SMTP) and spreads this across all Exchange 2010 Client Access Servers.

Figure 1. A Kemp load balancer in a multi-role Exchange server configuration

These clients can come from the internal network (i.e. Outlook clients) or from an external network like the Internet. There’s a distinct difference between the two, especially when there’s a reverse proxy between the Internet and the load balancer.

The load balancer itself can be connected in two ways:

• One arm configuration – this way the Load Balancer is connected to the internal network using one network interface. The Load Balancer is in the same subnet or VLAN as the clients and as the Exchange Servers. This is shown in Figure 1;
• Two arm configuration – with a two arm configuration the Kemp is connected using two network interface. The first network interface is connected to the VLAN where the clients are connected and the second network interface is connected to a (dedicated) VLAN where the Exchange servers reside.

Besides the infrastructural setup there are a few more important aspects you have to be aware off:

• Routing – you have to be aware of the routing in your network when using a hardware load balancer. In a one arm configuration the clients connect to the IP address of the load balancer, but when the clients are on the same subnet, the Exchange server will respond directly to the client instead of responding back to the load balancer. You can use Source NAT on the load balancer to avoid this. The Exchange server only sees the IP address of the load balancer and not of the original client;
• Persistence – this is also referred to as stickiness or affinity. A client connects to a load balancer and the load balancer sends the request to a particular Client Access Server. Persistence of the load balancer makes sure that the client keeps connected to the same CAS server when the connection is interrupted, or when there’s no activity in general. Persistence can be based on source IP address (think about the reverse proxy I mentioned earlier) or with smart HTTP solutions where the HTTP header of the incoming request is examined and modified. Also cookie based solutions are an HTTP solution. Since this takes place on an application layer these are typical Layer 7 solutions where the source IP are more down-level solutions referred to as Layer 4. Persistence is extremely important if you have stateful connections between the client and the server. This is the case with OWA/ECP and MAPI clients;
• Distribution – Distribution is the technique used by the load balancer to distribute client requests across multiple Client Access Servers. Common techniques are Round Robin and Least Connections.
• SSL Offloading – SSL Offloading is where the SSL connection is terminated at the load balancer. Hardware load balancers often have a dedicated processor to perform this and thus (theoretically) gain a performance benefit. On the other hand, current hardware is so powerful that this performance gain is not more than a few percent. But you need SSL offloading to perform the HTTP header based persistence solutions. Without SSL offloading it is only possible to do source IP persistence!
• Transparency – transparency is whether or not the IP address of the original client is logged on the Exchange server. When transparent the original IP address is logged on the Exchange server which can be useful for troubleshooting CAS connections, but especially important for SMTP messages. Without transparency it is not possible to use connection filtering on the Hub Transport Server!

Configuring the KEMP LoadMaster

For this blog post I am using a Kemp hardware load balancer, a Load Master 2600. This one has a dedicated SSL chip on-board and thus can process way more SSL transactions than a virtual appliance.

Configuring the LoadMaster 2600 is real easy. Unpack the box and wire it to the network. There are four RJ45 connectors. The first two (Eth0 and Eth1) are used for connecting the load balancer to the network (Eth0 for single arm, Eth0 and Eth1 for two arm configuration), the remaining two connectors can be used when multiple load balancers are used in a high availability configuration where one load balancer is the active load balancer while the other load balancer is a hot stand-by.

Connect a monitor and USB keyboard to the device and turn it. Within seconds the system is booted and an initial wizard is shown. Here you can enter the IP configuration for Eth0 and Eth1 (when connected), enter some network information like DNS settings and domain search order and your done. As shown in Figure 1 the load balancer in our lab environment is configured in a one-arm scenario and its IP address is 10.19.67.253/24, the default gateway is 10.19.67.1.

Figure 2. Initial configuration of the LoadMaster

When done, reboot the device and you’re ready to configure the Kemp using your browser. Way easier than configuration in the initial text based interface.

Open the browser and connect to the IP address of the load balancer, ignore the certificate warning. This is caused by the self signed certificate on the box while we’re connecting using the IP address.

The Kemp load balancer is easy to configure when using the web interface. On the left there’s the menu where you can select the options you want to configure like the Virtual Services, the Real Servers or Certificates and there’s the results pane in the middle.

Figure 3. The main configuration page of the LoadMaster

Before creating a new Virtual Service (sometimes referred to as VIP) the three Exchange servers have to be configured correctly. On all virtual directories the internalURL and the externalURL have to be configured. In this lab environment the URL webmail.exchangelabs.nl is used, both externally and internally (split DNS). When accessing this URL it will enter the LoadMaster and then one of the three Exchange Client Access Servers.

Figure 4. Some of the Exchange 2010 Virtual Directories and the (internal) Autodiscover settings

Note. Configuring the Exchange Client Access Servers need to be done very carefully. If one server is configured incorrectly you’ll face issues like not being able to connect to Exchange, or slow connections, or able to connect but not the next morning. All these kinds of strange issues, not all the time, but every now and then!

Summary

In this blog post I tried to explain some of the basics of load balancing, and in this example using a Kemp LM2600 load balancer. In the next blog I will explain how to configure this.