Keepalived¶

Siehe auch

Verwandte Artikel

Offizielle Dokumentation

Linuxfabrik

LFOps-Rolle keepalived

Keepalived setzt das Virtual Router Redundancy Protocol (VRRP) um und bringt damit einen schlanken HA-Failover-Mechanismus auf Layer 3. Zusätzlich kann es Linux IP Virtual Server (IPVS) für Layer-4-Load-Balancing konfigurieren. Im typischen Linuxfabrik-Einsatz wird Keepalived vor einem HAProxy-Cluster betrieben, um die Frontend-VIP zwischen den HAProxy-Nodes wandern zu lassen.

VRRP unterstützt Versionen 2 und 3. Dieser Artikel behandelt VRRP v2, weil die LFOps-Rolle keepalived darauf aufsetzt und v2 in RHEL-Umgebungen der Standard ist.

Begriffe

Floating IP / VIP: die IP-Adresse, die zwischen den HA-Knoten wandert. Immer nur ein Knoten hält sie zur gleichen Zeit (der Master).
Gratuitous ARP: Beim Übernehmen der VIP schickt der neue Master unaufgefordert ein ARP-Paket ins LAN, damit Switches ihre MAC-Adress-Tabellen aktualisieren und der Layer-2-Traffic sofort zum neuen Master läuft.
IP Protocol 112 (VRRP): VRRP ist weder TCP noch UDP, sondern eine eigene IP-Protokollnummer. Wichtig bei Firewall-Regeln.
Preemption: Kommt ein ausgefallener höher-priorisierter Master zurück, zieht er die VIP wieder an sich. Per Default aktiviert; per nopreempt deaktivierbar.
Priority: ein Integer zwischen 1 und 254 (plus der Sonderwert 255 für den „Owner“ der VIP). Die höchste Priority gewinnt die Master-Wahl.
VRID (Virtual Router ID): eindeutige ID einer VRRP-Gruppe pro Netzwerksegment. Muss bei Master und Backup identisch sein.
VRRP Advertisement: Multicast-Paket, das der Master periodisch versendet (per Default 1x pro Sekunde). Backup-Knoten nehmen ein fehlendes Advertisement als Master-Ausfall wahr.

Grundlagen¶

Die Master-Wahl läuft simpel:

Alle Knoten in derselben VRID-Gruppe lesen die priority-Direktive ihrer eigenen Config.
Der Knoten mit der höchsten Priority sendet als erstes ein Advertisement und wird Master.
Die anderen Knoten gehen in den Backup-Modus.
Der Master versendet pro advert_int (default: 1 Sekunde) ein Advertisement.
Fehlen drei Advertisements in Folge, wählen die Backups einen neuen Master.

Ein VRRP-Advertisement enthält:

Virtual Router ID (Gruppen-ID)
Priority des Absenders
Auth Type und Authentication String (bei auth_type PASS ein 8-Zeichen-Passwort)
Advertisement Interval
IP Address(es) der VIPs, die der Master hält

Die Zieladresse des Advertisements ist per Default die Multicast-IP 224.0.0.18 (IP-Protokoll 112). In Netzwerken, die Multicast nicht zuverlässig routen, wird er auf dem lokalen Segment wie Broadcast-Traffic behandelt.

Warnung

auth_type PASS übermittelt das Passwort in Klartext im VRRP-Paket und schützt nur gegen Konfigurationsfehler, nicht gegen aktive Angreifer im selben Broadcast-Segment. Für echten Schutz das VRRP-Segment von nicht-vertrauenswürdigen Hosts fernhalten. Nur die ersten 8 Zeichen des Passworts werden überhaupt verwendet.

Installation und Basis-Konfiguration¶

Keepalived liegt in den Standard-Repos.

dnf --assumeyes install keepalived
keepalived --version

VRRP muss auf der Host-Firewall freigegeben werden. Mit firewalld:

firewall-cmd --permanent --add-rich-rule='rule protocol value="vrrp" accept'
firewall-cmd --reload

Damit ein Service (z.B. HAProxy) auf einer VIP lauschen darf, die aktuell nicht auf dem Interface konfiguriert ist, muss ip_nonlocal_bind aktiviert werden:

/etc/sysctl.d/99-keepalived.conf¶

net.ipv4.ip_nonlocal_bind = 1

sysctl --load /etc/sysctl.d/99-keepalived.conf

Grundkonfiguration für zwei Knoten, die sich eine VIP 192.0.2.26/24 teilen. Master und Backup authentifizieren sich gegenseitig per Passwort:

/etc/keepalived/keepalived.conf (Master, server01)¶

global_defs {
    notification_email {
        root@example.com
    }
    notification_email_from noreply@server01.example.com
    smtp_server localhost
    smtp_connect_timeout 30
}

vrrp_instance VI_1 {
    state MASTER
    interface ens160
    virtual_router_id 51
    priority 255
    advert_int 1
    smtp_alert
    authentication {
        auth_type PASS
        auth_pass linuxfabrik
    }
    virtual_ipaddress {
        192.0.2.26/24
    }
}

/etc/keepalived/keepalived.conf (Backup, server02)¶

global_defs {
    notification_email {
        root@example.com
    }
    notification_email_from noreply@server02.example.com
    smtp_server localhost
    smtp_connect_timeout 30
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens160
    virtual_router_id 51
    priority 200
    advert_int 1
    smtp_alert
    authentication {
        auth_type PASS
        auth_pass linuxfabrik
    }
    virtual_ipaddress {
        192.0.2.26/24
    }
}

Direktiven im Überblick:

state: MASTER oder BACKUP. Reine Dokumentations-Information - den tatsächlichen Master bestimmt die priority.
interface: Das Interface, auf dem VRRP-Advertisements gesendet und die VIP konfiguriert wird.
virtual_router_id: Muss auf allen Knoten derselben VRRP-Gruppe identisch sein.
priority: Höchste Priority gewinnt. Konvention: 255 für den Master, 200 für den Backup. Der Abstand gibt Spielraum für Tracking-basierte Anpassungen.
advert_int: Sekundenabstand zwischen Advertisements. 1 ist sinnvoll.
smtp_alert: Sendet bei jedem Zustandswechsel eine Mail an die Adressen in notification_email.
virtual_ipaddress: Die VIPs, die der Master übernimmt. Mehrere Adressen pro Instanz sind erlaubt.

Auf beiden Knoten starten:

systemctl enable --now keepalived

Die VIP erscheint auf dem Master-Interface. Kontrolle:

ip --brief address show ens160

Tracking¶

Ohne weitere Konfiguration führt nur der komplette Netzwerk-Ausfall eines Knotens zu einem Failover. Das ist in der Regel zu grob: ein Service kann abstürzen, obwohl der Host selbst noch antwortet. Keepalived bringt vier Tracking-Mechanismen mit, die die effektive priority eines Knotens zur Laufzeit anpassen.

Prinzip: ein positiver weight-Wert wird auf die Priority aufaddiert, solange der Tracking-Check positiv ist. Fällt er, wird der Wert abgezogen - und der Knoten verliert gegen einen Backup, dessen Tracking noch intakt ist.