keepalived und VRRP Grundlagen: Hochverfügbarkeit mit virtueller IP

1. Was VRRP löst und wofür keepalived steht

keepalived ist eine Linux-Implementierung des Virtual Router Redundancy Protocol, kurz VRRP, das ursprünglich für redundante Router entworfen wurde und sich seit Jahren genauso gut für hochverfügbare Loadbalancer, Datenbank-Server und Reverse Proxys einsetzen lässt. Das Grundproblem, das keepalived löst, ist simpel formuliert: Ein einzelner Server, der eine kritische IP-Adresse bedient, ist ein Single Point of Failure. Fällt er aus, ist der Dienst nicht mehr erreichbar, unabhängig davon, wie gut die Anwendung selbst abgesichert ist.

Die Idee hinter VRRP ist, dass mehrere Server sich eine sogenannte virtuelle IP-Adresse teilen, die niemals an eine feste Netzwerkkarte gebunden ist, sondern dynamisch demjenigen Knoten zugewiesen wird, der gerade als Master fungiert. Fällt der Master aus, übernimmt ein Backup-Knoten die virtuelle IP innerhalb weniger Sekunden, ohne dass Clients ihre Konfiguration ändern müssen. keepalived ist dafür in praktisch jeder Linux-Distribution als Paket verfügbar und benötigt keine spezielle Hardware, was es zu einer der kostengünstigsten Lösungen für Hochverfügbarkeit im Linux-Umfeld macht.

In produktiven Umgebungen wird keepalived häufig vor einem Loadbalancer-Paar wie HAProxy oder nginx platziert, um auch die Loadbalancer selbst redundant zu machen. Ohne diese Ebene wäre der Loadbalancer selbst wieder ein Single Point of Failure, egal wie viele Backend-Server dahinterstehen. Die folgenden Abschnitte erklären Schritt für Schritt, wie VRRP intern funktioniert, wie keepalived konfiguriert wird und welche Fallstricke in der Praxis auftreten.

2. Funktionsweise: Master, Backup und die virtuelle IP

VRRP organisiert eine Gruppe von Routern oder Servern in einem sogenannten VRRP-Instanz-Verbund. Jede Instanz hat eine eindeutige Virtual Router ID zwischen 1 und 255, die alle Knoten in derselben Gruppe teilen müssen. Innerhalb dieser Gruppe wird per Priority-Wert ein Master gewählt, der Standardwert liegt zwischen 0 und 255, wobei der höchste Wert gewinnt. Der Master sendet in regelmäßigen Abständen, standardmäßig alle Sekunde, Multicast-Pakete an die Adresse 224.0.0.18 aus, um seine Anwesenheit zu signalisieren.

Bleiben diese Advertisement-Pakete für einen definierten Zeitraum aus, wechseln die Backup-Knoten automatisch in den Master-Zustand und übernehmen die virtuelle IP-Adresse per Gratuitous ARP. Dieses ARP-Paket informiert alle Geräte im lokalen Netzwerksegment darüber, dass sich die MAC-Adresse hinter der virtuellen IP geändert hat, wodurch der Traffic ohne DNS-Änderung oder manuelle Eingriffe zum neuen Master umgeleitet wird. Genau dieser Mechanismus macht keepalived so attraktiv: Failover findet auf Netzwerkebene statt, transparent für jede Anwendung, die die virtuelle IP anspricht.

Wichtig zu verstehen ist, dass VRRP nur die IP-Adresse verwaltet, nicht den dahinterliegenden Dienst. Ein Server kann als VRRP-Master vollkommen gesund erscheinen, während der eigentliche Webserver oder die Datenbank auf diesem Knoten längst abgestürzt ist. Genau deshalb kombiniert man keepalived in der Praxis fast immer mit Health-Checks, die den tatsächlichen Dienstzustand prüfen und nicht nur die Netzwerkverbindung von keepalived selbst.

3. Installation und Basis-Konfiguration

Die Installation von keepalived ist auf den meisten Distributionen ein einzeiliger Paketbefehl. Nach der Installation liegt die zentrale Konfigurationsdatei unter /etc/keepalived/keepalived.conf und folgt einer eigenen, klammerbasierten Syntax, die an nginx-Konfigurationen erinnert. Der wichtigste Block ist vrrp_instance, in dem Interface, Virtual Router ID, Priority und die virtuelle IP-Adresse definiert werden.

Ein zentraler Konfigurationspunkt ist der Zustand state MASTER oder state BACKUP, der als Ausgangswert gilt, aber durch die tatsächliche Priority-Aushandlung jederzeit überschrieben werden kann. Das Authentifizierungsfeld auth_pass verhindert, dass fremde VRRP-Pakete im selben Netzwerksegment die eigene Gruppe stören, es ist aber kein kryptografischer Schutz, sondern eher ein Schutz vor versehentlichen ID-Kollisionen.

# Install keepalived on Debian/Ubuntu
sudo apt update && sudo apt install -y keepalived

# Install keepalived on RHEL/AlmaLinux
sudo dnf install -y keepalived

# Enable IP forwarding and non-local binding (needed on some kernels
# so the service can bind before the VIP is actually assigned)
sudo tee -a /etc/sysctl.conf <<'EOF'
net.ipv4.ip_nonlocal_bind = 1
EOF
sudo sysctl -p

# Enable and start the service after config is in place
sudo systemctl enable --now keepalived
sudo systemctl status keepalived

# /etc/keepalived/keepalived.conf on node1 (intended master)
global_defs {
    router_id node1
    enable_script_security
    script_user root
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass s3cr3tPass
    }
    virtual_ipaddress {
        192.168.10.100/24
    }
}

Auf dem zweiten Knoten wird dieselbe Konfiguration mit identischer Virtual Router ID, identischem auth_pass und derselben virtuellen IP übernommen, jedoch mit niedrigerer Priority und dem Zustand BACKUP. Diese Symmetrie ist entscheidend: Weicht die Virtual Router ID zwischen den Knoten ab, bilden sie zwei getrennte VRRP-Gruppen und keiner der beiden übernimmt jemals vom anderen.

4. Health-Checks mit vrrp_script

Damit keepalived nicht nur die Netzwerkerreichbarkeit, sondern auch den tatsächlichen Anwendungszustand prüft, dient der Block vrrp_script. Dort wird ein beliebiges Skript oder ein einzelner Shell-Befehl hinterlegt, der in einem festen Intervall ausgeführt wird. Liefert das Skript einen Exit-Code ungleich null, verringert keepalived die Priority des Knotens um den in weight festgelegten Wert, wodurch ein anderer Knoten mit höherer effektiver Priority automatisch zum Master aufsteigt.

Ein häufiges Beispiel ist die Prüfung, ob ein lokaler HAProxy- oder nginx-Prozess läuft und auf dem erwarteten Port antwortet. Anstatt nur zu prüfen, ob der Prozess existiert, ist eine echte HTTP- oder TCP-Anfrage aussagekräftiger, weil ein Prozess durchaus laufen, aber trotzdem hängen oder alle Worker-Threads verloren haben kann. Wichtig ist, die Health-Check-Intervalle nicht zu aggressiv zu wählen, weil zu kurze Intervalle bei kurzzeitigen Lastspitzen unnötige Failover auslösen können.

vrrp_script check_haproxy {
    script "/usr/bin/pgrep haproxy"
    interval 2      # check every 2 seconds
    weight -50      # subtract 50 from priority on failure
    fall 3          # require 3 consecutive failures before acting
    rise 2          # require 2 consecutive successes to recover
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass s3cr3tPass
    }
    virtual_ipaddress {
        192.168.10.100/24
    }
    track_script {
        check_haproxy
    }
}

5. Ein vollständiges Zwei-Knoten-Setup

In der Praxis wird keepalived meist in einem Paar von zwei Knoten betrieben, die entweder als aktiv/passiv-Datenbank-Setup oder als redundantes Loadbalancer-Paar vor mehreren Applikationsservern arbeiten. Beim aktiv/passiv-Modell übernimmt der Backup-Knoten die virtuelle IP nur, wenn der Master tatsächlich ausfällt, während im Alltag der gesamte Traffic ausschließlich über den Master läuft. Das ist konzeptionell einfacher zu betreiben als ein aktiv/aktiv-Setup mit zwei virtuellen IPs, bei dem beide Knoten gleichzeitig Traffic bedienen und wechselseitig als Backup füreinander fungieren.

Für ein aktiv/aktiv-Setup definiert man auf jedem Knoten zwei vrrp_instance-Blöcke mit unterschiedlichen Virtual Router IDs, wobei jeder Knoten für eine Instanz Master und für die andere Backup ist. Diese Konfiguration verdoppelt zwar den Konfigurationsaufwand leicht, nutzt aber beide Server im Normalbetrieb aus, statt einen Knoten im Leerlauf zu halten. Für Datenbank-Failover mit MySQL oder PostgreSQL empfiehlt sich hingegen meist das einfachere aktiv/passiv-Modell, weil parallele Schreibzugriffe auf zwei Datenbank-Instanzen zusätzliche Replikationslogik erfordern würden.

Ein wichtiger Praxishinweis: Die virtuelle IP-Adresse muss im selben Layer-2-Netzwerksegment liegen wie die physischen Interfaces der beteiligten Knoten, da Gratuitous ARP nicht über Routergrenzen hinweg funktioniert. In Cloud-Umgebungen mit eigenen Netzwerküberlagerungen wie AWS oder Azure funktioniert klassisches VRRP daher oft nicht ohne Weiteres und erfordert zusätzliche Anpassungen wie das Umschreiben von Routing-Tabellen per Skript.

6. Priority, Preemption und Split-Brain vermeiden

Die Priority-Werte entscheiden, welcher Knoten im Normalfall Master wird, aber ein oft übersehenes Detail ist das Verhalten nach der Wiederherstellung eines ausgefallenen Knotens. Standardmäßig ist preempt aktiviert, das bedeutet, sobald der ursprüngliche Master mit höherer Priority zurückkehrt, übernimmt er die virtuelle IP sofort wieder zurück. Das klingt zunächst intuitiv, kann aber in Produktionsumgebungen zu unnötigen zusätzlichen Failovern führen, etwa wenn ein Knoten nach einem Neustart kurzzeitig instabil ist.

Mit der Option nopreempt bleibt der aktuell aktive Master aktiv, auch wenn ein Knoten mit höherer Priority wieder online geht, bis der aktuelle Master selbst ausfällt. Diese Einstellung reduziert die Anzahl der Übergänge und ist in vielen produktiven Setups die sicherere Wahl. Ein weiteres, subtileres Problem ist Split-Brain: Wenn die Netzwerkverbindung zwischen den Knoten unterbrochen wird, aber beide Knoten selbst weiterlaufen, können beide gleichzeitig glauben, Master zu sein, und beide beanspruchen dieselbe virtuelle IP.

Split-Brain-Situationen entstehen fast immer durch Netzwerkpartitionierung, nicht durch keepalived selbst. Ein zuverlässiger Schutz ist ein zweiter, unabhängiger Kommunikationspfad zwischen den Knoten, etwa über eine dedizierte Heartbeat-Verbindung oder ein zusätzliches Netzwerkinterface, sodass ein Ausfall des primären Netzwerksegments nicht sofort zu widersprüchlichen Master-Entscheidungen führt. Auch unicast_peer statt Multicast kann in Umgebungen mit unzuverlässigem Multicast-Routing helfen, die Zuverlässigkeit der VRRP-Kommunikation zu verbessern.

7. Notify-Skripte für Automatisierung

Ein reiner IP-Wechsel reicht in vielen Szenarien nicht aus, weil auf dem neuen Master zusätzliche Aktionen nötig sind, etwa das Starten eines Dienstes, das Versenden einer Benachrichtigung oder das Aktualisieren einer DNS-Route. Genau dafür bietet keepalived Notify-Skripte, die bei jedem Zustandswechsel automatisch ausgeführt werden. Die drei relevanten Hooks heißen notify_master, notify_backup und notify_fault, sie werden mit dem neuen Zustand als Parameter aufgerufen.

In der Praxis nutzt man Notify-Skripte häufig, um beim Übergang zum Master automatisch einen abhängigen Dienst zu starten, der auf dem Backup-Knoten im Ruhezustand bleibt, etwa einen Cache-Warmup-Prozess oder eine Replikations-Rolle in einer Datenbank umzuschalten. Ebenso verbreitet ist das Versenden einer Slack- oder E-Mail-Benachrichtigung an das Betriebsteam, damit ein Failover nicht unbemerkt bleibt, selbst wenn er technisch reibungslos verlief.

#!/usr/bin/env bash
# /etc/keepalived/notify.sh — invoked automatically on state transitions
set -euo pipefail

STATE="$1"     # MASTER, BACKUP or FAULT
INSTANCE="$2"  # VRRP instance name
PRIORITY="$3"  # current priority value

case "$STATE" in
  MASTER)
    logger -t keepalived "Node became MASTER for $INSTANCE"
    systemctl start haproxy
    curl -s -X POST -H 'Content-Type: application/json' \
      -d "{\"text\":\"Failover: this node is now MASTER for $INSTANCE\"}" \
      "https://hooks.example.com/notify" || true
    ;;
  BACKUP)
    logger -t keepalived "Node became BACKUP for $INSTANCE"
    ;;
  FAULT)
    logger -t keepalived "Node entered FAULT state for $INSTANCE"
    systemctl stop haproxy || true
    ;;
esac

8. Monitoring und Troubleshooting

Der erste Schritt bei jedem keepalived-Problem ist ein Blick in die Systemlogs, da keepalived jeden Zustandswechsel, jede Priority-Änderung und jeden Health-Check-Fehler protokolliert. Auf systemd-Systemen liefert journalctl -u keepalived -f einen Live-Stream aller Ereignisse und ist meist die schnellste Diagnosemethode bei unerwarteten Failovern. Der aktuelle VRRP-Zustand eines Knotens lässt sich außerdem direkt über ip addr show ablesen, weil die virtuelle IP nur auf dem aktuellen Master als zusätzliche Adresse am Interface erscheint.

Ein häufiges Praxisproblem ist, dass Multicast-Pakete von Firewalls oder Cloud-Sicherheitsgruppen blockiert werden, wodurch beide Knoten unabhängig voneinander Master werden, ohne voneinander zu wissen. Ein tcpdump-Mitschnitt auf Port 112 oder der VRRP-Protokollnummer zeigt schnell, ob Advertisement-Pakete überhaupt beim jeweils anderen Knoten ankommen. Tools wie arping helfen zusätzlich zu überprüfen, ob das Gratuitous ARP nach einem Failover tatsächlich im Netzwerksegment ankommt.

# Live-follow keepalived state transitions
journalctl -u keepalived -f

# Show current VRRP state and priority from the running config
sudo cat /var/run/keepalived.vrrp.state 2>/dev/null || \
  sudo cat /var/log/keepalived.log | tail -50

# Check whether the virtual IP is currently bound on this node
ip addr show eth0 | grep 192.168.10.100

# Capture VRRP advertisement packets (protocol 112) for troubleshooting
sudo tcpdump -i eth0 -n vrrp

# Verify multicast connectivity between nodes
sudo arping -I eth0 192.168.10.100

9. keepalived im Vergleich zu Alternativen

keepalived ist nicht die einzige Möglichkeit, Hochverfügbarkeit auf Linux-Servern umzusetzen. Je nach Anforderung an Cluster-Größe, Ressourcen-Management und Komplexität gibt es passendere Alternativen, die im nächsten Abschnitt zu Pacemaker und Corosync im Detail behandelt werden. Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber.

Für die meisten kleinen bis mittleren Setups mit zwei oder drei Knoten ist keepalived die pragmatischste Wahl, weil es sich ausschließlich um die IP-Zuweisung kümmert und dadurch deutlich einfacher zu verstehen und zu debuggen ist als vollwertige Cluster-Manager. Sobald mehrere unterschiedliche Ressourcen koordiniert werden müssen, etwa ein Dateisystem, ein Datenbank-Dienst und eine virtuelle IP gemeinsam, stößt keepalived an konzeptionelle Grenzen und ein Werkzeug wie Pacemaker wird sinnvoller.

10. Zusammenfassung

keepalived und VRRP lösen ein grundlegendes Verfügbarkeitsproblem mit vergleichsweise geringem Konfigurationsaufwand: eine virtuelle IP-Adresse, die automatisch zwischen mehreren Knoten wechselt, sobald der aktuelle Master ausfällt. Die Kombination aus Priority-Aushandlung, Gratuitous ARP und Health-Checks über vrrp_script sorgt dafür, dass Failover sowohl bei Netzwerk- als auch bei Anwendungsproblemen greift, statt sich nur auf die reine Erreichbarkeit von keepalived selbst zu verlassen.

Wer keepalived produktiv einsetzt, sollte besonders auf nopreempt, sinnvolle Health-Check-Intervalle und einen zweiten Kommunikationspfad zwischen den Knoten achten, um unnötige Failover und Split-Brain-Situationen zu vermeiden. Notify-Skripte erweitern reine IP-Übernahme um Automatisierung, etwa das Starten abhängiger Dienste oder das Versenden von Benachrichtigungen. Für einfache Zwei- bis Drei-Knoten-Szenarien bleibt keepalived die pragmatischste Lösung, bevor komplexere Cluster-Manager wie Pacemaker überhaupt in Betracht gezogen werden müssen.

11. FAQ: keepalived und VRRP Grundlagen