Load Balancing und High Availability

Siehe auch

Verwandte Artikel
Offizielle Dokumentation

Load Balancing (LB) und High Availability (HA) werden oft im gleichen Atemzug genannt, beantworten aber unterschiedliche Fragen. LB verteilt eingehenden Traffic auf mehrere, gleichzeitig aktive Backend-Systeme, damit die Last nicht einen einzelnen Host überrollt. HA sorgt dafür, dass ein Dienst seine Verfügbarkeit hält, wenn einzelne Komponenten ausfallen - typisch durch einen zweiten Knoten, der im Failover übernimmt. Die beiden Konzepte lassen sich kombinieren. In Linuxfabrik-Setups typisch: Apache HTTP Server mit mod_proxy_balancer als L7-Load-Balancer vor zwei Applikations-Servern, davor ein Paar Reverse-Proxies mit Keepalived als HA-VIP.

Begriffe

  • Fencing / Resource Fencing: Mechanismus, der einen Knoten zweifelsfrei aus dem Cluster entfernt, bevor ein anderer Knoten die gleiche Ressource übernimmt. Verhindert doppelte Zugriffe auf Shared Storage.

  • Floating IP / VIP: IP-Adresse, die nicht fest an einem Knoten klebt, sondern zwischen HA-Partnern wandert. Implementierungen: VRRP (Keepalived), Cluster-Resource (Pacemaker), Cloud-LB (AWS ELB, Azure LB, Hetzner Cloud LB).

  • Quorum: Mehrheitsentscheid der Cluster-Knoten, wer bei einem Kommunikationsabriss weiterarbeiten darf. Standardschwelle: mindestens die Hälfte plus eins der konfigurierten Knoten.

  • Split Brain: Zustand, in dem ohne Quorum zwei (oder mehr) Teilcluster gleichzeitig für die Ressource verantwortlich werden und parallel Schreibzugriffe zulassen. Datenverlust ist dann fast garantiert.

  • STONITH: „Shoot The Other Node In The Head“. Harte Variante von Fencing, bei der dem abweisenden Knoten typisch via schaltbarer Stromleiste oder BMC/IPMI die Stromzufuhr entzogen wird.

  • VRRP (Virtual Router Redundancy Protocol): leichtgewichtiger Standard (RFC 5798) für Floating IPs zwischen zwei oder mehr Hosts im selben Subnetz. Linux-Referenz-Implementierung ist Keepalived.

Load Balancer: Layer 4 vs. Layer 7

Load Balancer werden nach der OSI-Schicht unterschieden, auf der sie Entscheidungen treffen.

Layer 4 (TCP/UDP)

Arbeiten rein auf Transportebene. Sie sehen die IP-Adressen und Ports, nicht aber den Inhalt der Pakete. Funktionieren dadurch applikationsunabhängig (MariaDB, RabbitMQ, Webserver, …), können aber keine Protokoll-Spezialitäten auswerten wie z.B. HTTP-Cookies oder Host-Header. TLS-Terminierung ist auf L4 nicht möglich; TLS-Durchreichen (SSL Passthrough) schon. Gebräuchliche Open-Source-Implementierungen:

  • HAProxy (beherrscht sowohl L4 als auch L7)

  • keepalived mit IPVS

  • Google Seesaw

Im Linux-Kernel wird L4-LB durch IPVS (IP Virtual Server) umgesetzt. Keepalived erzeugt dessen Konfiguration deklarativ; ipvsadm -Ln zeigt die aktiven Virtual-Server und Real-Server an.

Layer 7 (Application Protocol)

Terminieren TLS, inspizieren das Applikationsprotokoll und können Routing-Entscheidungen basierend auf Headern, Cookies, URLs oder anderen Protokoll-Eigenheiten treffen. Voraussetzung für Sticky Sessions, Path-basiertes Routing, Rate-Limiting auf HTTP-Ebene und Web-Application-Firewall-Funktionen. Gebräuchliche Open-Source-Implementierungen für HTTP(S):

  • Apache HTTP Server mit mod_proxy_balancer - Linuxfabrik-Standard für klassische Webserver-Setups

  • HAProxy

  • Nginx

Im Kubernetes-/Service-Mesh-Umfeld übernehmen spezialisierte Proxies (Envoy, Istio, Linkerd) L7-Load-Balancing zwischen Pods - gehören aber konzeptionell in ein eigenes Kapitel.

Scheduling-Algorithmen

Sobald mehrere Backends vorhanden sind, stellt sich die Frage, wie der Load Balancer Requests verteilt. Die gebräuchlichen Verfahren:

Round Robin (RR)

Requests werden reihum verteilt. Einfach und fair bei homogenen Backends, ignoriert aber aktuelle Last. Varianten: Weighted Round Robin (WRR) berücksichtigt unterschiedliche Leistung der Backends über Gewichte.

Least Connections (LC)

Request geht an das Backend mit den wenigsten offenen Verbindungen. Besser als RR bei ungleichmässig schweren Requests. Varianten: Weighted Least Connections (WLC) mit Gewichten.

Source Hash (SH) / IP Hash

Requests mit gleicher Client-IP landen immer auf dem gleichen Backend. Damit lassen sich Sticky Sessions auch ohne Cookie-Support realisieren. Problem: hinter einem grossen NAT-Gateway werden viele Clients als eine IP gesehen, was die Balance kippt.

Cookie-based Sticky Sessions (nur L7)

Der Load Balancer setzt ein eigenes Cookie (oder wertet ein vorhandenes aus) und leitet nachfolgende Requests des gleichen Clients auf das gleiche Backend. Einzig zuverlässige Methode für NAT-lastige Umgebungen.

IPVS in Linux unterstützt zusätzlich Verfahren wie lblc (Locality-Based Least Connection), sed (Shortest Expected Delay), nq (Never Queue) und mh (Maglev Hashing, seit Kernel 4.18) - vollständige Liste: man ipvsadm.

Health-Checks

Ein Load Balancer ohne Health-Checks verteilt Requests blind - inklusive auf tote Backends. Typische Check-Arten:

  • TCP-Check: Verbindet sich auf einen Port, ein erfolgreicher Drei-Wege-Handshake gilt als „gesund“. Einfach, aber oberflächlich - der Port kann offen sein, während die Applikation dahinter hängt.

  • HTTP/HTTPS-Check: ruft einen konfigurierten Pfad (z.B. /healthz) ab und prüft Response-Code oder Inhalt. Die Applikation sollte einen eigenen, leichtgewichtigen Health-Endpoint bereitstellen, der Downstream-Dependencies (DB-Verbindung, externe Dienste) mitprüft.

  • TLS-Check / SSL_GET: wie HTTP-Check, aber über TLS. Wichtig bei End-to-End-TLS ohne Terminierung am LB.

  • SMTP/DNS/Custom: Protokoll-spezifische Checks. Keepalived unterstützt SMTP_CHECK, DNS_CHECK, UDP_CHECK, BFD_CHECK sowie MISC_CHECK (externes Skript).

Die Intervalle sollten so gewählt sein, dass ein Ausfall innerhalb weniger Sekunden erkannt wird, aber nicht so aggressiv, dass Netzwerk-Glitches ständig Fehlalarme auslösen - typisch 2-5 s Intervall mit 2-3 Fehlversuchen bis zum Ausschluss.

TLS-Terminierung vs. Passthrough

TLS-Terminierung

Der Load Balancer terminiert TLS. Das Backend bekommt unverschlüsselten Traffic (oder re-verschlüsselt per Back-End-TLS). Vorteil: Inspektion auf L7 wird möglich, Zertifikatsverwaltung nur am LB. Nachteil: Kompromittierung des LB gibt Angreifern Zugriff auf Klartext.

TLS Passthrough (SNI-Routing)

Der Load Balancer liest nur das Server Name Indication aus dem TLS-Handshake und reicht den verschlüsselten Stream direkt durch. Nur möglich auf L4. Vorteil: End-to-End-Verschlüsselung, LB sieht keinen Klartext. Nachteil: keine Cookie-/Path-basierte Routing-Logik.

In Linuxfabrik-Setups ist der Normalfall die TLS-Terminierung am Apache-Reverse-Proxy mit eigenen Zertifikaten; Passthrough kommt dort zum Einsatz, wo regulatorische Anforderungen End-to-End-Verschlüsselung vorschreiben (z.B. Gesundheitsdaten, Zahlungsverkehr).

DNS-based Load Balancing

DNS-Round-Robin (mehrere A-Records für den gleichen Namen) ist eine einfache Form von LB ohne Infrastruktur-Aufwand: der DNS-Server liefert bei jedem Query eine rotierte Liste. Nachteile:

  • Die Verteilung läuft über Client-Caches; der Browser oder das OS cachen den ersten Treffer für die gesamte Session.

  • Fällt ein A-Record aus, spricht der Client unter Umständen noch minutenlang die tote IP an, bis der TTL abläuft.

  • Keine Health-Checks möglich (sofern nicht ein dedizierter DNS-Service wie Route 53 Health Checks, NS1 oder dnsdist mit Health-Check-Backend eingesetzt wird).

Einzig sinnvolle Anwendung: grobe geografische Verteilung („GeoDNS“), bei der die Latenz wichtiger ist als der saubere Failover.

High Availability: Pacemaker/Corosync vs. Keepalived

Im Open-Source-Linux-Umfeld stehen sich zwei grundsätzlich unterschiedliche Ansätze gegenüber:

TL;DR

  • Pacemaker + Corosync: garantiert, dass eine Ressource maximal einmal aktiv ist. Lieber gar kein Service als Datenkorruption durch Split Brain.

  • Keepalived: garantiert, dass ein Service mindestens einmal aktiv ist. Lieber doppelt angeboten als gar nicht verfügbar.

Corosync ist ein Cluster Communication Manager - er sorgt dafür, dass die Knoten im Cluster wissen, welche anderen Knoten ansprechbar sind und Quorum bilden. Pacemaker setzt darauf auf und verwaltet die eigentlichen Ressourcen (z.B. eine SAP-HANA- Datenbank, ein Cluster-Filesystem, eine virtuelle IP): er stellt sicher, dass jede Ressource zu jedem Zeitpunkt nur auf genau einem Knoten läuft. Fällt der Knoten aus, entscheidet der Rest per Quorum, wer übernehmen darf; wer kein Quorum hat, gibt seine Ressourcen auf. Für die konsequente Absicherung gegen Split Brain kommt typischerweise STONITH zum Einsatz.

Keepalived verfolgt den entgegengesetzten Ansatz: es stellt per VRRP eine Floating IP zwischen zwei oder mehr Hosts her. Fällt der Master aus, übernimmt der nächste Backup-Knoten die IP - ohne Quorum, ohne STONITH. Die Konsequenz ist deutlich einfacheres Setup und minimaler Overhead, aber auch keine Garantie gegen Split Brain (wenn die Knoten sich gegenseitig für tot halten, halten beide die VIP).

Zwar lassen sich mit Konfigurationsaufwand beide Produkte in Richtung der jeweils anderen Zielrichtung biegen (z.B. Keepalived mit aufwendigen track_script-Checks, die Datenbanken konsistent halten) - aber man merkt dabei schnell, dass die Tools dafür nicht ausgelegt sind.

Wann welches Tool?

Faustregeln als Entscheidungshilfe:

  • Ein Webdienst / API / ein einfacher Frontend-Cluster: Keepalived als HA-VIP, dahinter zwei Reverse-Proxies (bei der Linuxfabrik typisch Apache HTTP Server mit mod_proxy_balancer), die den Traffic auf die Backends verteilen. Einfach, robust, schnell aufgesetzt.

  • Eine Datenbank-Replikation mit Shared Storage oder einem Primary-Replica-Setup, bei dem kein zweiter Schreiber gleichzeitig laufen darf (SAP HANA, PostgreSQL + Patroni, Clustered MariaDB mit Galera als Ausnahme nicht): Pacemaker + Corosync mit STONITH.

  • In der Cloud: statt Keepalived typischerweise der Cloud-eigene Load Balancer (AWS ELB, Azure LB, Hetzner Cloud LB), der Failover und Health-Checks nativ abbildet. VRRP- Multicast ist in Cloud-VPCs meist ohnehin nicht verfügbar.

  • In Kubernetes: weder Keepalived noch Pacemaker. Die Cluster-Primitiven (Deployments, Services, Ingress) erledigen HA auf ihrer eigenen Ebene; für externe VIPs existieren Lösungen wie kube-vip oder MetalLB.

Fencing und STONITH im Detail

Ein Quorum löst nur die Frage, welche Cluster-Seite weiterarbeiten darf. Es garantiert nicht, dass die verlorene Seite ihre Ressourcen auch wirklich stoppt. Wenn ein Knoten zwar unerreichbar ist, aber dennoch weiterschreibt (etwa auf Shared Storage), kann die neue Master-Seite nicht einfach übernehmen, ohne Datenkorruption zu riskieren.

Mit aktivem Resource Fencing ruft ein Knoten vor der Übernahme einer Ressource einen Fencing-Agenten auf und wartet auf dessen positive Rückmeldung. Bleibt diese aus (z.B. weil die Fencing-Hardware ebenfalls unerreichbar ist), übernimmt der Knoten die Ressource bewusst nicht. STONITH ist die harte Umsetzung: dem verlorenen Knoten wird per schaltbarer Stromleiste, BMC/IPMI oder via Hypervisor-API der Strom gekappt - danach ist mit Sicherheit kein Schreibzugriff mehr möglich.

Mitgelieferte STONITH-Agenten findet man mit stonith -L, ihre Parameter via stonith -m -tNAME. Der Mechanismus kommt auch bei einem vom Admin initiierten Umzug einer Ressource zum Einsatz, wenn der abgebende Knoten nicht innerhalb des stop timeout stoppt.

Die konkrete Fencing-Konfiguration hängt von der Hardware ab: schaltbare Stromleisten, Remote-Management-Boards (BMC, IPMI) mit eigener Stromzufuhr, im virtualisierten Umfeld Fencing via vSphere-/Proxmox-/KVM-API.