Partial Spec Paper written by: David Raistrick, with Mary K Swanson

(Sample Chapter)

1 About HAProxy

HAProxy, written in C by Willy Tarreau, is open source software for TCP and HTTP load balancing. It’s known for stability, efficiency and speed; chances are that this reputation is why you are installing it.

Load balancing, though, is a term that covers a broad range of functions, from basic TCP tunneling at Layer 4 to reverse proxy at Layer 7, and you may find more functionality in HAProxy than you expected—or, more than you bargained for.

In this chapter, you’ll learn what HAProxy load balancing is and what it can do for your network, and learn the terms you’ll need throughout the instructions. After that, you’ll be ready to begin configuring HAProxy to support your network needs.

The current version of HAProxy is 1.4.

HAProxy Basics

Load balancers are not all the same. Some simply work at Layer 4, directing network traffic with no regard to payload. Others like HAProxy also operate at Layer 7, where requests can be routed based on content.

With HAProxy, you can have high availability, reverse proxy, and failover, use ACLs, generate status reports and monitor your system, but all of it depends on the load balancing function.

Load Balancing

A load balancer distributes network or application traffic across multiple servers, allowing more users to access the same resource simultaneously. HAProxy operates at Layer 4 (network and transport protocols, or tunneling) and Layer 7 (application layer protocols).

One Arm or Two?

There are two common load balancing setups. In the simplest, the traffic is passed through one interface only— a request goes in one door to the load balancer, out the same door to the server resources, then the response travels back through the same interface into the load balancer and out to the requestor. This is referred to as one arm. This is usually the easiest setup to use, but limits maximum available throughput.

One Arm Load Balancer (Image removed)

Most software load balancers use one arm, but there can be substantial performance benefits from using the other type of load balancer setup called two arm. In this type, two interfaces are used for traffic, with the request going through the first interface into the load balancer, out the second interface to the server resources, and the response moving back through each of the two interfaces on its way back to the requestor. In order to use two (or more) arm infrastructures, the network routing topology needs to be changed, and the server running the load balancer software needs to be reconfigured as a router.

Two Arm Load Balancer (Image removed)

Select Terms

These terms will be useful as you read this document and begin setting up your own HAProxy load balancer.

ACL

ACLs are access control lists. They provide the ability to allow or deny access based on request content. HAProxy allows you to create and administer Layer 7 ACLs for your application, content switching routing/directing traffic based on ACLs.

DoS and DDoS

DoS and DDoS stand for denial of service and distributed denial of service. A DoS is an assault on a network that floods it with so many additional requests that regular traffic is either slowed or completely interrupted. A DDoS uses multiple computers throughout the network. HAProxy defends against these attacks by decoupling the client connection and request from the servers, queuing requests in front of busy servers, allowing you to fine tune details like timeouts and connection limits, and adding/testing against custom cookies. HAProxy 1.5 will include even more features.

Failover

Failover is the process by which a system, detecting the failure of one server, automatically reroutes any traffic to the other remaining servers in the group. If the application is stateful, the system remembers the state of each connection, creating a seamless experience for users of the system. HAProxy’s load balancing function allows you to set up automatic failover, ensuring that your network is always available.

High Availability

High availability is the term for a multiprocessing system that can quickly recover from a failure. There may a minute or two of downtime while one system switches over to another, but processing will continue. Another term for this is fault resilient.

One Arm and Two Arm

The terms ‘one arm’ and ‘two arm’ refer to the two common load balancing setups. One arm uses only one interface on the load balancer for passing traffic, where two arm uses two interfaces, one on the way in to the load balancer and one on the way out. HAProxy can be used with either setup.

HTTP Keep-alives

HTTP keep-alives are persistent connections between the client and the server, allowing you to perform multiple requests on the same connection. HAProxy 1.4 supports keep-alives between the client and HAProxy, but not between HAProxy and the backend server.

Reverse Proxy

Reverse proxy for HTTP is another way of saying a proxy for the server side of a system rather than for the client side. Some load balancers offer reverse proxies; some reverse proxy setups offer load balancing. The terms reverse proxy and load balancing are sometimes used interchangeably because of how often they are found together. You can use HAProxy to set up a reverse proxy.

Stickiness

Stickiness refers to keeping all of a particular client’s traffic ‘stuck’ to a specific server. It is particularly useful for applications that are unable to share state information between multiple servers. Another term for stickiness is session persistence.

Tunnel

A tunnel for HAProxy simply passes all data for a connection transparently through the load balancer. For HTTP, this means that only the initial request will be inspected; all further requests on a connection will be passed through untouched. For TCP, only the source/destination addresses for the connection change.

Supported Platforms for HAProxy 1.4

HAProxy is known to function on the operating systems listed below. Other related platforms may be used, but are not supported by the developers.

Linux 2.4 on x86, x86_64, Alpha, SPARC, MIPS, PARISC; Linux 2.6 on x86, x86_64, ARM (ixp425), PPC64

Solaris 8/9 on UltraSPARC 2 and 3; Solaris 10 on Opteron and UltraSPARC

FreeBSD 4.10 to 8.4 on x86

OpenBSD 3.1 to 5.3 on i386, amd64, macppc, alpha, sparc64 and VAX (check the ports)