HAProxy + Keepalived: Fault-Tolerant Load Balancer Setup

When your load balancer becomes a single point of failure, even a reliable service can suddenly stop. We configure a fault-tolerant HAProxy and Keepalived pair that automatically switches traffic to a backup node in case of failure. Our team delivers the project turnkey—from configuration to testing—ensuring stable operation and ongoing support.

Our competencies:

Frequently Asked Questions

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1365
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1330
  • B2B Advance company logo design
    B2B Advance company logo design
    776
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1077
  • AIDER company logo development
    AIDER company logo development
    1022
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1113

HAProxy + Keepalived: Building a Fault-Tolerant Load Balancer

In this guide, we walk through HAProxy configuration and Keepalived configuration to build a fault-tolerant load balancer that ensures 99.9% uptime. This HAProxy Keepalived cluster provides high availability load balancing with VIP automatic failover and sticky sessions via HAProxy peers replication.

Typical situation: you run microservices across several servers, but any load balancer remains a single point of failure. One network-level crash — and the whole application becomes unavailable. The solution is a bundle of HAProxy 2.8+ and Keepalived 2.2+ with VRRP: the first balances traffic, the second holds a Virtual IP and automatically switches it to a backup node if the active one fails. This architecture gives a failover time of 1-3 seconds and up to 70% savings compared to cloud LBs under steady loads starting at 10,000 RPS. For example, a project with 10,000 RPS saves $5,000 annually. Another client with 50,000 RPS saved $24,000 in the first year.

Our team of certified DevOps engineers with 10+ years of experience has completed over 50 projects configuring such schemes. We set up the entire system: two physical or virtual servers with HAProxy, Keepalived, and state synchronization. The client always accesses the VIP, which lives on the healthy node. In this article I'll show the configuration we use in production — with real timings, health checks, and session replication.

How VRRP Ensures Failover

Keepalived uses the VRRP protocol. According to RFC 5798, the active node (MASTER) sends multicast messages at an interval of advert_int (default 1 second). The backup node (BACKUP) listens for these messages. If BACKUP does not receive them for three intervals, it transitions to MASTER and captures the Virtual IP via notify scripts. The failover time is about 1-3 seconds. This is enough for most applications.

The weight parameter in vrrp_script chk_haproxy allows dynamic priority changes. If HAProxy on the MASTER dies, the script reduces the priority by 30 (weight -30), and BACKUP becomes MASTER even if advert_int didn't trigger. This prevents the situation where HAProxy is dead but VIP remains on it.

Why HAProxy Peers Are Critical for Sticky Sessions

If you use session affinity (sticky sessions), the session table is stored locally on each node. When the active node fails, the table is lost, and all clients are redirected to new servers — sessions are broken. HAProxy Peers replicates stick-tables between nodes via UDP in real time.

Example peers configuration:

peers haproxy_peers
    peer haproxy1 10.0.0.1:1024
    peer haproxy2 10.0.0.2:1024

backend app_servers
    balance roundrobin
    stick-table type ip size 200k expire 30m peers haproxy_peers
    stick on src

Now when VIP fails over, the backup node already has the current table and continues directing the client to the same backend. This is mandatory for e-commerce sites where cart status is tied to sessions.

Configuration and Nuances

Configuring HAProxy under load requires accounting for many parameters. For instance, maxconn 50000 — the limit of simultaneous connections; exceeding it will drop new connections. We recommend using httpchk GET /healthz expecting 200 OK to exclude servers that fail health checks.

An important parameter is slowstart 30s for backends. After a server recovers, HAProxy gradually increases the number of requests sent to avoid overwhelming the freshly started application. This prevents cascading failures.

Keepalived configuration on MASTER:

global_defs {
  router_id haproxy1
  enable_script_security
}

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

vrrp_instance VI_HAPROXY {
  state MASTER
  interface ens3
  virtual_router_id 60
  priority 200
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass hapassword
  }
  virtual_ipaddress {
    10.0.1.100/24 dev ens3 label ens3:vip
  }
  track_script {
    chk_haproxy
  }
  notify_master "/etc/keepalived/haproxy-master.sh"
  notify_backup "/etc/keepalived/haproxy-backup.sh"
}

On BACKUP — same parameters but state BACKUP and priority 100. Notify scripts start HAProxy if it was not running. For maximum reliability, we use keepalived -D and set up monitoring via Prometheus + Alertmanager.

Comparison: HAProxy+Keepalived vs Cloud Load Balancers

Criterion HAProxy+Keepalived (on-prem) Cloud LB (AWS/GCP)
Cost under high loads Fixed (storage + license) Pay per traffic + per hour
Latency (p99) < 10 µs (bare-metal) 50-200 µs (virtualization)
Control Full (configs, versions) Limited (API, console)
Failover 1-3 sec 5-30 sec (depends on DNS/Anycast)

These savings are not theoretical: one of our clients reduced costs by 65%, saving $12,000 per year after migrating from AWS NLB to on-prem HAProxy+Keepalived.

Quick Start Steps

  1. Install HAProxy 2.8 from official repository.
  2. Configure /etc/haproxy/haproxy.cfg with the options above.
  3. Install Keepalived 2.2 from EPEL.
  4. Configure /etc/keepalived/keepalived.conf as shown.
  5. Enable and start both services.
  6. Test failover by stopping HAProxy on the master.

Checklist for Configuration Verification

  • Ensure HAProxy maxconn is set to at least the expected peak number of connections.
  • Verify health check: httpchk GET /healthz returns 200.
  • Set slowstart 30s for backends to avoid overload on recovery.
  • Configure vrrp_script chk_haproxy with weight -30 for dynamic priority.
  • Enable HAProxy Peers for stick-table replication.
  • Test failover: stop HAProxy on MASTER, measure switch time.

What's Included in the Work

  1. Infrastructure audit. Analyze current traffic, performance requirements, identify bottlenecks.
  2. Architecture design. Choose balancing algorithm, set up health checks specific to your application, calculate Keepalived parameters.
  3. Implementation. Install and configure HAProxy (including SSL termination, HTTP/2, slowstart), set up Keepalived with VRRP and notify scripts, integrate HAProxy Peers for sticky sessions.
  4. Failover testing. Simulate failures: HAProxy stop, network outage, node crash. Verify switch time and session integrity.
  5. Documentation and training. Deliver network diagram, configs, runbook for on-call engineer. Conduct administration and monitoring walkthrough (stats endpoint, socat).

Timeline Estimates

Task Duration
HAProxy + Keepalived, basic scheme 1 day
SSL termination + health checks + peers 1-2 days
Failover testing + documentation +0.5 day

The cost of turnkey setup starts from $720–1k (about $1,000), confirmed after audit. Our certified engineers with ten years of experience guarantee SLA 99.9% for the load balancer. Infrastructure savings reach up to 70% compared to cloud solutions under steady load.

Order an audit of your infrastructure — we will choose the optimal HAProxy+Keepalived configuration for your load. Get a consultation on HAProxy+Keepalived setup: we will evaluate your infrastructure. Contact us for a preliminary project assessment.