Lastausgleich und Failover

1) Ziele und Begriffe

Balancing verteilt den Verkehr zwischen Instanzen/Zonen/Regionen für Leistung und Nachhaltigkeit.
Failover - Kontrolliertes Failover.
RTO/RPO: Zielwiederherstellungszeit und zulässiger Datenverlust.
SLO: Zielwert für Verfügbarkeit/Latenz; dient als „Tor“ zum automatischen Failover und Rollback.

2) Ausgleichsschichten

2. 1 L4 (TCP/UDP)

Vorteile: Leistung, Einfachheit, TLS passthrough. Nachteile: kein Verständnis der Route/Cookies.
Beispiele: NLB/GLB, HAProxy/Envoy L4, IPVS.

2. 2 L7 (HTTP/gRPC)

Vorteile: Routing auf Pfad/Header, Kanariengewichte, Sticky. Nachteile: teurer durch CPU/Latenz.
Beispiele: NGINX/HAProxy/Envoy/Cloud ALB/API Gateway.

2. 3 Globale Ebene

DNS/GSLB: health-checks + geo/weighted response.
Anycast/BGP: eine IP um die Welt, der nächste Ankündigungspunkt.
CDN/Edge: Cache/Failover am Perimeter.

3) Verteilungsalgorithmen

Round-robin/weighted sind einfach.
Least connections/latency - für „schwere“ Anfragen.
Consistent hashing - Tastenklammer (user/tenant) ohne Center-Sitzung.
Hash-basierte Lokalität - für Caches und stateful-Dienste.

4) Sitzungen und Klebrigkeit (sticky)

Cookie-Sticky: L7 LB setzt ein Cookie, um zur Instanz zurückzukehren.
Src-IP-Stick: bei L4, schlechter bei NAT/CGNAT.
Consistent Hashing: besser für horizontale Caches/Chats.
Aim: Wenn möglich, machen Sie den Service stateless, sonst - nehmen Sie den Status (Sitzungen in Redis/DB), um den Failover zu vereinfachen.

5) Zuverlässigkeit: Gesundheitschecks und Rückzug aus der Rotation

Aktive Prüfungen: HTTP 200/Deep Business Path Tests (z.B. '/healthz/withdraw 'mit Abhängigkeiten).
Passive (Outlier detection): Ausstoßen von Backends bei 5xx/Timeouts.
Warm-up: reibungslose Einbeziehung neuer Instances (Slow-Start).
Graceful drain: Entfernen Sie aus dem Pool → warten Sie, bis die Anforderungen abgeschlossen sind.

NGINX (Beispiel):

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

Envoy outlier detection (Fragment):

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6) Störungsmanagement: Timeout/Retry/Circuit-Breaking

Timeouts: kürzer als das Timeout des Kunden; Per-Route festlegen.
Retries: 1-2 mit Jitter und Idempotenz; Verbot von POST-Retrays ohne Idempotenzschlüssel.
Circuit Breaker: Begrenzung gleichzeitiger Anfragen/Fehler; „halboffene“ Erholung.
Budgets: Grenzen von Retrays/Fusion von Bursten, um keine Self-DDOS zu arrangieren.

7) Kubernetes-Muster

ClusterIP/NodePort/LoadBalancer/Ingress sind grundlegende Primitive.
Bereitschaft/Gelassenheit: Verkehr nur zu fertigen Pods.
PodDisruptionBudget: Gleichzeitiges Herunterfallen von N Replikaten nicht zulassen.
HPA/VPA: Skalierung nach CPU/RED-Metriken, Verknüpfung mit LB.
ServiceTopology/Topology Aware Hints: Lokalität nach Zone.
Service type = LoadBalancer (zonal): Minimum - 2 Replikate pro AZ.

Beispiel für Readiness für eine kritische Route:

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8) Zonenübergreifender und überregionaler Verkehr

Multi-AZ (innerhalb der Region): gleichmäßig verteilen (zonal LB), Speicher - synchrone Replikate.

Multi-region:

Aktiv-Aktiv: Beide Regionen dienen dem Verkehr; schwieriger - Sie benötigen Datenreplikation, Konsistenz und Geografie-Routing.
Aktiv-Passiv: Hauptregion dient, Reserve ist „warm/warm/kalt“. Einfacher, schneller wechseln, aber höher als RPO.

GSLB Strategie:

Geo-DNS (nächstgelegene Region).
Gewichtetes DNS (Kanarienvögel/Umverteilung).
Latenzbasiert (RTT-Messungen).
Failover = durch Gesundheits-/Verfügbarkeitssignale (Proben von mehreren Vantage-Punkten).

9) Daten und Failover

Cash/State: wenn möglich - regional lokal; für Aktiv-Aktiv - CRDT/konsistente Hashes.

DB:

Synchrone Replikation = niedriger RPO, höhere Latenz.
Asynchron = niedrigere Latenz, aber RPO> 0.
Warteschlangen: Spiegelung/Multi-Cluster-Topics; Ereignisdeduplizierung.
Entwerfen Sie die Idempotenz von Operationen und Replay-Mechanik.

10) Umfang: DNS/Anycast/BGP/CDN

DNS: kurze TTL (30-60s) + Gesundheitschecks außerhalb Ihres Netzwerks.
Anycast: Mehrere ROPs mit einer IP - der nächste akzeptiert Datenverkehr, ein Failover auf Routing-Ebene.
CDN/Edge: Cache und „Gateway“ für den Schutz, Statik/Medien werden bedient, wenn der Ursprung fällt; origin-shield + пер-POP health.

11) Beispielkonfigurationen

HAProxy L7:

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

NGINX sticky по cookie:

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

Envoy retry/timeout (route):

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12) Automatischer Failover: Signale und Tore

Tech-SLI: 5xx-rate, p95/p99, saturation, TLS handshakes, TCP resets.
Business SLI: Erfolg der Einzahlungen/Auszahlungen, keine Zahlungsfehler bei der PSP.
Gates: Wenn die Schwellenwerte überschritten werden, deaktivieren Sie die Zone/Instance, heben Sie die Gewichte des stabilen Pools an und schalten Sie die GSLB ein.
Runbook: Schritt für Schritt Anleitung zum Umschalten und Zurückfahren (Rollback).

13) Tests und Inspektionen (Chaos & Spieltage)

Chaos-Tests: AZ/Regionen abschalten, DB/Cache Degradation, Packet-Loss Simulation.
Game-Day: Ein Trainings-Failover mit On-Call-Teams.
Diagnose: Trace vom Perimeter zum Backend, Zuordnung von Release Annotationen und Metriken.

14) Sicherheit und Compliance

mTLS zwischen LB↔servisy, WAF/Rate Limits am Perimeter.
Fehler-/Segmentierungszonen: Blast-Radius-Isolation.
Politik: Verbot von Single Failure Points (SPOF), Vorgaben nach „mindestens N Repliken/AZ“.

15) Anti-Muster

Eine LB/eine Zone für den gesamten Prod-Verkehr (SPOF).
Keine Tiefenprüfung '/healthz'(grün - aber DB/Warteschlange nicht verfügbar).
Rückzugsort ohne Idempotenz → doppelte Transaktionen/Zahlungen.
Sticky per IP mit massivem NAT → Ungleichgewicht.
DNS-Failover mit hoher TTL (Stunden vor dem Wechsel).
Kein graceful drain beim Deployment - Clipping Anfragen.

16) Implementierung Checkliste (0-45 Tage)

0-10 Tage

Instanzen auf AZ- ≥2 verteilen; Aktivieren Sie readiness/liveness, health-checks.
Konfigurieren Sie L7-timeouts/retries (1 Versuch), outlier detection.
Aktivieren Sie graceful drain und slow-start.

11-25 Tage

Geben Sie GSLB (geo/weighted) oder Anycast für den Umfang ein.
Kanarische Gewichte/Routenrichtlinien; sticky via cookie/consistent hash.
SLO-Gates für Auto-Failover (p95/5xx + Business-SLI).

26-45 Tage

Regional DR: Aktiv-Aktiv oder Aktiv-Passiv mit Übersetzungstest.
Chaos-Tage mit AZ/Regionen aus, RTO/RPO-Berichte.
Automatisierte Runbooks' und (Pause/Shift/Rollback-Skripte).

17) Reifegradkennzahlen

Die Multi-AZ-Abdeckung ≥ 99% der kritischen Pfade.
DNS/GSLB/Anycast sind für öffentliche Endpunkte implementiert.
MTTR, wenn ein AZ <5 Minuten fällt (p95).
RPO für kritische Daten ≤ Ziel (z. B. ≤ 30 Sekunden).
Vierteljährliche Spieltage und ein erfolgreicher geplanter Failover.

18) Schlussfolgerung

Zuverlässiges Balancing und Failover ist eine geschichtete Architektur: lokale L7-Richtlinien (Timeouts/Retries/CB, Health-Checks), korrekte Tackness und Hashing, Cross-Zone-Stabilität und GSLB/DNS/Anycast am Perimeter. Fügen Sie SLO-Gates, Idempotenz, graceful drain und regelmäßige Chaos-Tests hinzu - und jeder Verlust eines Knotens, einer Zone oder sogar einer Region wird zu einem überschaubaren Ereignis mit vorhersehbarem RTO/RPO.

Lastausgleich und Failover