Scaling Beyond the Box: High-Availability Load Balancing with HAProxy on CentOS
It starts with a text message at 3:14 AM. Nagios is screaming. Your primary web server has maxed out its RAM, swap is thrashing the disk, and your latency just hit 5 seconds. If you are running a high-traffic Magento store or a critical SaaS portal here in Norway, "downtime" isn't just an inconvenience—it is revenue bleeding out of the data center.
Most sysadmins try to solve this by throwing money at the problem: upgrading to a larger VPS instance. But vertical scaling has a hard ceiling. Eventually, you run out of RAM slots, or the cost of a monster node becomes unjustifiable. The only professional way forward is horizontal scaling.
Today, we are going to look at the industry standard for open-source load balancing: HAProxy 1.4. We will set up a robust, failover-ready architecture using CoolVDS instances, ensuring your traffic is distributed intelligently while keeping your data strictly within Norwegian borders.
The Architecture: Why HAProxy?
In 2011, you have a few choices for load balancing. You could buy a hardware appliance like an F5 Big-IP, which costs as much as a new car. You could use Apache's mod_proxy_balancer, but Apache's prefork model eats RAM for breakfast. Or, you can use HAProxy.
HAProxy (High Availability Proxy) is a single-threaded, event-driven, non-blocking engine. It pushes packets. That is all it does, and it does it faster than anything else on the market. It can handle tens of thousands of concurrent connections without eating your CPU alive.
Pro Tip: When provisioning your Load Balancer on CoolVDS, you don't need massive disk space. Focus on CPU speed and network throughput. A standard CoolVDS node with CentOS 5.6 or 6.0 is perfect. We recommend using our private networking interface (eth1) for backend traffic to avoid hitting your public bandwidth limits.
Step 1: Installation and Base Configuration
Let's assume you have three servers provisioned in our Oslo data center:
- LB01 (Load Balancer): Public IP + Private IP 10.10.0.10
- Web01 (Backend): Private IP 10.10.0.11
- Web02 (Backend): Private IP 10.10.0.12
On your CentOS load balancer, grab the latest stable HAProxy package.
yum install haproxy
chkconfig haproxy onThe magic happens in /etc/haproxy/haproxy.cfg. The default config is often cluttered. Back it up, and let's start with a clean, production-ready configuration.
global
log 127.0.0.1 local0
maxconn 4096
user haproxy
group haproxy
daemon
# Spread checks to avoid spiking load on backends
spread-checks 5
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
listen app_frontend 0.0.0.0:80
mode http
stats enable
stats uri /haproxy?stats
stats realm Strictly\ Private
stats auth admin:SuperSecretPassword123
balance roundrobin
option httpclose
option forwardfor
# Session Stickiness (Crucial for PHP apps)
cookie SERVERID insert indirect nocache
server web01 10.10.0.11:80 check cookie w1 inter 2000 rise 2 fall 5
server web02 10.10.0.12:80 check cookie w2 inter 2000 rise 2 fall 5Breaking Down the Config
There are a few specific settings here that separate the amateurs from the pros.
1. The `balance roundrobin` Algorithm
This rotates requests sequentially: Web01, then Web02, then Web01. It is simple and stateless. However, if your application has long-running processes (like video encoding or heavy reports), you might prefer balance leastconn, which sends traffic to the server with the fewest active connections.
2. Session Persistence (`cookie SERVERID`)
If you are hosting an e-commerce site (like Magento or osCommerce), you cannot have a user's shopping cart session bouncing between servers. They will lose their cart items. The cookie SERVERID insert directive tells HAProxy to inject a cookie into the browser, ensuring the user sticks to the same backend server for the duration of their session.
3. Health Checks (`inter 2000 rise 2 fall 5`)
HAProxy checks your web servers every 2000ms. If a server fails 5 consecutive checks, it is removed from the rotation. No manual intervention required. When the server comes back up, HAProxy gently re-adds it.
Handling the Database Layer
Load balancing web servers is the easy part. The bottleneck usually shifts to the database. In a multi-server setup, you cannot store data on the local disks of Web01 or Web02. You need a centralized database server.
For high performance, we recommend a dedicated MySQL instance on CoolVDS using our high-performance SSD storage options. While standard SATA drives are fine for backups, your database needs the random I/O performance of Solid State Drives, especially when dealing with complex JOINs.
| Feature | Single Server | CoolVDS HA Cluster |
|---|---|---|
| Uptime | Single Point of Failure | Redundant Nodes |
| Scalability | Limited by hardware | Infinite (add more nodes) |
| Maintenance | Downtime required | Zero-downtime rolling updates |
The Norwegian Context: Latency and Law
Why host this on CoolVDS in Norway instead of a cheap US provider? Two reasons: Latency and Law.
If your customer base is in Oslo, Bergen, or Trondheim, speed of light matters. Ping times from Oslo to a US East Coast server are typically 100-120ms. On our infrastructure, peering directly at NIX (Norwegian Internet Exchange), that drops to <5ms. In the world of high-frequency trading or just snappy page loads, that is an eternity.
Furthermore, under the Norwegian Personal Data Act (Personopplysningsloven), you have strict obligations regarding where your user data lives. By keeping your architecture local, you simplify compliance with Datatilsynet and ensure you aren't caught up in foreign data jurisdiction disputes.
Next Steps: High Availability for the Load Balancer
You might notice a flaw: "What if the Load Balancer itself dies?"
That is where Keepalived and the VRRP protocol come in. By setting up a secondary HAProxy node and sharing a virtual IP (VIP), you can create a fully redundant entry point. If the primary LB drops, the VIP floats to the secondary in less than a second.
Don't let your infrastructure be the bottleneck. Deploying a test cluster on CoolVDS takes less than 60 seconds. Spin up two small nodes, install HAProxy, and see the resilience for yourself.