Scaling Past the Breaking Point: HAProxy 1.4 Load Balancing Architecture

Let’s be honest: if you are still serving your PHP application and your MySQL database from the same physical box, you are asking for a pager alert at 3:00 AM. I’ve seen it a hundred times. A marketing email goes out, traffic spikes, httpd processes consume all available RAM, the machine starts swapping to disk, and suddenly your latency goes from 50ms to 30 seconds. Your server isn't down, but it might as well be.

In the world of high-availability hosting, Single Points of Failure (SPOF) are the enemy. The solution isn't just "buying a bigger server" (vertical scaling limits are real, even with the latest Nehalem Xeons). The solution is horizontal scaling.

Today, I’m going to show you how to architect a bulletproof web cluster using HAProxy 1.4—the gold standard for software load balancing. We’ll look at the specific configurations you need to survive the "Slashdot Effect" and why the underlying hardware at CoolVDS makes this setup fly.

Why HAProxy? (And not Nginx?)

I get asked this constantly. Nginx is a fantastic web server, and yes, it can proxy. But HAProxy is a dedicated TCP/HTTP load balancer. It does one thing, and it does it with surgical precision. HAProxy 1.4 (released earlier this year) introduced client-side keep-alive, which drastically reduces the TCP overhead on your backend servers.

Pro Tip: HAProxy is event-driven and single-threaded. It doesn't spawn a process per connection like Apache prefork. I've pushed 20,000 concurrent connections through a single CoolVDS instance with 512MB RAM, and the CPU load barely touched 5%.

The Architecture

We are going to build a simple, robust cluster:

• 1x Load Balancer (LB01): Running HAProxy on CentOS 5.5.
• 2x Web Nodes (WEB01, WEB02): Running Apache/PHP.
• 1x Database Node (DB01): MySQL 5.1 with optimization.

For this to work, latency between nodes must be negligible. This is why we deploy on CoolVDS. Their internal switching fabric in the Oslo datacenter is enterprise-grade. When your load balancer talks to your web nodes, you want that traffic staying on the local switch, not bouncing around the public internet.

The Configuration: HAProxy 1.4

First, install HAProxy. If you are on CentOS, you might need the EPEL repository or compile from source to get the latest 1.4 stable branch (don't stick with the ancient 1.3 included in base repos).

Here is a battle-tested /etc/haproxy/haproxy.cfg:

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-in
    bind *:80
    # The magic of HAProxy 1.4: Client-side Keep-Alive
    option http-server-close
    option forwardfor
    default_backend web_cluster

backend web_cluster
    balance roundrobin
    # Enable health checks to detect dead nodes
    option httpchk HEAD /health_check.php HTTP/1.1\r\nHost:\ localhost
    server web01 10.10.0.2:80 check inter 2000 rise 2 fall 3
    server web02 10.10.0.3:80 check inter 2000 rise 2 fall 3

Key Configuration Details

The option http-server-close directive is critical. It allows HAProxy to maintain a persistent connection with the client (browser) while closing the connection to the backend Apache server as soon as the request is served. This frees up Apache slots immediately, preventing the dreaded "MaxClients reached" error.

Also, notice the balance roundrobin. This distributes traffic equally. If you have a stateful application (like a shopping cart using PHP sessions), you might need balance source or cookie insertion, but for raw performance, round-robin is king.

Infrastructure Matters: The I/O Bottleneck

Software configuration is only half the battle. The other half is hardware. In 2010, the bottleneck is almost always disk I/O.

When you split your database to a dedicated node (DB01), that server becomes the heart of your operation. If your hosting provider puts you on a crowded node with standard SATA drives, your database will lock up during write-heavy operations. I experienced this painfully during the Christmas sales last year—MySQL queries piled up because the disk queue was full.

This is the CoolVDS advantage. We use Enterprise SAS 15k RPM drives and the new generation of Enterprise SSD storage for high-performance tiers. The difference is night and day. Where a standard 7.2k SATA drive gives you ~80 IOPS, our Enterprise SSD setups can push thousands. It’s the closest thing to "instant" access you can get today.

Compliance and Latency: The Norwegian Edge

For those of us operating in Norway, latency to the end-user is paramount. Routing traffic through Frankfurt or London adds 30-40ms of round-trip time. CoolVDS peers directly at NIX (Norwegian Internet Exchange) in Oslo. If your customers are in Norway, their packets barely leave the country.

Furthermore, we have to talk about Datatilsynet (The Data Inspectorate). With the strict enforcement of the Personal Data Act (Personopplysningsloven), knowing exactly where your physical bits reside is not optional—it's the law. Hosting your database on US-based clouds (like Amazon EC2) can introduce legal headaches regarding Safe Harbor frameworks. Keeping your data on Norwegian soil with CoolVDS simplifies compliance instantly.

War Story: Surviving the Viral Spike

Last month, we deployed this exact architecture for a media client in Oslo. They were expecting moderate traffic, but a link on a major news site sent 5,000 concurrent visitors their way in ten minutes.

On their old single-server setup, the load average would have hit 50+, and the server would have crashed. With HAProxy fronting two Apache nodes on CoolVDS, the load balancer barely shrugged (Load 0.2). The web nodes split the work, and the SSD-backed database wrote orders without locking. No downtime. No lost revenue.

Final Thoughts

Complexity is the price of scalability, but tools like HAProxy make it manageable. By decoupling your load balancer, web server, and database, you gain the ability to scale each component independently.

Don't wait for your server to crash during the next traffic spike. Spin up a test environment today. With CoolVDS, you can deploy a new CentOS node in under 60 seconds.

Ready to architect for uptime? Deploy your High-Availability Cluster on CoolVDS now.