HAProxy als TCP/HTTP-Load-Balancer unter Linux: Konfigurationstest, Seamless Reload und Health Checks

Ziel

HAProxy vor mehreren Backend-Servern einsetzen, eine neue Konfiguration prüfen, bevor sie Datenverkehr erhält, ohne Verbindungsabbrüche neu laden und dafür sorgen, dass HAProxy keinen Datenverkehr mehr an ein ausgefallenes Backend sendet.

Voraussetzungen

HAProxy ist installiert; mindestens zwei Backend-Server oder Ports stehen für die Lastverteilung zur Verfügung; die bestehende Konfigurationsdatei ist vor der Bearbeitung gesichert.

Schritte

1. Ein frontend definieren, das die öffentliche Adresse und den Port bindet, sowie ein backend, das die Server auflistet. Jede Server-Zeile endet mit check, um Health Checks zu aktivieren. Die Option check aktiviert Health Checks für einen Server; ohne weitere Konfiguration gilt ein Server als verfügbar, wenn sich auf der höchsten konfigurierten Transportebene eine Verbindung aufbauen lässt, und er wird bei einem Fehler aus der Rotation genommen. Für eine Prüfung auf HTTP-Ebene option httpchk im Backend ergänzen (ab Version 2.2 verfeinern http-check send meth GET uri /health und http-check expect status 200 die Prüfung).
2. Vor dem Reload die Datei validieren: haproxy -c -f /etc/haproxy/haproxy.cfg. Der Schalter -c prüft ausschliesslich die Konfigurationsdateien und beendet sich, bevor ein Bind versucht wird; bei einem Fehler wird ein Exit-Status ungleich null zurückgegeben. Der Aufruf ist daher auch für eine Konfiguration unbedenklich, die noch nicht produktiv ist.
3. Ohne Verbindungsunterbruch neu laden: systemctl reload haproxy (als root). Paketierte Units starten HAProxy im Master-Worker-Modus (-Ws); der Reload sendet ein Signal an den Master, der versucht, die neue Konfiguration nahtlos in neuen Worker-Prozessen zu laden, während die alten Worker ihre bestehenden Verbindungen abschliessen und sich dann beenden. Die meisten paketierten Units führen zuerst die Prüfung mit -c aus und behalten die alten Worker, falls sie fehlschlägt.
4. Nur wenn HAProxy von Hand ohne Master-Worker-Modus betrieben wird: den neuen Prozess mit -sf <pid>... starten. Er sendet nach Abschluss des Starts das Signal zum Beenden (SIGUSR1) an die älteren Prozesse und fordert sie auf, ihre laufende Arbeit abzuschliessen und sich zu beenden.
5. Das Timing der Health Checks pro Server nach Bedarf anpassen (inter, fall, rise; Standardwerte 2s, 3 und 2), damit es dazu passt, wie schnell ein ausgefallenes Backend ausscheiden und wieder aufgenommen werden soll.
6. Nach einer Änderung den Laufzeitzustand beobachten: Der Stats-Socket oder die Stats-Seite zeigt den Check-Status jedes Servers (UP/DOWN), sodass die Auswirkung eines Reloads auf die Backend-Gesundheit sofort sichtbar ist.

Erwartetes Ergebnis

haproxy -c -f <file> beendet sich mit 0, bevor die laufende Instanz überhaupt neu geladen wird; nach einem Reload zeigt das Access-Log keine abgebrochenen Client-Verbindungen; wird ein Backend-Prozess gestoppt, wechselt sein Status in der Stats-Ausgabe innerhalb des konfigurierten Check-Intervalls auf DOWN, und es erhält keinen Datenverkehr mehr.

Grenzen und Prüfbasis

-c validiert Syntax und interne Konsistenz, nicht aber die Erreichbarkeit der Backend-Adressen: Eine Konfiguration kann -c bestehen und den Datenverkehr dennoch ins Leere leiten, wenn eine Backend-Adresse oder ein Port falsch ist. Der Graceful Reload hält alte Verbindungen auf dem auslaufenden Prozess aufrecht, überführt sie aber nicht in die neue Konfiguration; ein Client, dessen Anfrage während des Reloads läuft, wird noch nach den alten Regeln bedient. Die letzte funktionierende Konfigurationsdatei aufbewahren, um schnell zurückwechseln zu können, falls eine neue Datei -c besteht, im Livebetrieb aber trotzdem fehlerhaft arbeitet.