Surviving the Spike: High Availability Load Balancing with HAProxy on CentOS 6

It starts with a creeping sluggishness. Then, the connection timeouts begin. Finally, your Apache processes hit the MaxClients limit, and your server simply vanishes from the internet. If you are running a single VPS for your mission-critical application, you aren't running a business; you are gambling.

I recently watched a client's e-commerce launch melt down because they bet everything on one massive server instance. They assumed vertical scaling—adding more RAM and CPU—would save them. It didn't. The moment the marketing email hit 50,000 inboxes, the disk I/O locked up, and the site went dark. The fix wasn't a bigger server; it was smarter architecture.

This is where HAProxy (High Availability Proxy) enters the equation. It is the de facto standard for open-source load balancing, capable of handling tens of thousands of concurrent connections without breaking a sweat. In this guide, we are going to set up a robust Layer 7 load balancer on CentOS 6 that can distribute traffic across multiple CoolVDS backend nodes, ensuring that if one server dies, your users never notice.

The Architecture: Why Local Latency Matters

Before we touch the config files, let's talk about topology. If your customers are in Oslo, Bergen, or Trondheim, routing your traffic through a data center in Frankfurt or Amsterdam adds unnecessary milliseconds to every request. In high-frequency trading or real-time bidding, this is fatal. Even for a standard web app, that latency compounds.

We deploy our load balancers directly in Norway. This ensures minimal hops to the NIX (Norwegian Internet Exchange). Furthermore, with the growing concerns over the US Patriot Act and data sovereignty, keeping your data within Norwegian borders satisfies the strict requirements of Datatilsynet (The Norwegian Data Protection Authority). You cannot afford to be lax with the Personal Data Act (Personopplysningsloven).

Step 1: Installation and Base Configuration

We will stick to the stable branch. As of early 2012, HAProxy 1.4 is the battle-tested choice. Do not mess around with the 1.5 development snapshots in production unless you enjoy 3 AM wake-up calls.

[root@lb01 ~]# yum install haproxy
[root@lb01 ~]# chkconfig haproxy on

HAProxy works by defining frontends (what the internet sees) and backends (your pool of web servers). Open /etc/haproxy/haproxy.cfg using vi or nano.

The Global Section

First, we tune the global settings to handle high concurrency. The default file limit on many Linux distros is too low (1024). We need to bump this up.

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    # Spreading checks helps avoid spikes on backends
    spread-checks 3

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

Pro Tip: Always set option http-server-close. It enables HTTP keep-alive on the client side while closing the connection to the backend server after the request. This saves your backend Apache/Nginx slots for active processing rather than waiting on idle clients.

Step 2: Defining the Frontend and Backends

Here is where the magic happens. We will configure a frontend listening on port 80 and a backend pool with two web servers.

frontend  main *:80
    acl url_static       path_beg       -i /static /images /javascript /stylesheets
    acl url_static       path_end       -i .jpg .gif .png .css .js

    use_backend static          if url_static
    default_backend             app_servers

backend static
    balance     roundrobin
    server      static01 10.0.0.5:80 check

backend app_servers
    balance     roundrobin
    # Cookie insertion for session stickiness
    cookie      SERVERID insert indirect nocache
    server  web01 10.0.0.6:80 check cookie web01
    server  web02 10.0.0.7:80 check cookie web02

Understanding the Configuration

• Balance Roundrobin: Traffic is rotated sequentially. Request 1 goes to Web01, Request 2 to Web02, and so on.
• Check: HAProxy polls the server to see if it is alive. If Web01 stops responding to TCP requests, HAProxy automatically removes it from the pool. No human intervention required.
• Cookie SERVERID: This is critical for PHP sessions. It ensures that a user stays on the same backend server for the duration of their session. Without this, your users will get logged out randomly as they bounce between servers.

Step 3: Verification and Launch

Before restarting, verify your config syntax. A bad config will kill the service.

[root@lb01 ~]# haproxy -c -f /etc/haproxy/haproxy.cfg
Configuration file is valid

If valid, restart the service:

[root@lb01 ~]# service haproxy restart

You can now watch the logs in real-time to see traffic flowing:

tail -f /var/log/haproxy.log

The Hardware Reality: Why Virtualization Matters

Configuration is useless if the underlying infrastructure is unstable. I have seen providers pack 50 VPS instances onto a single host node using OpenVZ, overselling the RAM until the swap file screams for mercy. When your load balancer is fighting for CPU cycles just to route packets, you have added latency, not removed it.

This is why we architect CoolVDS differently. We rely on KVM (Kernel-based Virtual Machine) and Xen. These hypervisors provide true hardware virtualization. If you are allocated 4GB of RAM, that RAM is reserved for you. It isn't shared with the neighbor running a poorly optimized Minecraft server.

Storage I/O: The Bottleneck Killer

In 2012, disk I/O is still the most common bottleneck. Standard SATA drives struggle under the random read/write patterns of a busy database or log-heavy load balancer. While many hosts are still spinning 7.2k RPM drives, you need to look for providers offering Enterprise SSD or at least 15k RPM SAS arrays in RAID 10. High I/O throughput ensures your load balancer can write logs and handle state changes without locking up the CPU.

Conclusion

Redundancy is not a luxury; it is an insurance policy. By placing HAProxy in front of your application, you gain the ability to perform zero-downtime maintenance, survive server crashes, and scale horizontally as your traffic grows. But remember, a load balancer is only as good as the network it sits on.

If you are serious about uptime and need a compliant, low-latency foundation in Norway, don't settle for oversold shared resources. Build your cluster on a platform designed for professionals.

Ready to harden your infrastructure? Deploy a CoolVDS instance with SSD storage today and configure your first high-availability cluster.