Load Balancing

KAPITEL 10 · ENTERPRISE IT

Load Balancing

Lastverteilung in der Enterprise IT – Algorithmen, Methoden, L4/L7 Load Balancer, Health Checks und Best Practices für hochverfügbare Infrastrukturen.

Algorithmen L4 & L7 Health Checks HAProxy & Nginx Cloud LB

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernst du alles über Load Balancing:

  • Definition: Was ist Load Balancing und warum ist es wichtig?
  • Vorteile: Skalierbarkeit, Verfügbarkeit, Performance
  • Algorithmen: Round Robin, Least Connections, IP Hash, Weighted
  • OSI-Layer: L4 (Transport) vs. L7 (Application) Load Balancing
  • Typen: Hardware, Software, Cloud, DNS Load Balancing
  • Health Checks: Server-Überwachung und Failover
  • Session Persistence: Sticky Sessions
  • Lösungen: HAProxy, Nginx, AWS ELB, Azure Load Balancer
  • Konfiguration: Praxisbeispiele für HAProxy und Nginx
  • Best Practices: Sicherheit, Monitoring, Testing
  • FAQ: Häufige Fragen zu Load Balancing

1. Was ist Load Balancing?

Definition

Load Balancing (Lastverteilung) ist die Verteilung von Netzwerk- oder Anwendungs-Traffic auf mehrere Server, um die Last gleichmäßig zu verteilen, die Verfügbarkeit zu erhöhen und die Performance zu optimieren.

Ein Load Balancer fungiert als "Traffic Cop" (Verkehrspolizist) – er empfängt alle eingehenden Anfragen und leitet sie an die verfügbaren Backend-Server weiter. Dadurch wird verhindert, dass ein einzelner Server überlastet wird, während andere untätig sind.

Einfache Analogie: Stell dir eine Supermarkt-Kasse vor. Wenn nur eine Kasse geöffnet ist, bildet sich eine lange Schlange. Load Balancing ist wie mehrere geöffnete Kassen – die Kunden werden gleichmäßig verteilt, und alle werden schneller bedient.

Warum Load Balancing?

Die wichtigsten Vorteile auf einen Blick:

Skalierbarkeit

Horizontale Skalierung durch Hinzufügen weiterer Server. Keine Limits durch einzelne Hardware.

Hochverfügbarkeit

Redundanz durch mehrere Server. Fällt ein Server aus, übernehmen andere automatisch.

Bessere Performance

Gleichmäßige Lastverteilung verhindert Überlastung einzelner Server. Schnellere Antwortzeiten.

Wartung ohne Downtime

Server können einzeln gewartet werden, während andere den Traffic übernehmen (Zero Downtime).

Sicherheit

DDoS-Schutz, SSL-Terminierung, Web Application Firewall (WAF) Integration.

Flexibilität

Verschiedene Algorithmen, Health Checks, Session Persistence, SSL-Offloading.

2. Load Balancing Algorithmen

Der Algorithmus bestimmt, wie der Load Balancer Anfragen auf die Backend-Server verteilt. Die Wahl des richtigen Algorithmus hängt von der Anwendung und den Anforderungen ab.

ALGO 01

Round Robin

Reihum-Verteilung

Verteilt Anfragen der Reihe nach auf alle Server. Einfach und gleichmäßig.

  • Einfach zu implementieren
  • Gleichmäßige Verteilung
  • Keine Server-Überwachung nötig
  • Gut für homogene Server
Einsatzgebiete
Komplexität: Niedrig
Sticky Sessions: Nein
Health Checks: Optional
ALGO 02

Least Connections

Wenigste Verbindungen

Leitet Anfragen an den Server mit den wenigsten aktiven Verbindungen weiter.

  • Dynamische Lastverteilung
  • Berücksichtigt Server-Auslastung
  • Gut für lange Verbindungen
  • Verhindert Überlastung
Einsatzgebiete
Komplexität: Mittel
Sticky Sessions: Nein
Health Checks: Erforderlich
ALGO 03

IP Hash

Client-IP-basiert

Berechnet einen Hash aus der Client-IP und leitet immer an denselben Server weiter.

  • Session Persistence (Sticky Sessions)
  • Gleicher Client → gleicher Server
  • Gut für stateful Anwendungen
  • Keine zentrale Session-Store nötig
Einsatzgebiete
Komplexität: Mittel
Sticky Sessions: Ja (automatisch)
Nachteil: Ungleiche Last bei NAT
ALGO 04

Weighted Round Robin

Gewichtete Verteilung

Round Robin mit Gewichtung. Leistungsstärkere Server erhalten mehr Anfragen.

  • Berücksichtigt Server-Kapazität
  • Flexible Gewichtung
  • Gut für heterogene Server
  • Manuelle Konfiguration nötig
Einsatzgebiete
Komplexität: Mittel
Sticky Sessions: Nein
Beispiel: Server A: 3, B: 2, C: 1
ALGO 05

Random

Zufällige Verteilung

Verteilt Anfragen zufällig auf alle verfügbaren Server. Einfach, aber unvorhersehbar.

  • Sehr einfach
  • Keine Server-Überwachung
  • Unvorhersehbare Verteilung
  • Selten in Produktion genutzt
Einsatzgebiete
Komplexität: Sehr niedrig
Sticky Sessions: Nein
Empfehlung: Nur für Tests
ALGO 06

URL Hash

URL-basierte Verteilung

Berechnet einen Hash aus der URL und leitet immer an denselben Server für dieselbe URL.

  • Cache-Optimierung
  • Gleiche URL → gleicher Server
  • Gut für Caching-Server
  • L7 Load Balancing nötig
Einsatzgebiete
Komplexität: Hoch
Sticky Sessions: Ja (URL-basiert)
Layer: L7 (Application)

Welcher Algorithmus für welche Anwendung?

  • Web-Anwendungen (stateless): Round Robin oder Least Connections
  • Stateful Anwendungen (Sessions): IP Hash oder Sticky Sessions
  • Heterogene Server: Weighted Round Robin
  • Caching-Server: URL Hash
  • Lange Verbindungen (WebSocket): Least Connections
  • Database-Clustering: Least Connections + Health Checks

3. L4 vs. L7 Load Balancing

Load Balancer arbeiten auf verschiedenen OSI-Layern. Die Wahl zwischen L4 und L7 hängt von den Anforderungen ab.

L4 Load Balancer (Transport Layer)

TCP/UDP-basiert
  • Arbeitet auf Layer 4 (TCP/UDP)
  • Sieht nur IP + Port
  • Keine HTTP-Inspektion
  • Sehr schnell (geringer Overhead)
  • Gut für Non-HTTP-Protokolle
  • Einfache Konfiguration
Einsatzgebiete:
• Datenbank-Clustering (MySQL, PostgreSQL)
• Mail-Server (SMTP, IMAP)
• Gaming-Server
• DNS-Server
• Generische TCP/UDP-Dienste

L7 Load Balancer (Application Layer)

HTTP/HTTPS-basiert
  • Arbeitet auf Layer 7 (HTTP/HTTPS)
  • Sieht URL, Header, Cookies
  • Content-based Routing
  • SSL-Terminierung möglich
  • Intelligentes Routing
  • Höherer Overhead
Einsatzgebiete:
• Web-Anwendungen
• REST APIs
• Microservices-Architekturen
• Content-basiertes Routing
• A/B Testing
• Canary Deployments
Eigenschaft L4 Load Balancer L7 Load Balancer
OSI-Layer Layer 4 (Transport) Layer 7 (Application)
Protokolle TCP, UDP HTTP, HTTPS, WebSocket
Sichtbare Daten IP + Port URL, Header, Cookies, Body
Performance Sehr hoch Hoch (etwas Overhead)
SSL-Terminierung Nein Ja
Content Routing Nein Ja (URL, Header, etc.)
Komplexität Niedrig Hoch
Typische Nutzung Datenbanken, Mail, Gaming Web, APIs, Microservices

Wann L4, wann L7?

  • L4 wählen: Wenn Performance kritisch ist, Non-HTTP-Protokolle genutzt werden oder einfache Lastverteilung ausreicht
  • L7 wählen: Wenn intelligentes Routing nötig ist, SSL-Terminierung gewünscht ist oder HTTP-spezifische Features benötigt werden
  • Beide kombinieren: L7 für Web-Traffic, L4 für Datenbank-Clustering

4. Load Balancer Typen

Load Balancer gibt es in verschiedenen Ausführungen – von dedizierter Hardware bis zu Cloud-Diensten.

Hardware Load Balancer

Dedizierte Appliances

Spezialisierte Hardware-Appliances für Enterprise-Umgebungen. Maximale Performance und Features.

  • Maximale Performance
  • Alle Features integriert
  • Hochverfügbar (HA)
  • Enterprise Support
  • Sehr teuer
Beispiele:
F5 BIG-IP, Citrix ADC, A10 Thunder, Radware

Software Load Balancer

Open Source Lösungen

Software-basierte Load Balancer, die auf Standard-Servern laufen. Flexibel und kostengünstig.

  • Kostengünstig (oft Open Source)
  • Flexibel konfigurierbar
  • Auf Standard-Hardware
  • Gute Community
  • Eigenes Setup nötig
Beispiele:
HAProxy, Nginx, Traefik, Envoy, Caddy

Cloud Load Balancer

Managed Services

Load Balancing als Service von Cloud-Providern. Fully managed, automatisch skalierend.

  • Fully managed
  • Auto-Scaling
  • Pay-per-Use
  • Integration mit Cloud-Diensten
  • Vendor Lock-in
Beispiele:
AWS ELB/ALB/NLB, Azure Load Balancer, GCP Cloud Load Balancing

DNS Load Balancing

DNS-basierte Verteilung

Verteilung auf DNS-Ebene durch mehrere A-Records oder Geo-DNS. Einfach, aber limitiert.

  • Sehr einfach
  • Keine spezielle Hardware
  • Geo-Routing möglich
  • Kein Health Checking
  • DNS-Caching-Probleme
Beispiele:
Round-Robin DNS, GeoDNS, AWS Route 53, Cloudflare DNS

5. Health Checks & Failover

Health Checks überwachen die Verfügbarkeit der Backend-Server. Fällt ein Server aus, wird er automatisch aus dem Pool entfernt.

Arten von Health Checks

Passive Health Checks: Der Load Balancer überwacht die Antworten der Server. Wenn ein Server nicht antwortet oder Fehler zurückgibt, wird er als "unhealthy" markiert.

Active Health Checks: Der Load Balancer sendet regelmäßig Anfragen an die Server (z.B. HTTP GET auf /health) und prüft die Antwort.

Health Check Typen

Passive Health Checks

Überwachen tatsächliche Anfragen. Wenn ein Server keine Antwort gibt oder Fehler zurückgibt, wird er als ausgefallen markiert.

  • Kein zusätzlicher Traffic
  • Reagiert auf echte Probleme
  • Kann zu spät erkennen
Active Health Checks

Senden regelmäßig spezielle Anfragen (z.B. HTTP GET /health) an die Server, um deren Verfügbarkeit zu prüfen.

  • Proaktive Erkennung
  • Schnelle Reaktion
  • Zusätzlicher Traffic
Hybrid Health Checks

Kombination aus passiven und aktiven Checks für maximale Zuverlässigkeit und schnelle Erkennung.

  • Beste Erkennung
  • Redundanz
  • Höhere Komplexität
Health Check Typ Beschreibung Beispiel
TCP Check Prüft, ob der Port erreichbar ist Port 80, 443, 3306
HTTP Check Sendet HTTP GET und prüft Status-Code GET /health → 200 OK
HTTPS Check Wie HTTP, aber mit SSL/TLS GET /health → 200 OK (TLS)
Custom Script Eigenes Script prüft Server-Status Shell-Script, Python-Script
Application Check Prüft spezifische Anwendungslogik Datenbank-Verbindung, API-Test

Health Check Konfiguration

HAProxy # Health Check Konfiguration in HAProxy backend web_servers balance roundrobin # HTTP Health Check option httpchk GET /health http-check expect status 200 # Server mit Health Check Parametern server web1 192.168.1.10:80 check inter 5s fall 3 rise 2 server web2 192.168.1.11:80 check inter 5s fall 3 rise 2 server web3 192.168.1.12:80 check inter 5s fall 3 rise 2 # Parameter: # inter 5s = Check alle 5 Sekunden # fall 3 = 3 fehlgeschlagene Checks = Server down # rise 2 = 2 erfolgreiche Checks = Server wieder up

Best Practices für Health Checks

  • Intervall anpassen: Nicht zu häufig (Overhead), nicht zu selten (langsame Erkennung)
  • Fall/Rise Werte: Verhindert Flapping bei kurzzeitigen Problemen
  • Timeout setzen: Lange Timeouts vermeiden
  • Echten Endpunkt nutzen: Nicht nur /, sondern /health oder /status
  • Dependency-Checks: Datenbank, Cache, externe APIs prüfen
  • Monitoring: Health Check Ergebnisse überwachen und alerten

6. Session Persistence (Sticky Sessions)

Manche Anwendungen benötigen, dass ein Client immer mit demselben Server kommuniziert (z.B. für Sessions, Shopping Carts).

Was sind Sticky Sessions?

Sticky Sessions (Session Persistence) stellen sicher, dass alle Anfragen eines Clients während einer Session an denselben Backend-Server weitergeleitet werden.

Beispiel: Ein Nutzer legt Produkte in den Warenkorb. Der Warenkorb wird serverseitig gespeichert. Ohne Sticky Sessions könnte die nächste Anfrage an einen anderen Server gehen, der den Warenkorb nicht kennt.

Session Persistence Methoden

Cookie-basiert

Load Balancer setzt ein Cookie, das den Server identifiziert. Bei nachfolgenden Anfragen wird der Benutzer zum selben Server geleitet.

Source IP Hash

Berechnet einen Hash aus der Client-IP. Gleiche IPs landen immer auf demselben Server (funktioniert nicht hinter NAT/Proxy).

URL Parameter

Server-ID wird als URL-Parameter übergeben (z.B. ?server=2). Einfach, aber unsicher und sichtbar.

Shared Session Store

Sessions werden in einer zentralen Datenbank (Redis, Memcached) gespeichert. Server-unabhängig, aber komplexer.

Methode Beschreibung Vorteile Nachteile
IP Hash Hash aus Client-IP bestimmt Server Einfach, automatisch Problem bei NAT, ungleiche Last
Cookie-based Load Balancer setzt Cookie mit Server-ID Genau, flexibel Cookie-Overhead
Session Cookie Bestehendes Session-Cookie wird genutzt Kein zusätzliches Cookie App-spezifisch
SSL Session ID SSL-Session-ID wird genutzt Transparent Nur bei HTTPS

Alternative: Statelesse Anwendungen

Die bessere Lösung ist oft, Anwendungen stateless zu designen:

  • Session-Store: Sessions in Redis oder Memcached speichern
  • Token-basierte Auth: JWT-Tokens statt serverseitiger Sessions
  • Shared Storage: Uploads in S3 oder Shared Filesystem
  • Database: Alle Daten in zentraler Datenbank

Stateless Anwendungen können von jedem Server bedient werden – kein Sticky Sessions nötig!

7. Load Balancing Lösungen

Die wichtigsten Load Balancing Lösungen im Überblick – von Open Source bis Enterprise.

HAProxy

Open Source Standard

Der meistgenutzte Open Source Load Balancer. Extrem performant und zuverlässig.

  • L4 & L7 Load Balancing
  • Sehr hohe Performance
  • SSL-Terminierung
  • Health Checks
  • Kostenlos & Open Source
Details Lizenz: GPL v2
Plattform: Linux, Unix
Einsatz: Web, Datenbank, Mail

Nginx

Web Server & Load Balancer

Nginx ist primär ein Web Server, aber auch ein leistungsstarker Load Balancer.

  • Web Server + LB in einem
  • L7 Load Balancing
  • Reverse Proxy
  • Caching-Funktionen
  • Nginx Plus (kommerziell)
Details Lizenz: BSD / Commercial
Plattform: Linux, Unix, Windows
Einsatz: Web, APIs, Microservices

AWS Elastic Load Balancing

Cloud Load Balancer

Managed Load Balancing Service von Amazon Web Services. Auto-Scaling integriert.

  • Application LB (L7)
  • Network LB (L4)
  • Gateway LB (L3)
  • Auto-Scaling
  • AWS Integration
Details Lizenz: Pay-per-Use
Plattform: AWS Cloud
Einsatz: Alle AWS-Workloads

Azure Load Balancer

Microsoft Cloud LB

Load Balancing Service von Microsoft Azure. L4-basiert, hochverfügbar.

  • Public & Internal LB
  • L4 Load Balancing
  • Multi-Region
  • Azure Integration
  • Application Gateway (L7)
Details Lizenz: Pay-per-Use
Plattform: Azure Cloud
Einsatz: Azure VMs, AKS

Google Cloud Load Balancing

Global Load Balancer

Globaler Load Balancing Service von Google Cloud. Multi-Region, Anycast-basiert.

  • Global Load Balancing
  • HTTP(S), TCP/SSL, UDP
  • Anycast IP
  • Cloud Armor (DDoS)
  • GKE Integration
Details Lizenz: Pay-per-Use
Plattform: GCP Cloud
Einsatz: GCE, GKE, Cloud Run

F5 BIG-IP

Enterprise Hardware LB

Enterprise Load Balancer mit dedizierter Hardware. Maximale Features und Performance.

  • Hardware Appliance
  • Alle L4/L7 Features
  • WAF Integration
  • iRules (Scripting)
  • Enterprise Support
Details Lizenz: Kommerziell
Plattform: Hardware / VM
Einsatz: Enterprise, Datacenter

8. Konfiguration – Praxisbeispiele

Konkrete Konfigurationsbeispiele für HAProxy und Nginx.

HAProxy Konfiguration

HAProxy # /etc/haproxy/haproxy.cfg global log /dev/log local0 maxconn 4096 user haproxy group haproxy daemon defaults log global mode http option httplog option dontlognull timeout connect 5000ms timeout client 50000ms timeout server 50000ms # Stats Web-Interface listen stats bind *:8080 stats enable stats uri /stats stats auth admin:password # Frontend: Empfängt Traffic frontend http_front bind *:80 bind *:443 ssl crt /etc/ssl/certs/site.pem default_backend web_servers # Backend: Server-Pool backend web_servers balance roundrobin option httpchk GET /health server web1 192.168.1.10:80 check server web2 192.168.1.11:80 check server web3 192.168.1.12:80 check

Nginx Konfiguration

Nginx # /etc/nginx/nginx.conf # Upstream: Server-Pool definieren upstream backend_servers { # Load Balancing Algorithm least_conn; # oder: ip_hash, random, etc. # Backend Server server 192.168.1.10:80 weight=3; server 192.168.1.11:80 weight=2; server 192.168.1.12:80 backup; # Nur bei Ausfall # Health Check (Nginx Plus) # health_check uri=/health interval=5s; } server { listen 80; server_name example.com; # SSL Konfiguration listen 443 ssl; ssl_certificate /etc/ssl/certs/site.crt; ssl_certificate_key /etc/ssl/private/site.key; # Proxy zum Backend location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # Timeout Settings proxy_connect_timeout 5s; proxy_read_timeout 30s; } # Health Check Endpoint location /health { access_log off; return 200 "OK"; } }

Wichtige Konfigurations-Parameter

  • balance: Algorithmus wählen (roundrobin, least_conn, ip_hash)
  • weight: Gewichtung für heterogene Server
  • backup: Backup-Server nur bei Ausfall nutzen
  • check: Health Checks aktivieren
  • maxconn: Maximale Verbindungen pro Server
  • timeout: Timeouts für verschiedene Phasen

9. Best Practices

Die wichtigsten Empfehlungen für den Betrieb von Load Balancern.

Health Checks

  • Active Health Checks konfigurieren
  • Sinnvolle Intervalle wählen
  • Fall/Rise Werte anpassen
  • Echte Endpunkte prüfen (/health)
  • Dependency-Checks einbauen

Monitoring

  • Load Balancer Metriken überwachen
  • Response Times tracken
  • Error Rates alerten
  • Server-Auslastung beobachten
  • Stats-Dashboard einrichten

Sicherheit

  • SSL/TLS terminieren am LB
  • WAF integrieren
  • DDoS-Schutz aktivieren
  • Rate Limiting konfigurieren
  • Access Logs analysieren

Scaling

  • Auto-Scaling konfigurieren
  • Min/Max Server definieren
  • Scaling-Metriken wählen
  • Cooldown-Perioden setzen
  • Load Tests durchführen

Testing

  • Failover-Tests regelmäßig
  • Load Tests vor Go-Live
  • Chaos Engineering nutzen
  • Disaster Recovery testen
  • Config-Changes in Staging

Dokumentation

  • Config versionieren (Git)
  • Architektur dokumentieren
  • Runbooks erstellen
  • Change-Log führen
  • Emergency Contacts pflegen

High Availability (HA) Setup

Für maximale Verfügbarkeit sollten Load Balancer selbst redundant sein:

  • Active-Passive: Ein LB aktiv, einer standby (VRRP/Keepalived)
  • Active-Active: Beide LBs aktiv, teilen sich Last
  • Multi-Region: LBs in verschiedenen Rechenzentren
  • DNS Failover: DNS leitet zu verfügbarem LB

10. Load Balancing Algorithmen

Die Wahl des richtigen Algorithmus ist entscheidend für die Performance Ihrer Anwendung. Hier die wichtigsten Methoden:

Round Robin

Einfach & Gleichmäßig

Verteilt Anfragen reihum auf alle Server. Einfach, aber berücksichtigt nicht die Server-Last.

Server 1 → Server 2 → Server 3 → Server 1 → ...
Geeignet für: Homogene Server-Umgebungen mit ähnlicher Leistung

Least Connections

Lastbasiert

Leitet Anfragen an den Server mit den wenigsten aktiven Verbindungen weiter.

Server A: 15 Verbindungen Server B: 3 Verbindungen → Neue Anfrage an B
Geeignet für: Lange persistente Verbindungen (Datenbanken, Streaming)

IP Hash

Session Persistence

Berechnet einen Hash aus der Client-IP. Gleiche Clients landen immer auf demselben Server.

Hash(192.168.1.100) % 3 = 1 → Server 2 Hash(192.168.1.101) % 3 = 0 → Server 1
Geeignet für: Anwendungen mit Session-State (Shopping Carts, Logins)

Weighted Round Robin

Gewichtet

Weist jedem Server ein Gewicht zu. Stärkere Server erhalten mehr Anfragen.

Server A: Weight 3 → 3 Anfragen Server B: Weight 1 → 1 Anfrage Server C: Weight 2 → 2 Anfragen
Geeignet für: Heterogene Server-Umgebungen mit unterschiedlicher Leistung

Random

Zufällig

Wählt zufällig einen Server aus. Einfach, aber unvorhersehbar.

Zufallsgenerator → Server 2 Zufallsgenerator → Server 1 Zufallsgenerator → Server 3
Geeignet für: Kurzlebige Anfragen, wenn alle Server gleich sind

URL Hash

Content-basiert

Berechnet einen Hash aus der URL. Gleiche URLs landen immer auf demselben Server (Cache-freundlich).

Hash("/api/users") % 3 = 2 → Server 3 Hash("/api/products") % 3 = 0 → Server 1
Geeignet für: Caching-Server, CDNs, statische Inhalte
Algorithmus Komplexität Session Persistence Beste Anwendung
Round Robin Niedrig Nein Homogene Web-Server
Least Connections Mittel Nein Lange Verbindungen
IP Hash Mittel Ja (IP-basiert) Session-State Apps
Weighted Niedrig Nein Heterogene Server
Random Niedrig Nein Kurzlebige Anfragen
URL Hash Hoch Ja (URL-basiert) Caching, CDNs

10. FAQ – Häufige Fragen

Häufige Fragen zu Load Balancing

Brauche ich überhaupt einen Load Balancer?

Ein Load Balancer ist sinnvoll, wenn:

  • Du Hochverfügbarkeit benötigst
  • Ein Server die Last nicht alleine bewältigen kann
  • Du Wartungen ohne Downtime durchführen willst
  • Du skalierbare Architektur aufbauen möchtest
  • Du SSL-Terminierung zentralisieren willst

Für kleine Projekte mit wenig Traffic reicht oft ein einzelner Server.

HAProxy oder Nginx – was ist besser?

Beide sind hervorragend, haben aber unterschiedliche Stärken:

  • HAProxy: Spezialisiert auf Load Balancing, mehr Features, bessere Stats
  • Nginx: Web Server + LB in einem, einfacher für Web-Setups

Empfehlung: HAProxy für reine LB-Aufgaben, Nginx wenn du auch Web Server brauchst.

Wie viele Server sollte ich hinter einem Load Balancer betreiben?

Das hängt von der Last und Ausfallsicherheit ab:

  • Minimum: 2 Server (für Redundanz)
  • Empfehlung: 3+ Server (für Load + Redundanz)
  • Production: So viele wie nötig für Peak-Last + 1-2 Reserve

Wichtig: Immer mindestens 2 Server für Failover!

Was ist der Unterschied zwischen Load Balancer und Reverse Proxy?

Die Begriffe werden oft synonym verwendet, aber es gibt Unterschiede:

  • Reverse Proxy: Empfängt Anfragen und leitet sie an Backend weiter (kann auch Caching, SSL, etc.)
  • Load Balancer: Verteilt Anfragen auf mehrere Backends (spezialisierter Reverse Proxy)

Jeder Load Balancer ist ein Reverse Proxy, aber nicht jeder Reverse Proxy ist ein Load Balancer.

Wie handle ich SSL/TLS mit einem Load Balancer?

Es gibt drei Ansätze:

  • SSL-Terminierung am LB: LB entschlüsselt, leitet HTTP an Backend weiter (einfach, LB sieht Klartext)
  • SSL-Passthrough: LB leitet verschlüsselten Traffic durch (Backend macht SSL, LB sieht nichts)
  • SSL Re-Encryption: LB entschlüsselt und verschlüsselt erneut (sicher, aber Overhead)

Empfehlung: SSL-Terminierung am LB für die meisten Use Cases.

Was passiert, wenn der Load Balancer ausfällt?

Der Load Balancer ist ein Single Point of Failure – daher muss er redundant sein:

  • Active-Passive: Zweiter LB übernimmt automatisch (VRRP/Keepalived)
  • DNS Failover: DNS leitet zu anderem LB
  • Cloud LB: Provider-managed Redundanz

Ohne LB-Redundanz bedeutet ein LB-Ausfall Totalausfall!

Wie teste ich mein Load Balancing Setup?

Wichtige Tests für Load Balancer:

  • Failover-Test: Server einzeln abschalten, prüfen ob Traffic umgeleitet wird
  • Load Test: Tools wie Apache JMeter, k6, locust nutzen
  • Health Check Test: Health Endpoints manipulieren
  • Sticky Session Test: Prüfen ob Sessions erhalten bleiben
  • SSL Test: SSL Labs (ssllabs.com) nutzen
Cloud Load Balancer oder Self-Hosted?

Vor- und Nachteile:

  • Cloud LB: Managed, auto-scaling, teurer bei hohem Traffic, vendor lock-in
  • Self-Hosted: Volle Kontrolle, günstiger bei hohem Traffic, eigenes Setup nötig

Empfehlung: Cloud LB für Startups und variable Last, Self-Hosted für konstante hohe Last und spezielle Anforderungen.

Zusammenfassung

Die wichtigsten Punkte

  • Load Balancing: Verteilt Traffic auf mehrere Server für Skalierbarkeit und Verfügbarkeit
  • Algorithmen: Round Robin, Least Connections, IP Hash, Weighted, Random, URL Hash
  • L4 vs L7: L4 = TCP/UDP (schnell), L7 = HTTP (intelligent)
  • Typen: Hardware (F5), Software (HAProxy, Nginx), Cloud (AWS, Azure, GCP), DNS
  • Health Checks: Überwachen Server-Verfügbarkeit, automatisches Failover
  • Sticky Sessions: Session Persistence für stateful Anwendungen
  • Best Practices: Redundanz, Monitoring, Security, Testing, Dokumentation
  • HA vs HA: Load Balancer selbst muss redundant sein (Active-Passive/Active-Active)
  • SSL: Terminierung am LB (einfach) oder Passthrough (sicher)
  • Stateless Design: Besser als Sticky Sessions – Session-Store nutzen

Nächste Schritte

Bereit, Load Balancing einzusetzen? Hier ein empfohlener Weg:

  1. Anforderungen definieren: L4 oder L7? Welche Algorithmen?
  2. Lösung wählen: HAProxy, Nginx oder Cloud LB?
  3. Setup planen: Redundanz, SSL, Health Checks
  4. Konfiguration: Backend-Server, Algorithmus, Timeouts
  5. Testing: Failover, Load Tests, SSL-Tests
  6. Monitoring: Metriken, Alerts, Dashboards
  7. Dokumentation: Config versionieren, Runbooks erstellen

Weiterführende Themen

Hochverfügbarkeit

HA-Konzepte, Redundanz, Failover und Disaster Recovery.

Zu Hochverfügbarkeit
Netzwerk-Architektur

Netzwerk-Design, Topologien und Enterprise-Netzwerke.

Zur Netzwerk-Architektur
Cloud Computing

Cloud-Dienste, IaaS, PaaS, SaaS und Cloud-Architekturen.

Zu Cloud Computing
IT-Sicherheit

Sicherheitskonzepte, Firewall, DDoS-Schutz und Verschlüsselung.

Zur IT-Sicherheit