Expensive load balancers are no longer required, thanks to Exchange 2013 improvements. Clients don't require affinity, so Layer 7 load balancers that inspect traffic and ensure the same client always goes back to the same server can be substituted with simple Layer 4 load balancers with simple configurations.
There are many reasons why an expensive
Setting up Exchange 2013 load balancing with a free option isn't complicated because it's easy to implement and doesn't require lots of maintenance to keep up and running. Commercial load balancers are great and come with good support, additional features and simple graphical user interfaces (GUIs), but a free option might meet your needs for Exchange 2013.
Let's look at an example environment. We'll keep everything relatively simple in our example environment, so we'll have a single site with two Exchange Servers. Each server is running both the Client Access Role and the Mailbox Role and participates in a single database availability group (Figure 1).
The benefit of simple Layer 4 load balancing might mean our load balancer configuration is simple, but it also means that we need to use fully qualified domain names (FQDNs) for each Web service, along with corresponding Exchange configuration for internal and external URLs.
|Outlook Web App and SMTP||mail.exchangelabs.co.uk|
|Exchange Admin Center||eac.exchangelabs.co.uk|
|Exchange Web Services||ews.exchangelabs.co.uk|
|Offline Address Book||oab.exchangelabs.co.uk|
Layer 4 load balancing can't inspect the traffic passing through and therefore won't know if the client is requesting OWA, ActiveSync or something else. To ensure that we can perform per-service monitoring on the load balancer, we'll need to split up traffic by using different IP addresses, the result of which is separate names for each service.
Installing Linux to run Exchange 2013 load balancing
To run our load balancer, we'll need a basic Linux installation. If you haven't installed Linux before, it isn't particularly hard. If you're familiar with PowerShell, then you will adapt pretty easily.
The Linux distribution we'll use for this load balancer is Ubuntu 12.04 LTS. LTS stands for Long-Term Support, which means it will continue to receive updates long after newer versions of Ubuntu stop receiving updates. Ubuntu isn't necessarily better than any other Linux distribution, but we've chosen it because it includes HAProxy. That makes it easy to install and update.
Download Ubuntu Server 12.04 LTS from the Ubuntu website. We'll use that ISO to create a new virtual machine (Figure 2).
The Hyper-V configuration dialogue shows that we don't need a lot of resources to run this load balancer; 1 GB RAM and a single virtual CPU will suffice for our small database availability group.
Ubuntu installation is straightforward. It's a virtual machine, so we know the hardware will be supported and we can choose the defaults for every stage of the installer; the only exceptions are when choosing your login user account and package selection. When prompted to install packages, choose OpenSSH to allow remote administration of the server. The server will reboot after the installation completes, and after the first boot, we're presented with the login prompt. We'll log in here to perform a couple of core tasks:
- Perform updates, the equivalent of installing Windows Updates on the server.
- Configure the IP addresses the server will use.
Log in with the user created during the setup process. This user allows us to elevate privileges
to the administrator user (root) by prefixing commands with sudo (the equivalent of User
Account Control) to make our changes. The program apt-get is used to install and update
software, so we'll update the package list and then install updates using the following
sudo apt-get update
sudo apt-get upgrade
After performing updates, assign static IP addresses to the server. We'll have a primary IP address and an additional IP address for each load-balanced service. The configuration for the network is contained in a text file, which we'll edit with a text editor, similar to Notepad, called Nano:
sudo nano -w /etc/network/interfaces
After opening the interfaces file, replace it with configuration information to match your network:
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address
netmask gateway # OWA and SMTP auto eth0:0 iface eth0:0 inet static address netmask # EAC auto eth0:1 iface eth0:1 inet static address netmask # EWS auto eth0:2 iface eth0:2 inet static address netmask # OAB auto eth0:3 iface eth0:3 inet static address netmask # EAS auto eth0:4 iface eth0:4 inet static address netmask # Autodiscover auto eth0:5 iface eth0:5 inet static address netmask # OA auto eth0:6 iface eth0:6 inet static address netmask
Now you can view the changes you've made (Figure 3).
Using Ctrl-X, then restart the networking service using the following command:
sudo /etc/init.d/networking restart
Install and configure the load balancer
With our server set up, it's time to install the load-balancer software, HAProxy. We'll use the following command to install it:
sudo apt-get install haproxy
The HAProxy package will download and install. Because it was installed using the package manager, it'll also benefit from updates as and when they're applied. Just like the networking configuration, the load-balancer configuration -- HAProxy -- is contained within a simple text file. To complete our load-balancer configuration, we'll need to edit the configuration file for HAProxy and define a number of parameters:
- The definitions for each load-balanced service, such as OWA, and how they are monitored
- The IP addresses each load-balanced service is attached to
- The IP addresses of the back-end servers
We'll use our simple Nano text editor again to edit the configuration file:
sudo nano -w /etc/haproxy/haproxy.cfg
We'll also have to create definitions for each service, using the following configuration file as a reference:
global maxconn 4096 user haproxy group haproxy daemon defaults mode tcp balance roundrobin retries 3 option redispatch maxconn 10000 contimeout 5000 clitimeout 50000 srvtimeout 50000 listen OWA
:443 option httpchk /owa/healthcheck.htm server <Server 1 Name> <Server one IP> check port 80 server <Server 2 Name> <Server 2 IP> check port 80 listen EAC <EAC IP>:443 option httpchk /eac/healthcheck.htm server <Server 1 Name> <Server 1 IP> check port 80 server <Server 2 Name> <Server 2 IP> check port 80 listen EWS :443 option httpchk /ews/healthcheck.htm server <Server 1 Name> <Server one IP> check port 80 server <Server 2 Name> <Server 2 IP> check port 80 listen OAB :443 option httpchk /oab/healthcheck.htm server <Server 1 Name> <Server one IP> check port 80 server <Server 2 Name> <Server 2 IP> check port 80 listen EAS :443 option httpchk /Microsoft-Server-ActiveSync/healthcheck.htm server <Server 1 Name> <Server one IP> check port 80 server <Server 2 Name> <Server 2 IP> check port 80 listen Autodiscover :443 option httpchk /Autodiscover/healthcheck.htm server <Server 1 Name> <Server one IP> check port 80 server <Server 2 Name> <Server 2 IP> check port 80 listen OA :443 option httpchk /rpc/healthcheck.htm server <Server 1 Name> <Server one IP> check port 80 server <Server 2 Name> <Server 2 IP> check port 80 listen SMTP :25 option smtpchk server <Server 1 Name> <Server 1 IP> check port 25 server <Server 2 Name> <Server 2 IP> check port 25 listen stats :8080 mode http stats enable stats uri /
You can view the changes after you've made them (Figure 4).
Use Ctrl-X to save the configuration file and activate the configuration using the following commands:
update-rc.d haproxy enable sudo /etc/init.d/haproxy restart
As with any load balancer, you'll need to direct traffic toward it for it to actually load-balance anything. For each service load-balanced, we'll update the DNS entries to match each corresponding service (Figure 5).
As we begin to test traffic with the load balancer, we'll want to verify that it's distributing
the load correctly while we gain insight into how healthy the load balancer is. HAProxy includes
statistics, which we've enabled in the configuration. To access the statistics, use the following
Lastly, we'll illustrate how simple the HAProxy-based load balancer is to manage and examine what we need to do when performing Exchange Server maintenance. In previous versions of Exchange, we would have used the GUI for a load balancer to disable all new traffic from reaching a server. In Exchange 2013 load balancing, we can simply use a command on Exchange to put the Client Access Role into maintenance:
Set-ServerComponentState <Server Name> -Component ServerWideOffline -State Inactive -Requester Maintenance
As HAProxy is using the parts of Exchange to monitor services, it will automatically mark the server as Down while maintenance is performed.
When maintenance is finished, use this command to mark the server as Active again. HAProxy will pick this up and begin routing requests.
Set-ServerComponentState <Server Name> -Component ServerWideOffline -State Active -Requester Maintenance
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners, Phoenix IT Group. Goodman has worked in the IT industry for 14 years and has worked extensively with Microsoft Exchange since version 5.5.
This was first published in December 2013