Scaling Beyond the Single Server: High Availability with HAProxy on CentOS 6

Let’s be honest: relying on a single dedicated server for a production workload in 2012 is professional suicide. I’ve seen it happen too many times. You configure a perfectly tuned LAMP stack, Apache is serving pages, and life is good. Then, marketing sends out a newsletter, or you get featured on a major news portal. Suddenly, your load average spikes to 50, swap thrashing kills your I/O, and your site goes dark. Your client calls you at 3 AM asking why they are losing money every second.

If you are serious about uptime, you need to stop vertical scaling and start scaling horizontally. In this guide, we are going to deploy HAProxy 1.4—the gold standard for open-source load balancing—sitting in front of a cluster of web servers. We will look at why this setup, running on CoolVDS KVM instances, provides the redundancy your infrastructure demands.

Why Nginx and Apache Aren’t Enough

While Nginx is making waves as a lightweight web server and simple proxy, HAProxy (High Availability Proxy) is a specialized tool designed for one thing: shifting packets with minimal latency. It doesn't serve static files; it doesn't run PHP. It routes traffic. And it does so with incredible efficiency.

In a typical Norwegian setup, latency is king. If your users are in Oslo or Bergen, you want your termination point to be local. Routing traffic through a cheap VPS in Germany adds 30ms you can't afford when you're dealing with real-time bidding or high-frequency transaction systems.

The Architecture

We will build a simple, robust cluster:

• Load Balancer (LB1): HAProxy + Keepalived (Master)
• Load Balancer (LB2): HAProxy + Keepalived (Backup)
• Web Nodes: Two or more Apache/Nginx servers handling the application logic.

We use Keepalived with VRRP (Virtual Router Redundancy Protocol) to share a virtual IP (VIP) between the two load balancers. If LB1 dies, the VIP floats instantly to LB2.

Step 1: Installing HAProxy on CentOS 6.2

First, ensure you are running a clean minimal install of CentOS 6. The EPEL repository usually has a decent version, but for production, I prefer compiling from source or using a trusted repo to get the latest 1.4 stable branch.

# yum install haproxy
# chkconfig haproxy on

Step 2: The Configuration (`/etc/haproxy/haproxy.cfg`)

This is where the magic happens. We configure HAProxy to listen on port 80 and distribute traffic using a leastconn algorithm, which is generally superior to Round Robin for web apps where request times vary.

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

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

frontend  main_webapp
    bind *:80
    default_backend app_servers

backend app_servers
    balance     leastconn
    server  web1 10.10.1.10:80 check inter 2000 rise 2 fall 5
    server  web2 10.10.1.11:80 check inter 2000 rise 2 fall 5
    # Maintenance server for downtime
    server  backup 127.0.0.1:8080 backup

Pro Tip: Notice the `option http-server-close`. This tells HAProxy to close the connection to the backend server as soon as the response is complete, while keeping the connection to the client open. This significantly reduces the memory footprint on your Apache backends.

Persistence and Sticky Sessions

One major pain point in 2012 web development is session handling. If you are running a PHP application that stores sessions in `/tmp` (files), you will break user logins when HAProxy bounces them between web1 and web2.

You have two options:

1. Centralized Session Storage: Use Memcached or a database to store sessions. This is the architectural "right way."
2. Sticky Sessions (Cookie Insertion): If you can't rewrite the code, let HAProxy handle it.

To enable sticky sessions, modify your backend block:

backend app_servers
    balance     roundrobin
    cookie      SERVERID insert indirect nocache
    server      web1 10.10.1.10:80 check cookie web1
    server      web2 10.10.1.11:80 check cookie web2

Now, HAProxy will inject a cookie named SERVERID. Subsequent requests from that browser will contain the cookie, and HAProxy will route them to the same server.

The Hardware Reality: Why CoolVDS KVM Matters

You might be tempted to run this setup on cheap OpenVZ containers. Don't. In a shared kernel environment (like OpenVZ), you don't have full control over the TCP stack. Sysctl tuning parameters like net.ipv4.ip_nonlocal_bind (crucial for Keepalived VIPs) can be restricted.

At CoolVDS, we use KVM (Kernel-based Virtual Machine) virtualization. This gives you a true, isolated kernel. Furthermore, load balancing is I/O intensive—not disk I/O, but network I/O. Our infrastructure in Norway is connected via premium upstream providers, ensuring that your packets don't get dropped when the traffic spikes.

Performance Tuning for High Load

Before you go live, you need to tune the kernel on your load balancer. Add these to /etc/sysctl.conf:

# Allow binding to non-local IPs for Failover
net.ipv4.ip_nonlocal_bind = 1

# Increase the range of ephemeral ports
net.ipv4.ip_local_port_range = 1024 65000

# Enable TCP SYN cookies to protect against SYN floods
net.ipv4.tcp_syncookies = 1

# Time to wait for a FIN packet
net.ipv4.tcp_fin_timeout = 30

Run sysctl -p to apply. This configuration helps mitigate basic DOS attacks and ensures your connection table doesn't fill up during a traffic surge.

Data Sovereignty and The "Patriot Act" Problem

Here in Norway, privacy is taken seriously. The Datatilsynet (Data Protection Authority) enforces strict guidelines on how personal data is handled. With the cloud booming, many CTOs are unknowingly sending customer data to US-owned servers, subjecting it to the US Patriot Act.

By hosting on CoolVDS within Norwegian borders, you ensure that your data remains under Norwegian jurisdiction, adhering to the Personal Data Act (Personopplysningsloven). This isn't just about compliance; it's about trust. Your customers want to know their data isn't being sifted through by foreign agencies.

Conclusion

High availability isn't just for Google or Facebook. With open-source tools like HAProxy and robust infrastructure from CoolVDS, you can build a redundant, self-healing web cluster today. Stop waking up at 3 AM to reboot a crashed server.

Ready to harden your infrastructure? Don't let slow I/O kill your SEO or a single point of failure destroy your reputation. Deploy a KVM instance with fast SSD storage on CoolVDS today and build an architecture that lasts.