Load Balancing mit HAProxy unter Linux: Architektur, Konfiguration und Hochverfügbarkeit

Stellen Sie sich eine Website vor, die bei Ausfall eines Servers nahtlos weiterläuft, als sei nichts geschehen. Genau das verspricht Load Balancing mit HAProxy unter Linux: zwei Webserver, zwei Load-Balancer, eine schwebende VIP und ein Pfad durch VRRP-basiertes Failover, der den Verkehr selbst dann führt, wenn einer der Knoten ausfällt. Der Trick liegt nicht nur in der Frontend-Umschichtung des Traffics, sondern in der Architektur, die Redundanz auf mehreren Ebenen verbindet: Health Checks, Rolling-Updates, TLS-Termination – alles so orchestriert, dass der Besucher kaum merkt, dass hinter den Kulissen ein Tanz von Master- und Backup-Knoten stattfindet. Die Kunst besteht darin, eine Balance zu finden zwischen schneller Reaktionszeit, Sicherheit und Wartbarkeit, ohne dass der Betrieb ins Stocken gerät. Dieser Beitrag nimmt Sie mit auf eine Reise von der Architektur über die Feineinstellung der HAProxy-Konfiguration bis hin zu praktischen Tests, mit denen Sie Hochverfügbarkeit greifbar machen.

Architektur mit VIP-Failover: Zwei Webserver hinter zwei Load-Balancern und der VIP 10.13.211.10

Überblick der Architektur

Die vorgestellte Architektur setzt Redundanz auf mehreren Ebenen, um Ausfällen einzelner Komponenten vorzubeugen. Das Herzstück der Hochverfügbarkeit bildet eine schwebende VIP 10.13.211.10, die per VRRP über Keepalived zwischen Master- und Backup-Load-Balancer rotiert. Die Load-Balancer-Knoten tragen die IP-Adressen 10.13.211.194 und 10.13.211.120 und übernehmen den Verkehr, falls der Master ausfällt. Der Webverkehr läuft primär über Port 80; TLS/HTTPS lässt sich ergänzen, um die Backend-Last zu reduzieren und zusätzliche Sicherheit zu bieten. Ziel ist eine Hochverfügbarkeit mit Redundanz gegen Ausfälle eines LB-Knotens oder eines Webservers, kombiniert mit praktikabler Wartbarkeit durch Rolling-Updates, bei denen die VIP auch im Failover erreichbar bleibt.

Architekturkomponenten im Überblick

• Webserver
• Webserver 1: 10.13.211.169
• Webserver 2: 10.13.211.158
• Load-Balancer
• Master/Backup: 10.13.211.194 und 10.13.211.120
• Virtuelle-IP
• VIP: 10.13.211.10
• Der VIP schwebt zwischen Master und Backup; Failover erfolgt automatisch bei Ausfall des Masters.
• Netzinfrastruktur und Dienste
• Der Webverkehr erfolgt primär auf Port 80.
• TLS/HTTPS kann ergänzt werden, um Backend-Last zu reduzieren und Verschlüsselung frühzeitig abzuwickeln.
• Zielsetzung
• Hochverfügbarkeit durch Redundanz auf LB- und Webserver-Ebene.
• Ausfallsicherheit gegen Einzelkomponenten-Fehler.
• Wartungsfreundlichkeit durch Rolling-Updates, bei denen der VIP stets erreichbar bleibt.

Webserver-Topologie und Lastverteilung

Webserver-Hintergrund

• Zwei Webserver hinter einem Paar von Load-Balancern bilden das Backend-Cluster.
• Die Webserver liefern identische Inhalte und stehen für Skalierbarkeit und Fehlertoleranz in der App-Schicht.

Verteilung der Anfragen

• Der Verkehr wird durch die Load-Balancer-Knoten (HAProxy) auf die beiden Webserver gleichmäßig verteilt.
• Die Verteilung erfolgt so, dass bei aufkommendem Traffic beide Backend-Server genutzt werden, was zu höherer Verfügbarkeit und besserer Reaktionszeit führt.
• TLS-Entlastung kann entweder am Load Balancer erfolgen (TLS-Offloading) oder durch TLS-Passthrough zum Backend realisiert werden, je nach gewünschtem Sicherheits- und Performanceprofil.

VRRP-basiertes VIP-Failover mit Keepalived

Konzept des VIP-Failovers

• Die schwebende VIP-Adresse ermöglicht eine nahtlose Failover-Strategie, ohne dass Clients die Zieladresse ändern müssen.
• VRRP sorgt dafür, dass nur ein LB-Knoten Master wird, während der andere als Backup bereitsteht.
• Im Master-Modus übernimmt der Load-Balancer mit der VIP alle ankommenden Verbindungen, der Backup-Knoten tritt erst in Aktion, wenn der Master ausfällt.

Keepalived-Kontext

• Keepalived betreibt die VRRP-Instanz und verwaltet den Floating-IP-Satz. Bei Ausfall des Masters übernimmt der Backup-Knoten die VIP, sodass der Dienst weiterhin erreichbar bleibt.
• Die VIP-Rotation unterstützt Wartungsfenster: Rollende Updates an einem LB-Knoten beeinträchtigen so nicht die Erreichbarkeit des Dienstes, da der andere LB weiterhin Anfragen abarbeitet.
• Typischerweise wird der Master mit einer höheren Priorität betrieben, der Backup übernimmt erst im Failover-Fall. Die VIP bleibt währenddessen erreichbar.

Netzwerkadressierung und Rollenverteilung

• Webserver
• 10.13.211.169
• 10.13.211.158
• Load-Balancer
• Master/Backup-Knoten: 10.13.211.194 und 10.13.211.120
• VIP-Floating-Adresse
• 10.13.211.10 rotiert zwischen Master und Backup
• Verkehrspfad
• Client-Anfragen erreichen zuerst den VIP, werden durch die LB-Knoten an die Webserver weitergeleitet.
• Die Inhalte auf den Webservern sind unverändert, da Load-Balancer-Schichten die Verteilung übernehmen.

Traffic-Flow und TLS-Strategie

Ausgangspunkt Port 80

• Der primäre Webverkehr läuft über Port 80, was gängige Webanwendungen und einfache Bereitstellungen unterstützt.
• Diese Architektur ermöglicht eine unkomplizierte, kosteneffiziente Anbindung der Clients.

TLS-/HTTPS-Optionen

• TLS/HTTPS kann ergänzt werden, um Backend-Last zu entlasten und die Verschlüsselung frühzeitig zu terminieren.
• TLS-Offloading am Load Balancer reduziert die CPU-Last der Backend-Webserver und vereinfacht Zertifikat- und Schlüsselmanagement auf der LB-Ebene.
• Optional kann TLS-Passthrough genutzt werden, wenn Backends die TLS-Verarbeitung selbst übernehmen sollen.

Vorteile, Redundanz und Wartbarkeit

• Hochverfügbarkeit durch Redundanz
• Ausfall eines LB-Knotens oder eines Webservers führt nicht zu Ausfall des Dienstes, da die verbleibenden Komponenten die Last übernehmen.
• VIP-Failover sorgt dafür, dass sich Clients nicht mit Ausfällen auseinandersetzen müssen; der Verkehr bleibt stabil.
• Wartungsfreundlichkeit durch Rolling-Updates
• Wartungsarbeiten können an einem LB-Knoten durchgeführt werden, während der andere Knoten weiterhin Traffic verarbeitet.
• Der VIP bleibt während Failover-Ereignissen erreichbar, was Downtime minimiert.
• Transparente Failover-Operation
• VRRP/Keepalived steuern die VIP-Rotation automatisch; der Master bleibt preferenziell aktiv, der Backup übernimmt nur bei Ausfall.
• Skalierbarkeit und Zukunftssicherheit
• Mehr Webserver oder zusätzliche LB-Knoten lassen sich in die Architektur integrieren, ohne den Betrieb zu stören.
• Die Struktur unterstützt einfache Erweiterungen von Port-80-zu-HTTPS-Setups oder gezielte ACL-/Routing-Strategien, um spezifische Pfade oder Content-Gruppen zu bedienen.

Betrieb, Monitoring und Best Practices

• Statusprüfungen sollten regelmäßig erfolgen, um Health-Checks der Backend-Server zu verifizieren.
• Die VIP-Überwachung lässt sich durch gezielte Curl- oder Monitoring-Queries gegen 10.13.211.10 testen, um das Failover-Verhalten in der Praxis zu beobachten.
• Logs und Metriken auf beiden LB-Knoten liefern Einblick in Lastverteilung, Failover-Ereignisse und mögliche Engpässe.
• Backup-Strategien für Konfigurationsdateien und Zertifikate erhöhen die Robustheit der Installation.

Fazit

Architektur mit VIP-Failover bietet eine robuste Grundlage für Lastverteilung und Hochverfügbarkeit in Linux-Umgebungen. Zwei Webserver hinter zwei Load-Balancern, unterstützt durch eine schwebende VIP-Adresse und VRRP-basiertes Failover, garantieren Verfügbarkeit auch bei Ausfällen einzelner Bausteine. Der primäre Verkehr läuft über Port 80, TLS/HTTPS ist optional und entlastet Backend-Last bzw. erhöht Sicherheit. Die Struktur erleichtert Wartung durch Rolling-Updates, da der VIP auch im Failover erreichbar bleibt, was Downtime minimiert und Betriebsabläufe stabil hält.

HAProxy-Grundkonfiguration: Frontend, Backend, Round-Robin, Health Checks

In dieser Grundkonfiguration wird HAProxy als einfacher HTTP-Load-Balancer vorgestellt. Die Kernideen sind klar: eine Frontend-Sektion lauscht auf eingehende Verbindungen, eine Backend-Sektion bildet den Pool der Anwendungsserver, und der Standard-Verteilungsalgorithmus ist Round-Robin. Health Checks sichern die Verfügbarkeit, während der STATUS-Bereich eine einfache Überwachung ermöglicht. Zudem lassen sich HTTP-spezifische Features wie Header-Verarbeitung, Keep-Alive und Sticky Sessions nutzen. Auch spielt die Firewall-Konfiguration eine Rolle, und es besteht die Option, eine Statistikseite über Port 8404 bereitzustellen.

Frontend: Lauschen, Statusseite und Weiterleitung

• Frontent-Definition: Ein Frontend empfängt den eingehenden Verkehr und leitet ihn an das entsprechende Backend weiter. Typischerweise wird hier der Listenport festgelegt, zum Beispiel Port 80.
• Statusseite: Über eine integrierte Statistikseite lassen sich Verbindungen, Anfragen und Backend-Gesundheit überwachen. Die Standard-URI für diese Statusseite ist sichtbar innerhalb der HAProxy-Konfiguration (z. B. /haproxy?stats).
• Standard-Backend: Das Frontend legt das Default-Backend fest, auf das Anfragen weitergeleitet werden, wenn keine ACL-basierten Regeln zutreffen.

• Beispiel-Abschnitt (Entlastung und Überblick):
• Frontend-Name: http_front
• Bind-Statement: bind *:80
• Stats-URI: stats uri /haproxy?stats
• Default Backend: default_backend http_back

Backend: Round-Robin und Health Checks

• Balancing-Algorithmus: Der Standard-Algorithmus in dieser Grundkonfiguration ist balance roundrobin, also eine zyklische Verteilung der Anfragen auf die verfügbaren Backend-Server.
• Backend-Definition: Ein Backend bildet den Pool der Backend-Server ab, die die eigentliche Anwendungslogik erfüllen. Hier werden zwei Backend-Server definiert.
• Health Checks: Jeder Backend-Server wird mit check markiert, was regelmäßige Health Checks aktiviert. Gesonderte Health-Check-Definitionen ermöglichen HTTP-Checks und entsprechende Erwartungswerte (z. B. HTTP-Status 200).

• Beispiel-Abschnitt (Kern-Konfiguration):
• Backend-Name: http_back
• Balance: balance roundrobin
• Mode: mode http
• Server webserver1 10.13.211.169:80 check
• Server webserver2 10.13.211.158:80 check
• (optional) option httpchk GET /health
• (optional) http-check expect status 200

Health Checks: Verfügbarkeit regelmäßig prüfen

• Health Checks prüfen regelmäßig die Verfügbarkeit der Backend-Server und markieren inaktive Backends.
• Durch regelmäßige Checks wird Traffic automatisch auf die gesunden Knoten umgelenkt, was Ausfallzeiten reduziert.
• Die Checks können HTTP-spezifisch (z. B. GET-Anfrage an einen Health-Endpunkt) oder allgemein über den Status erfolgen.

• Typische Health-Check-Definitionen:
• check für jeden Server im Backend
• optional option httpchk GET /health
• optional http-check expect status 200
• Ergebnis: inaktive oder nicht erreichbare Backends werden aus dem Traffic genommen und wieder aktiviert, sobald sie gesund sind.

HTTP-spezifische Features: Header, Keep-Alive & Sticky Sessions

• HTTP-Header-Unterstützung: HAProxy kann Header-Informationen nutzen und passenden Traffic zurechtschneiden oder weiterleiten, z. B. X-Forwarded-For, Host-Header-Weiterleitung usw.
• Keep-Alive: Verbindungs- und Timeout-Einstellungen ermöglichen langlebige Verbindungen zwischen Client, Load-Balancer und Backend.
• Sticky Sessions (Sitzungspersistence): Cookie-basierte Persistenz lässt eine Sitzung einem bestimmten Backend-Server zuordnen, was bei zustandsbehafteten Anwendungen sinnvoll ist.

Monitoring, Firewalls und Erweiterungen

• Statuszugang: Die HAProxy-Statistikseite ist ideal, um Verbindungen, Anfragenfrequenz und Backend-Gesundheit zu überwachen. Zugriff ist in der Praxis oft über /haproxy?stats möglich.
• Firewallregeln: Achten Sie darauf, HTTP/HTTPS-Verkehr zuzulassen (typisch Port 80/443). Für Statistiken lässt sich zusätzlich Port 8404 öffnen, um eine dedizierte Statistikseite bereitzustellen.
• Erweiterungspotential: Die Grundkonfiguration lässt sich einfach auf weitere Backends, ACLs, Stick-Tables (für Ratenbegrenzung) oder TLS-Termination erweitern.

Beispielfintras Konfigurationshappen (klares Grundgerüst)

• Globaler Block (Wichtige Rahmendaten):
• global
• log /dev/log local0
• log /dev/log local1 notice
• chroot /var/lib/haproxy
• stats timeout 30s
• user haproxy
• group haproxy
• daemon

• Defaults-Block (Zeiteinstellungen und Verhalten):
• defaults
• log global
• mode http
• option httplog
• option dontlognull
• timeout connect 5000
• timeout client 50000
• timeout server 50000

• Frontend-Block ( Lauschen und Weiterleitung ):
• frontend http_front
• bind *:80
• stats uri /haproxy?stats
• default_backend http_back

• Backend-Block (Round-Robin & Health Checks):
• backend http_back
• balance roundrobin
• mode http
• server webserver1 10.13.211.169:80 check
• server webserver2 10.13.211.158:80 check
• (optional) option httpchk GET /health
• (optional) http-check expect status 200

Schritte zur Inbetriebnahme

1. HAProxy installieren und Grundkonfiguration anlegen.
2. Konfiguration testen, z. B. haproxy -c -f /etc/haproxy/haproxy.cfg.
3. Dienst aktivieren und starten: systemctl enable haproxy; systemctl start haproxy.
4. Zugriff testen: browsen Sie zur DNS- oder IP-Adresse des Load-Balancers; Anfragen sollten abwechselnd an webserver1 und webserver2 gehen.
5. Stats prüfen: rufen Sie die Statistikseite auf, beispielsweise über die konfigurationsseitig definierte URI, um Verbindungen, Anfragen und Backend-Gesundheit zu sehen.
6. Erweiterungen schrittweise hinzufügen: Header-Verarbeitung, Keep-Alive, Sticky Sessions, ACLs, und Sicherheitsverbesserungen wie TLS-Termination.

Dieses Grundgerüst bietet eine klare, erweiterbare Basis für Load Balancing mit HAProxy unter Linux. Es illustriert die Trennung in Frontend und Backend, den Standard-Verteilungsmechanismus Round-Robin, die Integration von Health Checks und die Möglichkeiten zur Observability und Erweiterung.

Keepalived und VRRP: Master-Backup-Setup, VIP-Swing und Interface-Konfiguration

Keepalived liefert auf zwei Load-Balancern eine hochverfügbare Floating-VIP, die im VRRP-Failover zwischen Master- und Backup-Knoten rotiert. In diesem Zusammenhang verwaltet Keepalived den Floating VIP 10.13.211.10, der als schwebende IP-Adresse fungiert und den Zugriff auf die dahinterliegenden Backends ermöglicht, ohne dass Clients eine Änderung der Zieladresse bemerken. Die VRRP-Instanz VI_1 sorgt dafür, dass der Master-Status, der Interface-Name (beispielsweise eth0) und die VIP-Adresse sauber konfiguriert sind. Durch identische Grundkonfiguration beider LB-Knoten, unterschieden lediglich durch Priority, lässt sich ein transparentes Failover realisieren.

Grundkonfiguration der VRRP-Instanz VI_1

• VI_1-Konfiguration: Die VRRP-Instanz VI_1 initialisiert den Master-Status, referenziert das Interface (z. B. eth0), setzt eine virtuelle Router-ID und verwaltet die VIP-Adresse. Typische Parameter sind virtual_router_id, priority, advert_int und authentication, die das Failover-Verhalten determinieren.
• Interface-Auswahl: Der Interface-Name muss der Netzwerkschnittstelle des jeweiligen LB-Knotens entsprechen, üblicherweise eth0 oder ein entsprechendes Interface im konkreten Setup.
• VIP-Adresse: Die virtuelle IP-Adresse wird in der keepalived.conf unter virtual_ipaddress aufgeführt, hier als 10.13.211.10.
• Animation der VIP-Verwaltung: Das System reagiert zügig auf Statusänderungen: Der Master verwaltet die VIP, der Backup wechselt in BACKUP, ohne dass Clients den Wechsel bemerken.
• Authentifizierung und Stabilität: In der Regel wird eine einfache PASS-Authentifizierung verwendet, ergänzt durch advert_int- und Zeitparameter, um die Stabilität des Failovers zu erhöhen.

Master-Backup-Ansatz: Priority und VIP-Swing

• Master- vs. Backup-Priorität: Standardmäßig besitzt der Master eine Priority von 101, der Backup-Knoten eine Priority von 100. Diese klare Unterscheidung sorgt dafür, dass der Master die VIP-Verwaltung übernimmt, solange er erreichbar ist.
• VIP-Swing-Mechanismus: Wenn der Master ausfällt oder die VRRP-Gruppenkommunikation unterbrochen wird, übernimmt der Backup-Knoten nahtlos die VIP-Verwaltung. Der Wechsel erfolgt, ohne dass Clients eine neue Zieladresse oder einen anderen Endpunkt benötigen.
• Gleiches Setup, unterschiedliche Priorität: Beide LB-Systeme arbeiten mit identischer Keepalived-Konfiguration, unterscheiden sich aber in der Priority-Zuweisung. So bleibt die VIP-Verwaltung klar deterministisch, und der Failover erfolgt automatisch.

VIP-Verteiler-Beispiel: Zwei identische Systeme, unterschiedliche Priorität

• Verteilungslogik: Der VIP-Verteiler wird so konfiguriert, dass eines der beiden LB-Systeme den Master-Status übernimmt. Die VIP-Adresse rotiert zwischen Master und Backup je nach Verfügbarkeit.
• Schnelle Reaktionsfähigkeit: Durch das Festlegen der VIP-Verwaltung auf den Master wird sichergestellt, dass Health Checks der dahinterliegenden Systeme ununterbrochen Traffic erhalten, weil die VIP-Adresse konstant bleibt.
• Beispiel eines Implementierungs-Szenarios: Beide LB-Knoten verwenden identische Keepalived-Konfigurationen; der Master besitzt Priority 101, der Backup 100. Der VRRP-Adapter sorgt dafür, dass der Master die VIP aktiv verwaltet, der Backup verbleibt im BACKUP-Status.

Manuelle Tests zur VIP-Verifikation

• VIP-Zugriff prüfen: Für einfache Tests reicht es, curl auf die VIP-Adresse 10.13.211.10 auszuführen, um sicherzustellen, dass der Traffic weitergeleitet wird und eine gültige Antwort von den dahinterliegenden Webservern kommt.
• Test-Befehle:
• curl 10.13.211.10
• curl -I 10.13.211.10
• Dauerhafter Monitoring-Test: Zur Beobachtung des Failover-Verhaltens kann eine Schleife genutzt werden, die periodisch die VIP beantwortet:
• while true; do curl 10.13.211.10; sleep 1; done
• Beim Master-Ausfall erreicht der Backup weiterhin die VIP, da der Backup-Knoten die VIP-Verwaltung übernimmt.
• Praktisch lässt sich so die nahtlose Failover-Funktion demonstrieren und visuell verifizieren.

Betrieb, Überwachung und praktische Hinweise

• Klonen und Replizieren: Für Effizienz empfiehlt es sich, VMs zu klonen und den zweiten Knoten entsprechend neu zu konfigurieren, statt beide Systeme komplett neu aufzubauen.
• Status-Überwachung: Keepalived-Logs und der VRRP-Status geben Aufschluss über den aktuellen Master, Backup-Status und VIP-Zustand.
• Test-Strategie: Führen Sie gezielte Failover-Tests durch, indem Sie den Master vorübergehend deaktivieren oder Keepalived stoppen, und beobachten Sie, wie der Backup die VIP übernimmt.
• Interface-Name prüfen: Prüfen Sie vor dem Produktionseinsatz, welcher Interface-Name im System tatsächlich verwendet wird, damit VI_1 das korrekte Interface referenziert.
• VIP-Planung: VIPs können auf unterschiedliche Live-IP-Adressen verlagert werden; in diesem Setup ist 10.13.211.10 der Floating VIP, der zwischen Master und Backup wechselt.
• Sicherheit und Integrität: Achten Sie darauf, dass VRRP-Antworten sicher kommuniziert werden, und verwenden Sie nachvollziehbare Authentication-Parameter, um unbefugte Manipulationen zu verhindern.

Praktische Deployment-Empfehlungen

• Identische Konfigurationen: Halten Sie die Keepalived-Konfigurationen beider LB-Knoten identisch, außer der Priority-Wert, damit der Master eindeutig bestimmt ist.
• VIP-Resilienz testen: Führen Sie selbst Tests durch, die den VIP-Wechsel simulieren, etwa durch Entfernen des Masters aus dem Netzwerk oder das temporäre Deaktivieren des Master-Knotens.
• Überlagerung mit Health Checks: Verknüpfen Sie VRRP mit Health Checks der Backend-Systeme, damit im Fehlerfall der Master unabhängig vom VIP-Verhalten zuverlässig reagiert.

Zusammen sichern Master-Backup-Setup, VIP-Swing und Interface-Konfiguration die unterbrechungsarme Verfügbarkeit der Lastverteilung. Der Floating VIP bleibt die zentrale Zugriffspunktadresse, während VRRP Master- und Backup-Status koordiniert. Manuelle VIP-Tests mit curl gegen 10.13.211.10 liefern eine direkte Bestätigung der Funktionsfähigkeit und ermöglichen die frühzeitige Erkennung von Störungen im Failover-Pfad.

Monitoring, Tests und Validierung: Statistiken, VIP-Tests und Failover-Szenarien

In einer produktiven HAProxy-Architektur ist Monitoring integraler Bestandteil des Betriebs. Die Validierung von Lastverteilung, Health Checks und Failover-Szenarien muss ganzheitlich erfolgen: Sichtbarkeit in Echtzeit, reproduzierbare Tests und klare Regeln für den Betrieb bei Änderungen. Im Folgenden finden Sie konkrete Schritte, Messgrößen und Testfälle.

Überwachung und Statistik

• Überwachung über die Statistikseite: Die zentrale Überwachung erfolgt primär über die integrierte Statistikseite von HAProxy, erreichbar über die LB-IP. Dort lässt sich der Live-Status der Backends einsehen, einschließlich Verfügbarkeitsindikatoren, Verbindungszahlen und Health-Check-Ergebnisse. Diese Ansicht dient als erste Orientierung für Betriebs- und Engineering-Teams.
• Logs als Quellermedium: Logs befinden sich typischerweise in /var/log/haproxy oder werden via Syslog dokumentiert. Sie enthalten detaillierte Einträge zu Verbindungen, Fehlern, Health-Checks und Backend-Aktivitäten. Eine regelmäßige Prüfung der Logs ermöglicht Frühwarnungen bei anomalem Muster, zum Beispiel wiederkehrenden Timeouts oder auffälligen 5xx-Antworten.
• Observability und Metriken (optional): Neben der klassischen Log- und Statistikseite empfiehlt sich eine Observability-Ebene mit Metriken. Prometheus-Exporter oder native Prometheus-Schnittstellen liefern Kennzahlen wie Anfragen pro Sekunde, durchschnittliche Latenzen, Verbindungszahlen pro Backend sowie Health-Check-Latenzen. Diese Metriken unterstützen Dashboards, Alarmierung und Kapazitätsplanung.
• Beständigkeit von Logs und Metriken: Stellen Sie sicher, dass Logs zuverlässig rotiert und aufbewahrt werden. Definieren Sie zeitgesteuerte Aufbewahrungsregeln und sichern Sie Remote-Logging-Optionen, um den Verlust von Diagnosedaten im Störungsfall zu vermeiden.

Manueller Test: VIP- und LB-Tests mit Curl

• Gezieltes Validieren der Lastverteilung: Führen Sie Curl-Tests gegen die VIP oder gegen die LB-IPs aus, um zu beobachten, wie Anfragen auf die Backend-Server verteilt werden. Idealerweise zeigen mehrere aufeinanderfolgende Requests unterschiedliche, aber gleichmäßige Backend-Ziele an.
• Health-Check-Reaktion prüfen: Neben der Verteilung sollten Health-Checks sichtbar werden: In der Statistikseite oder in den Logs sollten fehlgeschlagene Checks markiert und Backends in den Status „unhealthy“ wechseln, woraufhin HAProxy das Backend-Gesamtsystem neu balanciert.
• Wiederherstellung testen: Senken Sie schrittweise die Belastung oder simulieren Sie kurze Backend-Ausfälle, um zu prüfen, ob HAProxy bei Rückkehr der Dienste wieder zuverlässig verteilt.
• Reproduzierbare Tests dokumentieren: Legen Sie standardisierte Testfälle fest (z. B. 10 aufeinanderfolgende Requests gegen VIP, 10 gegen LB-IP, Gleichverteilung über zwei Backends) und speichern Sie Ergebnisse, Outputs, damit Abweichungen zeitnah erkannt werden.

Failover-Szenarien: VIP-Wechsel und Master-/Backup-Status

• Master- bzw. Keepalived-Ausfall simulieren: Failover-Tests lassen sich realisieren, indem gezielt der Master-Knoten oder Keepalived-Dienste gestoppt werden. Anschließend beobachten Sie, wie der VIP (Virtual IP) vom Master auf den Backup-Knoten wechselt und welche Auswirkungen dies auf die Traffic-Verteilung hat.
• VIP-Switchover beobachten: Während des Failovers sollten Sie in der Statistikseite und in den Logs nachvollziehen können, welcher Knoten aktuell den VIP bedient und welche Backends als primary/secondary fungieren. Notieren Sie Übergangszeiten, um SLA-Anforderungen zu evaluieren.
• End-to-End-Failover-Validierung: Nach dem Failover sollten Client-Anfragen weiterhin erfolgreich beantwortet werden, wobei die Antworten von unterschiedlichen Backends stammen könnten. Das dient der Bestätigung, dass der Traffic nahtlos weitergeleitet wird und der Ausfall eines Knotens nicht zu Unterbrechungen führt.

Logs und Forensik

• Detaillierte Verarbeitungsdaten: Die Protokolle liefern Einblick in Verbindungen, Statuscodes, Verbindungsdauer, Health-Check-Ergebnisse und Backend-Verfügbarkeit. Diese Informationen sind unverzichtbar, um Ursachenforschung bei Störungen zu betreiben oder Muster von Fehlern frühzeitig zu erkennen.
• Log-Management und Nachbereitung: Richten Sie eine strukturierte Log-Weiterleitung ein (z. B. zentralisiertes Logging oder Log-Analytics-Plattform) und implementieren Sie regelmäßig Rotationen, Sicherungen und Audits der Logs. Dies erleichtert die Rückverfolgbarkeit im Fehlerfall.

Validierung: End-to-End-Tests und Observability

• End-to-End-Tests: Validieren Sie den gesamten Pfad vom Client bis zur Backend-Antwort. Prüfen Sie, dass Anfragen trotz einzelner Backend-Ausfälle korrekt an verfügbare Serversysteme weitergeleitet werden und dass die Antworten konsistent sind.
• Observability und Metriken: Kombinieren Sie End-to-End-Tests mit einem Metrik-Stack. Sichtbar werden Kennzahlen wie Requests pro Sekunde, durchschnittliche Latenz pro Backend, Health-Check-Latenzen, Verbindungs-Queues und Auslastung.
• Regressionstests (empfohlen): Für Produktionsumgebungen empfiehlt sich ein automatisiertes Regressionstest-Setup, das bei Änderungen an der Konfiguration oder an der Infrastruktur greift. Integrieren Sie diese Tests in CI/CD-Pipelines, um frühzeitig regressionsbedingte Fehler zu erkennen und aussagekräftige Reports zu erhalten.

Produktions- und Betriebsleitfaden

• Automatisierte Regressionstests bevorzugen: Setzen Sie auf automatisierte Tests, die sowohl funktionale Korrektheit der Lastverteilung als auch Stabilität bei Failover-Szenarien sicherstellen.
• Staging vor Production: Führen Sie kritische Tests zuerst in einer Stage-Umgebung durch, bevor Sie Änderungen in Production übernehmen.
• Sichere Logs und Zugriffskontrollen: Schützen Sie Logging- und Monitoring-Endpunkte vor unbefugtem Zugriff; setzen Sie ausreichende Berechtigungen und vermeiden Sie sensible Informationen in Logs und Metriken.
• Dokumentation der Testergebnisse: Halten Sie Testpläne, erwartete Ergebnisse, tatsächliche Observability-Werte und Failover-Zeiten fest. So entsteht eine nachvollziehbare Historie für Audits und Optimierungen.

Diese Monitoring- und Validierungsstrategie sorgt dafür, dass Load Balancing mit HAProxy unter Linux nicht nur funktioniert, sondern auch unter Last stabil bleibt, transparenter beobachtbar ist und im Notfall schnell und kontrolliert wiederhergestellt werden kann.

Best Practices: TLS, Firewall, Leistung, Skalierung und Sicherheit

TLS-Termination und Zertifikatsverwaltung

• Vorteil der TLS-Termination: Die TLS-Verbindung wird am Load Balancer beendet, wodurch Kryptografie- und Entschlüsselungsarbeit von den Backend-Servern abgezogen wird. Das erhöht die verfügbare Rechenleistung der Backend-Services und vereinfacht Wartung sowie Updates der Zertifikate.
• Zertifikatsverwaltung: Zertifikate sollen zentral am LB gepflegt werden. Let’s Encrypt/Certbot bieten automatisierte Beschaffung und -erneuerung; so bleiben Zertifikate aktuell, ohne manuelle Eingriffe an jedem Backend erforderlich zu machen.
• Praktische Umsetzung: Legen Sie eine PEM-Datei je Domain in Ihrem Zertifikatsverzeichnis ab, sichern Sie Berechtigungen (typisch 600), und konfigurieren Sie den HTTP-zu-HTTPS-Redirect sowie TLS-Parameter so, dass die PEM-Datei vom LB geladen wird. Planen Sie Renewals-Hooks ein, damit bei jeder Erneuerung die PEM-Datei neu erzeugt wird und der Load Balancer neu geladen wird.

TLS- und Sicherheitskonfigurationen

• Moderne Protokolle bevorzugen: Konfigurieren Sie TLS 1.2 und TLS 1.3 als Standard, deaktivieren Sie ältere Protokolle vollständig. Achten Sie auf zeitgemäße Chiffersuiten, Perfect Forward Secrecy und regelmäßige Updates der TLS-Konfiguration.
• HSTS aktivieren: HSTS sorgt dafür, dass der Browser TLS-Verbindungen ausschließlich nutzt und verhindert Klartext-Verkehr. Aktivieren Sie HSTS mit sinnvoll gesetztem Max-Age und ggf. IncludeSubDomains, um Subdomains zu schützen.
• TLS-ALPN unterstützen: Mit TLS-ALPN lässt sich HTTP/2 effizient aushandeln; dies reduziert Latenz und verbessert Parallelität bei HTTPS-Verkehr.
• Zertifikatsketten und OCSP-Stapling: Stellen Sie sicher, dass die vollständige Zertifikatskette vorliegt und OCSP-Stapling aktiv genutzt wird, um Abfragen an Zertifizierungsstellen zu minimieren.
• Zugriffsbeschränkungen für TLS-bezogene Endpunkte: Reduzieren Sie Angriffsflächen durch Absicherung der TLS-Index-Seiten, Strikte-Transport-Security-Header (Strict-Transport-Security), sowie saubere Weiterleitungen von HTTP auf HTTPS, um Klartext-Verkehr zu eliminieren.

Firewall- und Netzwerkzugriffe

• Schütze den öffentlichen Zugriff: Öffnen Sie öffentlich nur die minimal notwendigen Ports (typisch 80/443) am Load Balancer. Alle anderen Verwaltungs- oder Monitoring-Endpunkte sollten strikt hinter einer Zugriffskontrolle oder einem Verwaltungsnetzwerk liegen.
• VRRP-Port 112 freigeben: In der Sicherheitszone der Load-Balancer müssen VRRP-Kommunikationen zwischen Master- und Backup-Knoten erlaubt sein; der Port 112 (UDP) wird für VRRP verwendet. Stellen Sie sicher, dass dieser Verkehr sicher zwischen den LB-Knoten fließt.
• Netzwerksegmentierung: Halten Sie Backends hinter der LB-Demilitarisierung: Nur der LB sollte direkt ins Internet gehen; interne Backend-Verbindungen verwenden private Netze; pflegen Sie klare ACLs, um unautorisierten Zugriff zu verhindern.
• Zugriffssteuerung für Stats-Seiten: Statistiken und Management-Schnittstellen sollten idealerweise hinter Authentisierung oder einer IP-Whitelist liegen, um Missbrauch zu verhindern.

OS-Tuning und Kernel-Parameter

• Dateideskriptoren erhöhen: Erhöhen Sie die Grenzwerte für offene Dateien (ulimits) sowie die Systemdateien, um tausende gleichzeitige Verbindungen zu unterstützen.
• Backlog- und Kernel-Parameter: Anpassungen wie höhere somaxconn-Werte (z. B. 65535) und erweiterte Empfangspuffer helfen, Lastspitzen abzufangen. Setzen Sie effektive TCP-Parameter (z. B. tcp_tw_reuse, tcp_fin_timeout) sinnvoll, um Verbindungszustände effizient zu managen.
• Systemweite Einstellungen persistent machen: Verwenden Sie Sysctl-Dienste/Overrides, damit die Optimierungen nach Neustarts erhalten bleiben. Dokumentieren Sie ebenfalls Overrides-Dateien.
• Ressourcenlimitierung pro Prozess: Falls Sie mehrere Instanzen des Load Balancers betreiben, setzen Sie klare LimitNOFILE-Werte, damit kein Prozess durch Beschränkungen ausgebremst wird.
• Monitoring der Metriken: Überwachen Sie Scheduling-Parameter und Timeouts, um Kapazitätsgrenzen frühzeitig zu erkennen und entsprechend zu skalieren.

Schutzmechanismen: DoS, Ratenbegrenzung, ACLs und Sticky Sessions

• Stick-Table-Mechanismen: Verwenden Sie Stick-Tabellen, um IP-basierte Ratenbegrenzung und Verbindungsraten zu implementieren. So lassen sich Burst-Floods früh erkennen und blockieren.
• Ratenbegrenzung: Setzen Sie Grenzwerte pro Client-IP (z. B. HTTP-Anfragen pro Sekunde in einen kurzen Zeitraum) und verweigern Sie übermäßige Anfragen mit zeitnahen 429-Fehlern.
• ACLs (Zugriffskontrolllisten): Nutzen Sie ACLs, um Anfragen zielgerichtet zu filtern, z. B. Pfad-/Host-basierte Routing-Entscheidungen, Quell-IP-Restriktionen oder spezielle Verhaltensmuster.
• Sticky Sessions: Für zustandsbehaftete Anwendungen unterstützen Sticky Sessions typischerweise Cookies oder Header-basierte Persistenz, um die Zuordnung einzelner Clients zu einem Backend-Server stabil zu halten.
• DoS-Resilienz im Frontend: Kombinieren Sie Ratenbegrenzung mit sinnvoll abgegrenzten ACLs, um Angriffe abzuschwächen, ohne legitime Nutzer zu blockieren.

Skalierung: Horizontal wachsen und Durchsatz maximieren

• Weitere Backend-Server hinzufügen: Skalierung erfolgt durch horizontales Hinzufügen weiterer Anwendungsserver hinter dem Load Balancer. Passen Sie Health Checks an, damit neue Knoten zuverlässig ins Backend aufgenommen werden.
• Zusätzliche LB-Knoten: Für hohe Verfügbarkeit und größere Kapazität können zusätzliche LB-Knoten eingeführt werden. VRRP/Keepalived sorgt dann für Floating VIPs und automatisches Failover.
• IPVS/LVS für extrem hohen Durchsatz: In sehr anspruchsvollen Umgebungen lässt sich IPVS/LVS als Layer-4-In-Kernel-Lastausgleich mit HAProxy kombinieren. IPVS bietet extrem schnellen Durchsatz, während HAProxy fortgeschrittene Layer-7-Entscheidungen bereitstellt.
• Richtige Verteilung der Last: Kombinieren Sie verschiedene Lastverteilungsalgorithmen (z. B. Round Robin für Gleichverteilung, Least Connections für variierende Backend-Kapazitäten) und nutzen Sie health-based Routing, um ausgefallene Endpunkte konsequent zu umgehen.
• Zeitnahe Re-Konfiguration: Nutzen Sie hitless Reloads, um Konfigurationsänderungen ohne Verbindungsunterbrechung einzuspielen, insbesondere bei TLS-Erneuerungen und ACL-Anpassungen.

Zusammengefasst ermöglichen TLS-Termination, gezielte Firewall- und Netzwerksicherheitsmaßnahmen, sorgfältiges OS-Tuning sowie robuste Schutzmechanismen eine belastbare Load-Balancing-Architektur. Durch geschickte Skalierung und den Einsatz moderner TLS-Features lässt sich sowohl Sicherheit als auch Performance auf ein neues Level heben, während der Betrieb stabil und wartbar bleibt.

Fazit

Dieses Fazit bündelt die Kerngedanken: Mit zwei Webservern hinter zwei Load-Balancern, einer schwebenden VIP und VRRP-basiertem Failover entsteht eine Architektur, die Ausfälle elegant kaschiert und Wartung erleichtert. HAProxy übernimmt Frontend- und Backend-Logik, Health Checks sichern die Verfügbarkeit, Rolling-Updates ermöglichen Upgrades ohne Downtime, TLS-Termination entlastet die Backend-Server. Die VIP-Rotation sorgt dafür, dass Clients stabil bleiben, unabhängig davon, welcher Knoten Master oder Backup ist. In dieser Struktur wird Traffic sinnvoll ausbalanciert, Sicherheits- und Leistungsanforderungen lassen sich durch optionale TLS-Offloading, TLS-Passthrough oder ACL-Regeln abdecken. Die Beobachtung über Logs, Statistiken und Metriken macht Fehlersituationen frühzeitig sichtbar und erlaubt gezielte Gegenmaßnahmen.

Für den praktischen Betrieb empfiehlt sich eine schrittweise Vorgehensweise: Klar definierte Monitoring- und Teststrategien, regelmäßige Failover-Simulationen, automatisierte Backups von Konfigurationen und Zertifikaten, sowie eine sorgfältige Planung der Firewall- und Netzwerkregeln. Wer Skalierung plant, kann später zusätzliche Backend-Knoten oder weitere LB-Knoten ergänzen oder IPVS-basierte Lösungen für extremen Durchsatz evaluieren. So bleibt die Architektur nicht nur theoretisch hochverfügbar, sondern auch im Alltag zuverlässig, sicher und wartbar.