Scaling Beyond the Single Server: Robust Load Balancing with HAProxy 1.4

It is 3:00 AM. Your pager is buzzing. The marketing team launched a campaign targeting Oslo commuters, and your single Apache server just hit MaxClients. The site is crawling, database locks are piling up, and latency has spiked from a crisp 20ms to a sluggish 5 seconds. If you have been in this industry as long as I have, you know that DNS round-robin is not a strategy; it is a bandage.

In 2010, relying on a single box for a production application is negligence. We need horizontal scalability. While hardware load balancers like F5 Big-IP are standard for enterprises with six-figure budgets, the rest of us in the Linux trenches have a weapon that is just as powerful and far more flexible: HAProxy.

This guide cuts through the noise. We aren't just installing packages; we are architecting a high-availability layer that sits in front of your web servers, intelligently routing traffic based on health, load, and application logic. We will look at deploying HAProxy 1.4 on CentOS 5.5, tuning it for the Linux 2.6 kernel, and why the underlying virtualization platform—specifically KVM on CoolVDS—matters for network throughput.

The Architecture: Why Layer 7 Matters

Many sysadmins stick to simple Layer 4 (TCP) balancing. It works, but it's blind. It forwards packets without understanding the request. HAProxy 1.4 shines at Layer 7 (HTTP mode). It inspects headers, terminates SSL (if using stunnel alongside it), and makes routing decisions based on the URL or cookies. This is critical for session persistence in PHP applications like Magento or Drupal.

Pro Tip: Never run your load balancer on the same physical hardware as your heavy database. Resource contention on the bus will kill your throughput. At CoolVDS, we isolate network I/O from disk I/O at the hypervisor level to prevent this "noisy neighbor" effect.

Step 1: Installation and Base Configuration

While `yum install haproxy` is easy, the repositories often lag behind. We want version 1.4 for the enhanced client-side keep-alive support. Let's compile from source to ensure we have the latest stable build.

wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.8.tar.gz
tar xzvf haproxy-1.4.8.tar.gz
cd haproxy-1.4.8
make TARGET=linux26 CPU=native USE_PCRE=1
make install

Once installed, we need to configure the logic. Create /etc/haproxy/haproxy.cfg. We will configure a standard setup: listening on port 80 and distributing to two backend web servers.

Step 2: The Configuration Meat

Here is a production-ready configuration block. Pay attention to the timeouts. Default timeouts are often too high, leaving sockets open during SYN flood attacks or slowloris attempts.

global
    log 127.0.0.1   local0
    maxconn 4096
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    retries 3
    option  redispatch
    maxconn 2000
    contimeout 5000
    clitimeout 50000
    srvtimeout 50000

frontend http_front
    bind *:80
    default_backend web_cluster

backend web_cluster
    mode http
    balance roundrobin
    option httpchk HEAD /health_check.php HTTP/1.0
    cookie SERVERID insert indirect nocache
    server web01 10.10.1.10:80 check cookie s1
    server web02 10.10.1.11:80 check cookie s2

Breakdown of Critical Flags

• balance roundrobin: Rotates requests evenly. If your servers have different specs (e.g., one legacy node, one new CoolVDS instance), use balance weighted.
• option httpchk: This is vital. HAProxy checks if the server is actually serving content, not just if the port is open. If Apache hangs but port 80 accepts connections, a TCP check passes, but an HTTP check fails. We want it to fail so traffic is rerouted.
• cookie SERVERID: Inserts a cookie to pin a user to a specific server. Essential for legacy PHP apps storing sessions in local /tmp files.

Step 3: Kernel Tuning for High Concurrency

A load balancer is only as fast as the kernel's TCP stack. The default Linux settings are conservative. To handle thousands of concurrent connections without hitting nf_conntrack limits, we must edit /etc/sysctl.conf.

Add these lines to allow for rapid recycling of TIME_WAIT sockets, a common issue when acting as a reverse proxy:

# Increase system-wide file descriptors
fs.file-max = 65535

# Allow reuse of sockets in TIME_WAIT state
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

# Increase port range for outgoing connections
net.ipv4.ip_local_port_range = 1024 65000

# Protect against SYN floods
net.ipv4.tcp_syncookies = 1

Apply these with sysctl -p.

War Story: The "Black Friday" Meltdown

Last year, I audited a setup for an e-commerce client hosting in Oslo. They had three web nodes but no intelligent balancing—just DNS round-robin. One node's SAS drive array degraded, causing I/O wait times to skyrocket. DNS kept sending 33% of the traffic to the dying server. Customers saw timeouts; the support line melted down.

We implemented HAProxy with the option httpchk configuration shown above. The moment the disk latency caused the health check script to time out (we set a strict 2-second limit on the script), HAProxy pulled the node from rotation. The remaining two nodes took the load, and the customers never noticed. That is the difference between a broken SLA and a quiet weekend.

The Hardware Reality: Latency and Compliance

Software configuration is only half the battle. In Norway, we have specific challenges. The Data Inspectorate (Datatilsynet) is strict about where personal data resides under the Personal Data Act. Hosting your load balancer or backends on cheap US-based VPS providers introduces legal gray areas regarding safe harbor, not to mention the 100ms+ latency penalty.

When you deploy a load balancer, network jitter is the enemy. You need a host connected directly to the NIX (Norwegian Internet Exchange). Furthermore, virtualization overhead can kill packet processing rates. This is why at CoolVDS, we use KVM (Kernel-based Virtual Machine) rather than older container technologies like Virtuozzo. KVM gives us a true kernel, allowing for the precise TCP tuning we detailed above.

Conclusion

High availability isn't about buying more servers; it's about intelligent routing. HAProxy 1.4 provides the logic, but the stability of the foundation is up to your provider. If your current host throttles your packets or runs on oversubscribed SATA arrays, no amount of configuration will save you.

For your next deployment, ensure your infrastructure is as robust as your code. Test your load balancing setup on a platform built for low-latency ops.

Ready to build a cluster that doesn't sleep? Deploy a high-performance SSD VPS on CoolVDS today and keep your traffic flowing.