Linux Labs
Where to start First steps track · 15 stages
Linux Labs
EN

keepalived — high availability with VRRP

4 min Ubuntu 24.04 · keepalived

High availability through a virtual IP — failover between nodes using VRRP.

Cheat sheet

2 commands Printable version
  • ip a | grep VIP which node is MASTER right now
  • journalctl -u keepalived -f state transitions
  • conf: state MASTER/BACKUP · virtual_router_id (same on all nodes) · priority · virtual_ipaddress
  • service check: vrrp_script + track_script (a negative weight)
  • split-brain → firewall VRRP through (proto 112, 224.0.0.18) or use unicast_peer

Overview

keepalived provides high availability: two or more nodes share a virtual IP (VIP) using the VRRP protocol. Normally the VIP sits on the MASTER; if it goes down, the VIP automatically moves to the BACKUP. Often paired with haproxy/nginx.

bash 
systemctl status keepalived
ip a | grep <VIP>                 # which node currently holds the VIP (see ip)
journalctl -u keepalived -f       # MASTER/BACKUP transitions in real time

Configuration

4

/etc/keepalived/keepalived.conf (on the MASTER):

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51        # SAME on every node in the group, unique on the L2 segment
    priority 100                # higher = preferred MASTER
    advert_int 1
    authentication { auth_type PASS; auth_pass secret }
    virtual_ipaddress { 10.0.0.10/24 }
}

On the BACKUP — the same, but state BACKUP and priority 90.

Directive Meaning
priority weight in the MASTER election (higher wins)
nopreempt don't take the VIP back on return (avoid extra flips)
unicast_peer VRRP over unicast (clouds/networks without multicast)
vrrp_script + track_script check a service → lower priority on failure

Nothing found. Try a shorter query.

Recipes

1

Checking a service

So the VIP moves when the application fails, not only when the whole node does:

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy"   # 0 = alive
    interval 2
    weight -20                              # down → priority -20 → BACKUP wins
}
vrrp_instance VI_1 {
    ...
    track_script { chk_haproxy }
}

Troubleshooting

5

VIP is up on both nodes at once (split-brain)

The nodes don't see each other's VRRP advertisements. The cause is the firewall blocking VRRP (protocol 112, multicast 224.0.0.18) or a mismatched virtual_router_id. Allow VRRP between the nodes; in a cloud without multicast, use unicast_peer.

The VIP doesn't move when the application fails

There's no track_script — the VIP stays as long as the node is alive, even if the service died. Add a vrrp_script/track_script with a weight.

The VIP "flaps" back and forth

The vrrp_script is too sensitive, or a recovered MASTER takes the VIP back. Set nopreempt on the BACKUP nodes, or increase interval/fall/rise.

virtual_router_id conflict

Within one L2 segment, virtual_router_id must be unique per group; a clash with another group breaks the election.

Where's the VIP right now, what's happening

ip a on each node (the VIP only shows on the MASTER), journalctl -u keepalived for the state transitions (see ip).

See also

  • haproxy — Load balancing and TCP/HTTP proxying — backends, health checks, statistics.
  • ip — Manage interfaces, addresses and routes (iproute2) — the replacement for ifconfig/route.
  • firewall — Traffic filtering — simple ufw and low-level nftables.

Found an inaccuracy? Report an error in the article

Topics
Loading…