Scaling Past the Breaking Point: High-Availability Load Balancing with HAProxy on CentOS 6

It starts with a slow page load. Then a timeout. Then your phone starts buzzing at 3:00 AM. Your database is locked, your Apache workers are maxed out, and your single frontend server just gave up the ghost under the weight of a marketing campaign that went better than expected. If you are relying on a single entry point for your web infrastructure in 2012, you are architecting for failure.

I’ve seen it happen too many times. A client hosts a perfectly good Magento store on a generic VPS, gets featured on a major news outlet, and the site vanishes instantly. The solution isn't just "add more RAM." The solution is horizontal scalability and intelligent traffic distribution.

Today, we are going to look at the industry standard for software-based load balancing: HAProxy. We will pair it with Keepalived for failover, ensuring that even if a load balancer dies, your traffic keeps flowing. And we’re going to do it on the stability of CentOS 6.

The Hardware Load Balancer Myth

For years, the "Enterprise" answer was to buy a pair of F5 BigIP hardware boxes, rack them up, and pay five figures for the privilege. That era is ending. With the raw compute power available in modern KVM-based virtualization, commodity Linux servers can push 10Gbps of traffic without breaking a sweat, provided the kernel is tuned correctly.

Why do we prefer software load balancing at CoolVDS? Control. You can script it, version control your config, and deploy it in seconds. Plus, when you are running on our high-performance SSD infrastructure in Norway, the bottleneck is rarely the disk or CPU—it's usually the configuration.

The Architecture: Avoiding the Single Point of Failure

We are going to set up an Active/Passive pair. You will need:

• 2x CoolVDS KVM Instances (CentOS 6.2 x86_64)
• Floating IP (VIP): An IP address that can move between servers.
• Backends: Your actual web servers (Apache/Nginx).

If the master Load Balancer (LB1) fails, Keepalived detects the heartbeat loss and moves the VIP to the backup (LB2) almost instantly. Users won't notice a thing.

Phase 1: Installing HAProxy 1.4

While the EPEL repositories are great, for high-performance production environments, I prefer compiling from source or using a trusted repo to get the latest stable patch. However, for the sake of this guide, the standard CentOS base is solid enough for starting out.

Now, let’s back up the default config and write a real one.

Here is a battle-tested configuration for handling HTTP traffic. This setup includes stats monitoring (vital for seeing who is hammering your site) and proper timeout handling to avoid zombie connections.

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4096
    user        haproxy
    group       haproxy
    daemon
    # Spread checks to avoid spiking load on backends simultaneously
    stats socket /var/lib/haproxy/stats

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
    bind *:80
    acl url_static       path_beg       -i /static /images /javascript /stylesheets
    acl url_static       path_end       -i .jpg .gif .png .css .js

    default_backend             app

backend app
    balance     roundrobin
    # Cookie insertion for session stickiness (crucial for PHP sessions)
    cookie      SERVERID insert indirect nocache
    server  web1 10.10.10.1:80 check cookie s1
    server  web2 10.10.10.2:80 check cookie s2
    
listen stats *:1936
    stats enable
    stats uri /
    stats hide-version
    stats auth admin:SuperSecretPassword

Phase 2: The Heartbeat (Keepalived)

HAProxy balances the traffic, but who watches HAProxy? Keepalived uses the VRRP protocol. Edit /etc/keepalived/keepalived.conf on the Master server:

vrrp_script chk_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    interface eth0
    state MASTER
    virtual_router_id 51
    priority 101
    virtual_ipaddress {
        192.168.1.200 # Your Public Floating IP
    }
    track_script {
        chk_haproxy
    }
}

On the Backup server, simply change state MASTER to state BACKUP and priority 101 to priority 100.

Tuning the Kernel for Heavy Traffic

A standard Linux install is tuned for desktop usage, not for handling 10,000 concurrent connections. If you don't tune sysctl.conf, you will run out of ephemeral ports or hit connection tracking limits. I recently debugged a cluster where the load balancer was dropping packets simply because the nf_conntrack table was full.

Add these to /etc/sysctl.conf and run sysctl -p:

# Allow reuse of sockets in TIME_WAIT state for new connections
net.ipv4.tcp_tw_reuse = 1
# Fast recycling (be careful with NAT, but usually safe inside a cluster)
net.ipv4.tcp_tw_recycle = 1

# Increase port range
net.ipv4.ip_local_port_range = 1024 65023

# Max syn backlog
net.ipv4.tcp_max_syn_backlog = 4096

# Protection against SYN flood
net.ipv4.tcp_syncookies = 1

Pro Tip: Monitor /proc/net/nf_conntrack during load tests. If the count nears your net.netfilter.nf_conntrack_max, your server will silently drop new users. CoolVDS instances come with optimized kernel templates, but you should always verify these limits manually.

The "Noisy Neighbor" Problem and KVM

Why does architecture matter? In the hosting world, you often get what you pay for. Many budget providers use OpenVZ (container-based virtualization). In an OpenVZ environment, the kernel is shared. If another customer on the same physical node gets hit with a DDoS attack, the context switching overhead can kill your HAProxy performance.

Latency is everything. When routing traffic from Oslo to a user in Bergen, every millisecond counts. We use KVM (Kernel-based Virtual Machine) at CoolVDS. This ensures that your RAM is your RAM, and your CPU cycles are dedicated. HAProxy is extremely CPU efficient, but it hates "steal time" (waiting for the hypervisor). With our setup, your load balancer operates with the predictability of bare metal.

Data Sovereignty and Datatilsynet

Operating in Norway isn't just about latency; it's about trust. With the growing concerns over the US Patriot Act and data privacy, keeping your infrastructure within Norwegian borders is becoming a compliance necessity for many businesses. Datatilsynet (The Norwegian Data Protection Authority) is very clear about the responsibilities of data handlers. By hosting on CoolVDS, your data resides physically in Oslo, subject to Norwegian law, providing a layer of legal safety that offshore cloud giants cannot guarantee.

Final Thoughts

Load balancing isn't just for Google or Facebook. In 2012, any business that relies on the web for revenue needs redundancy. HAProxy on CentOS 6 is a rock-solid combination that, when deployed on true KVM virtualization, offers enterprise stability at a fraction of the cost of hardware appliances.

Don't wait for your server to crash during the next holiday rush. Spin up two CoolVDS SSD instances today, configure your VRRP, and sleep soundly knowing your infrastructure can take the hit.

Ready to scale? Deploy your High-Availability Cluster on CoolVDS now.