Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Par

Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Part 1

Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Part 1 - Introduction and lab description (this page)

Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Part 2 - Deploy and configure the PKI infrastructure

Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Part 3 - Configure and test the Exchange 2013 Client Access role

Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Part 4 - Install CentOS 7

Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Part 5 - Install and configure HAProxy

Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Part 6 - Make HAProxy highly availabile

Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Part 7 - Demo

In this series of articles I will demonstrate how to set up a HA pair of Layer 7 load balancers for Exchange 2013. The aim is to implement a low-cost, high performance, reliable load balancing solution using free software.

As we know, the need for Layer 7 load balancers has been removed with Exchange 2013. Layer 4 load balancers can be used and in most environments it is probably all you’ll ever need. However Layer 4 load balancers simply pass client traffic to the Exchange servers and haven’t got the capacity to inspect traffic content. Therefore health checks and load balancing decisions are limited.

With Layer 7 load balancers the SSL channel is terminated at the load balancer. The load balancer has full visibility over the traffic content. It therefore can perform more granular health checks, traffic inspection, and make smarter decisions. With a Layer 7 solution it is possible to detect and handle the failure of a single service. For instance, if the load balancer detects a failed EAS service while all other services are responsive on that same Exchange 2013 server, then it can re-target EAS traffic to a healthy service on another server while sending all other traffic to the healthy services.

The various load balancing options with their pros and cons are nicely explained by Ross Smith IV here.

My test lab is based on HAProxy running on a minimal installation of CentOS 7.

This part is a brief presentation of the architecture and components of the test environment. Subsequent articles will target the installation, configuration and testing of each component.

Before I start, I want to make it very clear that the focus of this lab is on the technical solution. Naturally it can be improved in various ways, most notably in the area of security, in that all setup and management tasks in this lab are done using local and domain Administrator and root accounts. While I wouldn’t normally do it, and I would definitely advise against it in a production system, it is perfectly acceptable for the purpose of this lab.

The diagram below shows each server deployed in the lab.

HAProxy Lab Components

The servers provide the following functionality:

• LAB-DC01: domain controller and DNS server.
• LAB-EX01 and LAB-EX02: multi-role Exchange 2013 servers.
• LAB-CA01 and LAB-CA02: stand-alone root and intermediate CAs for the lab’s certificate requirements. I chose this configuration to simulate commercial CAs as closely as possible and to illustrate various CA-specific tasks to make things work.
• lab-hap01 and lab-hap02: latest stable HAProxy compiled from source, running on CentOS7 – the focus of this lab.
• LAB-WS01: mail client to test all supported access methods. For EAS testing I used the Windows Phone 8.1 emulator included with the Windows Phone 8.1 SDK.

With the exception of LAB-WS01, all other computers are virtual. Virtualising an EAS client in a virtual environment (hypervisor in a hypervisor) is not trivial and my environment doesn't allow me to do it. Therefore LAB-WS01 had to be physical.

Assumed knowledge:

• General administration skills of Microsoft Windows operating systems (any version and edition).
• General Linux administration skills. Red Hat flavour preferred.
• Deployment and configuration of domain controllers.
• Deployment and configuration of Exchange 2013 servers.
• Internet and infrastructure technologies used in this lab, including PKI concepts.

The more unusual components will have sufficient space dedicated throughout the article to illustrate how these components fit into the test solution.

The series is comprised of the following parts:

Part 1 – Introduction and lab description (this article). It deals with the overall architecture and scope of this lab.

Part 2 – Deploy and configure the PKI infrastructure. Describes the installation and configuration of the local PKI infrastructure that supports the lab.

Part 3 – Configure and test the Exchange 2013 Client Access role. This part deals with configuring the CAS role in particular. Database and transport aspects are not relevant as the focus is client access. As far as database and transport is concerned, defaults will be used, with some minimal customisation at transport level to fit the lab.

Part 4 – Install CentOS 7. This part walks you through the installation and initial configuration of CentOS 7 in the context of this lab.

Part 5 – Install and configure HAProxy. This part demonstrates the installation and configuration of the latest stable version of HAProxy from source. You'll find a good chunk of information about integrating it with the PKI infrastructure. Things change quickly in the Linux world, so don't panic if by the time you want to test this lab, there will be a newer version of HAProxy available. There is a good chance these instructions will work with that too.

Part 6 – Make HAProxy highly availabile. This part demonstrates the installation and configuration of keepalived and its integration with HAProxy.

Part 7 – Demo. This part demonstrates HAProxy’s service-level load balancing ability and a load balancer service failover within the HA pair in a simulated HAProxy failure.

By the time we reach the end of this first part, and before moving on to Part 2, the following components are assumed to be deployed, none of them covered in this series, as knowledge of doing it is assumed:

• LAB-DC01, a single server with the AD-DC and DNS Server roles. I deliberately chose different AD and SMTP domain names:

• lab.local – AD domain
• digitalbrain.com.au – Alternative UPN suffix and simulated publicly registered domain. The domain Administrator will have its UPN suffix set to this to match the primary SMTP e-mail address.
• NOTE: Ideally, all users with an Exchange mailbox should have their UPN configured to match their primary e-mail address, although in many cases this isn't possible because the logon name is different from the local part of the users' e-mail address.

Additional UPN Suffix

Mail User UPN (Administrator in this lab)

• LAB-EX01 and LAB-EX02, two servers with vanilla (default, unconfigured) multirole Exchange 2013 servers.
• LAB-CA01 and LAB-CA02, two vanilla workgroup servers.
• LAB-WS01, a single workgroup client computer with Office 2013 SP1 and the Windows Phone 8.1 emulator.

All computers, including the workstation, have statically configured network settings, as per the diagram. Lots of good stuff is coming, hopefully you’ll find it useful and informative.

This concludes Part 1. Keep tuned for the next part.

Highly Available L7 Load Balancing for Exchange 2013 with HAProxy – Part 1 - Introduction and lab description (this page)