Stop Letting Traffic Spikes Kill Your Sleep: The HAProxy Reality Check

It’s 3:15 AM on a Saturday. Your phone is buzzing off the nightstand. It's Nagios. Again. Your primary Apache server has hit MaxClients, the load average is sitting at 25.0, and swap usage is climbing faster than heating bills in an Oslo winter. If you are running a single-server setup in 2012, you are playing Russian Roulette with your uptime.

I've seen this happen too many times. A marketing campaign goes viral, and suddenly that "robust" dedicated server you leased melts under the pressure of 5,000 concurrent connections. The hardware isn't the problem; the architecture is.

Today, we are going to fix this. We aren't going to throw money at expensive hardware load balancers like F5 Big-IP. We are going to use HAProxy (High Availability Proxy). It is the gold standard for software load balancing—used by Reddit, Stack Overflow, and GitHub. It pushes packets faster than you can blink, and it runs beautifully on the pure KVM instances provided by CoolVDS.

The Architecture: Redundancy is Not Optional

The goal is simple: decouple the request entry point from the application logic. We are moving from one overworked server to a cluster.

• 1x Load Balancer Node: Runs HAProxy 1.4. Minimal resources needed (1 vCPU, 512MB RAM is often plenty).
• 2x Web Nodes: Running Apache 2.2 or Nginx. These do the heavy lifting.
• 1x Database Node: MySQL master (we'll cover replication another time).

This setup allows you to take down a web node for patching (security updates are critical, especially with the recent PHP vulnerabilities) without dropping a single user connection.

Step 1: Installing HAProxy on CentOS 6.3

First, log into your CoolVDS instance. We prefer CoolVDS here because they offer true KVM virtualization. Many budget hosts try to sell you OpenVZ containers, where "guaranteed RAM" is a lie and CPU steal time from noisy neighbors will kill your latency. With HAProxy, you need consistent CPU scheduling.

The standard repositories are often outdated. Let's make sure we have a decent version. If you have the EPEL repo enabled:

[root@lb01 ~]# yum install haproxy
[root@lb01 ~]# haproxy -v
HA-Proxy version 1.4.22 2012/08/09

If you need the bleeding edge features of 1.5-dev (like native SSL termination, though I still recommend terminating SSL on Nginx or Stunnel for stability), you'd need to compile from source. For production today, stick to 1.4 stable.

Step 2: The Configuration That Won't Fail

The default config is garbage for high traffic. We need to tune this for performance. Open /etc/haproxy/haproxy.cfg and backup the original.

The Global & Defaults Section

Here we define our process management and default timeouts. Timeouts are where most sysadmins mess up. If you leave them too high, dead connections eat your RAM. Too low, and slow mobile clients (3G is still spotty in rural Norway) get dropped.

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 prevents spikes on backend servers
    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

The Frontend & Backend

This is where the magic happens. We will set up a stats page (secured, obviously) so you can watch your traffic in real-time, and define our round-robin balancing.

listen stats_page
    bind *:8080
    stats enable
    stats uri /haproxy_stats
    stats realm Haproxy\ Statistics
    stats auth admin:SuperSecretPassword123

frontend main_http
    bind *:80
    default_backend app_servers

backend app_servers
    mode http
    balance roundrobin
    # Cookie insertion for session persistence (essential for PHP sessions)
    cookie SERVERID insert indirect nocache
    
    # Health checks: check index.html every 2 seconds
    server web01 10.0.0.2:80 check inter 2000 rise 2 fall 5 cookie web01
    server web02 10.0.0.3:80 check inter 2000 rise 2 fall 5 cookie web02

Pro Tip: Notice the cookie SERVERID directive? If you are running a PHP application like Magento or Drupal, you need session stickiness. Without this, a user adds an item to the cart on Server A, the next request hits Server B, and their cart is empty. This config injects a cookie so the user stays "stuck" to one server unless it dies.

Step 3: Sysctl Tuning for High Loads

HAProxy is efficient, but the Linux kernel needs help to handle thousands of state entries. If you don't tune sysctl, you'll run out of ephemeral ports. Add this to /etc/sysctl.conf:

net.ipv4.ip_local_port_range = 10000 65000
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 30

Run sysctl -p to apply. This is critical for avoiding the dreaded TIME_WAIT bucket overflow during a DDoS or a legitimate traffic spike.

Why Infrastructure Choice Matters

You can have the perfect HAProxy config, but if your underlying I/O is slow, your queue will back up. In traditional VPS hosting (spinning rust), disk I/O is the bottleneck. When logs are writing, databases are reading, and swap is thrashing, your 15k RPM SAS drives can't keep up.

This is where CoolVDS changes the equation. By utilizing high-performance SSD storage arrays and low-latency connectivity to the NIX (Norwegian Internet Exchange), the packet round-trip time is minimized. For users in Oslo or Trondheim, milliseconds matter. A request routed through a bog-standard host in Germany adds 30-40ms latency. Keeping it local on CoolVDS keeps it snappy.

Privacy and The Datatilsynet

Furthermore, running your infrastructure on Norwegian soil isn't just about speed; it's about compliance. With the Datatilsynet (Norwegian Data Protection Authority) keeping a close eye on how personal data is handled under the Personal Data Act (Personopplysningsloven), keeping your servers and logs within the country simplifies your legal standing compared to Safe Harbor reliance.

Testing the Failover

Don't trust your config until you break it. Start a continuous ping or `curl` loop to your load balancer IP.

1. SSH into web01.
2. Stop Apache: service httpd stop.
3. Watch the HAProxy stats page (port 8080). You should see web01 turn RED.
4. Check your curl loop. You shouldn't see a single error; HAProxy seamlessly redirects everything to web02.

If you see downtime, check your retries and fall parameters. You want failover to be fast, but not so sensitive that a single dropped packet marks a server as dead.

Final Thoughts

Redundancy isn't a luxury; it's an insurance policy. By placing HAProxy in front of your web tier, you gain the ability to scale horizontally. Need more power? Just spin up a new CoolVDS instance, run your Puppet manifest (or manual setup if you're old school), and add the line to the HAProxy config.

Don't wait for the next crash. Clone your current server, deploy a load balancer, and sleep through the night for once.

Ready to build a cluster that doesn't quit? Deploy a high-performance SSD VPS on CoolVDS today and start scaling.