An active-passive load balancer setup doesn’t actually balance traffic; it sits on standby, ready to take over if the active one fails.
Let’s see this in action with a common HAProxy configuration for an active-passive pair.
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
frontend http_frontend
bind *:80
default_backend http_backend
backend http_backend
balance roundrobin
server web1 192.168.1.10:80 check
server web2 192.168.1.11:80 check
# This is the crucial part for active-passive
listen admin
bind *:8080
stats enable
stats uri /haproxy?stats
stats realm HAProxy\ Statistics
stats auth admin:SuperSecretPassword123
In this HAProxy configuration, the balance roundrobin directive is a bit of a red herring for the active-passive scenario. The real magic happens with HAProxy’s built-in health checks and its ability to manage server states. When HAProxy is configured with multiple server entries for the same backend, it monitors their health. If the primary server (web1 in this case) becomes unhealthy (e.g., stops responding to its health check on port 80), HAProxy will automatically stop sending traffic to it. In an active-passive setup, you’d typically have only one server entry initially, or you’d configure your backend such that only one server is ever active. For true active-passive, you’d use a mechanism like VRRP or Pacemaker to ensure only one HAProxy instance is active on the network. HAProxy itself, when running on two separate machines, will monitor its backend servers, not necessarily fail over its own instance to another machine. The stats section is your window into this.
The problem HAProxy solves here is ensuring that if one of your web servers goes down, traffic is seamlessly redirected to the remaining healthy server. Without this, an outage on one web server would mean a complete service interruption for users hitting that specific server. The check directive on each server line tells HAProxy to periodically ping or make a request to that server’s IP and port. If the check fails for a configured number of attempts, HAProxy marks that server as DOWN.
The mental model here involves two layers of availability. First, you have your backend application servers (e.g., web1, web2). HAProxy sits in front of these, acting as a single point of contact for clients. If web1 fails, HAProxy detects it via health checks and stops sending traffic there, directing it entirely to web2. This is the backend failover. For load balancer failover (active-passive), you’d have two HAProxy instances. One is actively forwarding traffic, the other is in standby. A separate high-availability clustering solution (like Keepalived with VRRP, or Pacemaker/Corosync) is responsible for detecting the failure of the active HAProxy instance and promoting the passive one to become active. This usually involves moving a virtual IP address from the failed instance to the standby instance.
The part most people miss about active-passive load balancer setups is that the load balancer itself needs high availability. HAProxy, in its default configuration on two separate machines, provides backend server failover. It does not automatically provide failover of the HAProxy process between the two machines. That requires an external mechanism like VRRP (Virtual Router Redundancy Protocol) managed by Keepalived, or a more robust cluster manager like Pacemaker. This external tool is what ensures that if the primary HAProxy machine dies, the standby machine takes over its IP address and starts processing traffic.
The next concept to explore is active-active load balancing, where both instances actively serve traffic simultaneously.