intermediate Guided Build ✓ abgeschlossen

Redundanter Loadbalancer mit HAProxy und Keepalived

Active/Passive Loadbalancer-Stack mit floating VIP über VRRP in einer Proxmox-Umgebung.

12. Mai 2025

Tools HAProxyKeepalivedVRRPProxmoxUbuntu

Tags NetworkingHigh-AvailabilityLinux

Zusammenfassung

In diesem Lab wurde auf Basis zweier Ubuntu 24.04 Server-VMs ein hochverfügbarer Loadbalancer-Stack mit HAProxy und Keepalived aufgebaut und in eine bestehende Proxmox-Homelab-Umgebung integriert. Ziel war das Verständnis von Active/Passive-Failover-Mechanismen über VRRP sowie die praktische Konfiguration von HAProxy als Layer-7-Loadbalancer für HTTP-Backend-Dienste. Ein dritter VM-Node diente als minimaler Webserver-Backend-Pool zur Verifikation der Lastverteilung.

Verwendete Hardware / Software / Sprachen

Typ	Name / Version
Virtualisierung	Proxmox VE 8.2
Betriebssystem	Ubuntu Server 24.04 LTS
Loadbalancer	HAProxy 2.8
HA / Failover	Keepalived 2.2.8 (VRRP)
Backend	nginx 1.24 (2x minimale Web-VMs)
Netzwerk	Linux Bridge, VLAN-tagged Interface
Konfigurationssprache	YAML (Netplan), HAProxy-Config-Syntax

Skill-Einschätzung

Dimension	Vorher (Selbst)	Vorher (KI)	Nachher
Vorkenntnisse Themenspezifisch	2/5	2/5	4/5
Vorkenntnisse Tools	1/5	2/5	3/5
Komplexität des Labs	3/5	4/5	—

Größter Lernmoment: Der Zusammenhang zwischen VRRP-Priority, Preemption und dem tatsächlichen Failover-Verhalten war nicht intuitiv. Erst als der Master-Node absichtlich per systemctl stop keepalived heruntergefahren wurde und die Virtual IP innerhalb von ~2 Sekunden auf den Backup-Node gewandert ist, wurde das Prinzip der floating VIP wirklich greifbar — und warum ohne sie ein DNS-basierter Failover deutlich langsamer und fehleranfälliger wäre.

Ergebnis

Status: Erfolgreich

HAProxy läuft auf beiden Nodes im identischen Konfigurationsstand und verteilt HTTP-Requests per Round-Robin auf zwei nginx-Backend-VMs. Keepalived hält eine Virtual IP (192.168.10.100) im VRRP-Verbund, die bei Ausfall des Master-Nodes innerhalb von ~2 Sekunden auf den Backup-Node übergeht. Der Failover wurde mehrfach durch gezieltes Stoppen von HAProxy sowie durch komplettes Herunterfahren des Master-Nodes verifiziert.

Schwierigkeiten

Keepalived sendete beim ersten Start keine VRRP-Advertisements, weil net.ipv4.ip_nonlocal_bind nicht gesetzt war. HAProxy konnte dadurch nicht an die Virtual IP binden und Keepalived ging in einen Fehler-State. Erst nach längerer Log-Analyse identifiziert — beim nächsten ähnlichen Lab direkt als erstes prüfen.
Die Netplan-Konfiguration eines Nodes hat sich nach einem Reboot zurückgesetzt, weil netplan apply nicht persistiert hatte. Beide Nodes beanspruchten danach gleichzeitig Master-Status (Split-Brain). Zustand erst durch direkten Log-Vergleich beider Nodes erkannt.
Das rsync-Skript zur Konfigurationssynchronisation wurde initial ohne --checksum betrieben, was eine fehlerhafte HAProxy-Config unbemerkt auf den Backup-Node übertrug. Ab dann: nach jedem Sync manuell haproxy -c -f /etc/haproxy/haproxy.cfg auf dem Backup ausführen.

Verwendete Quellen

Erweiterungsideen

Automatische Konfigurationssynchronisation via csync2 oder zentralem Git-Repository, damit beide Nodes nie inkonsistent sein können.
HAProxy Stats-Endpoint auf internem Port freischalten und mit Authentifizierung absichern für Live-Monitoring von Backend-Health und Requestverteilung.
SSL-Terminierung am Loadbalancer: TLS-Zertifikat am HAProxy-Frontend terminieren, Backend-Traffic intern unverschlüsselt — typisches Produktionsmuster.
Active/Active statt Active/Passive: beide HAProxy-Nodes gleichzeitig unter Last betreiben und Komplexitätsunterschied erfahren.