Learn HAProxy - Load Balancing Algorithms & Health Checks

#Introduction

When a request arrives, how does HAProxy choose a server? The answer has two parts: the load balancing algorithm that determines distribution, and the health check that ensures the chosen server is actually healthy.

Episode 5 covers both thoroughly. You'll know when to use roundrobin versus leastconn, how active and passive health checks work, and how to set up backup servers so the service stays up when primary servers fail.

#Load Balancing Algorithms

#roundrobin: Alternating Distribution

This is the default and simplest algorithm: each server is served in turn according to its weight. Suitable for almost every HTTP case with homogeneous servers.

backend web_back
    balance roundrobin
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check weight 2

The balance roundrobin directive turns on rotating distribution, and server web2 10.0.0.12:80 check weight 2 gives double weight so web2 receives a larger share of traffic.

#leastconn: Prioritize the Least Loaded Server

For long-lived connections — streaming, WebSocket, or applications that keep connections open — leastconn is fairer:

backend ws_back
    balance leastconn
    server ws1 10.0.0.21:9000 check
    server ws2 10.0.0.22:9000 check

balance leastconn sends new requests to the server with the fewest active connections. This prevents one server from piling up long-lived connections.

#source: Persistence Based on IP

The source algorithm maps a client IP to a server consistently through hashing. The same client always goes to the same server, as long as the server pool doesn't change:

backend cache_back
    balance source
    hash-type consistent
    server cache1 10.0.0.31:80 check
    server cache2 10.0.0.32:80 check

hash-type consistent reduces mapping jumps when servers are added or removed — important for a cache layer.

#uri: Routing Based on a URL Part

For CDNs or content caching, uri hashes part of the URI so that requests for the same content always go to the same server:

backend static_back
    balance uri
    hash-type consistent
    server s1 10.0.0.41:80 check
    server s2 10.0.0.42:80 check

balance uri is a good fit when per-server local caches can be exploited to the fullest.

#Active Health Checks

#Definition and Configuration

An active health check is a probe that HAProxy initiates periodically toward backend servers. For HTTP, use option httpchk to request a specific endpoint:

backend api_back
    option httpchk GET /healthz
    http-check expect status 200
    server api1 10.0.0.51:8080 check inter 3s fall 3 rise 2

The option httpchk GET /healthz directive tells HAProxy to request the /healthz path. The keywords check inter 3s fall 3 rise 2 mean the check runs every 3 seconds, a server is considered down after 3 failures, and healthy again after 2 successes.

#Server Status

The order of status marking on a server that fails its health check:

• UP: server is healthy and receiving traffic.
• DOWN: server has failed and receives no traffic.
• MAINT: server is manually removed for maintenance.
• DRAIN: server receives no new traffic, but existing connections are finished.

Status can be seen on the stats page (episode 7) or via the runtime API (episode 9).

#Passive Health Checks

#Detecting Failures from Real Traffic

A passive health check sends no probes; it judges failures from requests that actually happen. The main directives are maxconn per server and fall at the connection level. When a connection to a server fails, HAProxy counts it as a failure and can take the server down.

backend api_back
    server api1 10.0.0.61:8080 maxconn 2000
    server api2 10.0.0.62:8080 maxconn 2000

The server api1 10.0.0.61:8080 maxconn 2000 directive limits connections per server; if a server refuses additional connections, HAProxy chooses another server. Combining active and passive checks provides layered defense.

#Adjusting Failure Tolerance

Common tuning defaults:

• inter: interval between probes.
• fall: number of failures before a server is considered DOWN.
• rise: number of successes before a server returns to UP.
• timeout connect: connection timeout to the server.

#Failover with Backup Servers

#Backup Server Configuration

A backup server receives traffic only when all primary servers are DOWN. It's the last layer before the service actually dies:

backend web_back
    balance roundrobin
    option httpchk GET /healthz
    server web1 10.0.0.71:80 check
    server web2 10.0.0.72:80 check
    server dr 10.0.0.99:80 check backup

A server with the backup keyword in server dr 10.0.0.99:80 check backup is only active when all primary servers fail their health checks. The backup can be a server in another region or minimal capacity.

#Testing Failover

To test, shut down all primary servers and see whether traffic moves to the backup:

sudo systemctl stop python-http-8080
curl -s http://localhost/ | head -n 1

curl -s http://localhost/ | head -n 1 shows the response from the serving server. If all primaries are down and the backup is alive, the answer must come from the backup.

#Closing

Episode 5 gives you the two core controls of load balancing: algorithms for the right distribution and health checks for trustworthy availability. Their combination determines the quality of service your users experience.

Key takeaways:

• roundrobin for general distribution; leastconn for long connections.
• source and uri use hashing for IP- or URL-based persistence.
• Active health checks use periodic probes; passive ones use real traffic.
• Master inter, fall, and rise to set tolerance.
• Backup servers are the last safety net when all primary servers are DOWN.

In the next episode we'll cover HTTP routing, headers & rewrite — path-based and host-based routing, request and response header manipulation, redirects, and cookie-based persistence for session affinity.