Load Balancer: Lastverteilung für hohe Verfügbarkeit

1. Einführung: Warum Load Balancer unverzichtbar sind

Stell dir vor, deine Website wird plötzlich von 10.000 Besuchern gleichzeitig aufgerufen. Ein einzelner Server kann diese Last nicht bewältigen: Die CPU schießt in die Höhe, die Anfragen stauen sich, Benutzer sehen Timeout-Fehler und deine Website wird praktisch unbenutzbar.

Ein Load Balancer (Lastverteiler) löst dieses Problem: Er sitzt vor mehreren Backend-Servern und verteilt eingehende Anfragen intelligent auf sie. Wenn ein Server überlastet ist, leitet der Load Balancer neue Anfragen an weniger belastete Server weiter. Fällt ein Server aus, leitet er Anfragen auf die verbleibenden Server um – die Website bleibt verfügbar, ohne dass ein Benutzer etwas bemerkt.

Load Balancing ist nicht nur für große Websites notwendig. Auch mittelgroße Projekte profitieren von der erhöhten Verfügbarkeit und dem gesteigerten Durchsatz. In diesem Guide behandeln wir die Funktionsweise, verschiedene Algorithmen, Hardware vs. Software Lösungen und praktische Implementierung mit Nginx.

2. Was ist ein Load Balancer?

Ein Load Balancer ist eine Netzwerk-Komponente – Hardware, Software oder Cloud-Service – die eingehende Anfragen empfängt und nach definierten Regeln auf mehrere Backend-Server verteilt. Der Client sieht nur eine Adresse (die des Load Balancers), nicht die Adressen der einzelnen Backend-Server.

Kernfunktionen eines Load Balancers

• Anfrage-Verteilung: Verteilt Anfragen nach Algorithmen wie Round Robin, Least Connections, etc.
• Health Checks: Prüft regelmäßig, ob Backend-Server noch erreichbar sind
• Failover: Leitet Anfragen automatisch um, wenn ein Server ausfällt
• Session Persistence: Stellt sicher, dass Anfragen eines Clients immer zum gleichen Server gehen (falls gewünscht)
• SSL Offloading: Terminiert SSL/TLS-Verbindungen und reduziert CPU-Last auf Backend-Servern
• Kompression: Komprimiert Responses, um Bandbreite zu sparen

3. Wie funktioniert Load Balancing?

Der Ablauf ist simpel, aber wirkungsvoll:

1. 1
   Client sendet HTTP-Anfrage Der Client verbindet sich mit der IP oder dem Hostname des Load Balancers – nicht der Backend-Server.
2. 2
   Load Balancer empfängt Anfrage Der Load Balancer liest die Anfrage und wählt einen Backend-Server basierend auf einem Algorithmus aus.
3. 3
   Anfrage wird weitergeleitet Der Load Balancer leitet die Anfrage zum ausgewählten Backend-Server weiter – transparent für den Client.
4. 4
   Backend-Server verarbeitet Der Server verarbeitet die Anfrage normal und sendet die Response zurück an den Load Balancer.
5. 5
   Load Balancer sendet Response zurück Der Load Balancer leitet die Response an den Client weiter. Der Client sieht nur die Antwort, nicht, von welchem Server sie kam.

Health Checks – So erkennt der Load Balancer Ausfälle

Ein guter Load Balancer prüft regelmäßig (z.B. alle 5 Sekunden), ob die Backend-Server noch erreichbar sind. Das funktioniert durch:

• HTTP-Requests: Der LB sendet HTTP GET zu einer definierten URL (z.B. /health) und prüft auf Status 200
• TCP-Verbindungen: Der LB versucht, eine TCP-Verbindung auf einem Port (z.B. 80, 443) zu öffnen
• Custom Scripts: Bei Enterprise-Lösungen können Custom Health-Check-Scripts laufen

Wenn ein Server 3-5 Checks hintereinander fehlschlägt, wird er aus der Rotation entfernt – neue Anfragen gehen nur noch zu den verbleibenden Servern. Sobald ein Server wieder antwortet, wird er wieder eingebunden.

Session Persistence – Sticky Sessions

Bei manchen Anwendungen ist es wichtig, dass ein Client immer zum gleichen Backend-Server geht – etwa wenn der Session-State lokal auf dem Server gespeichert ist. Der Load Balancer kann "Sticky Sessions" nutzen:

• Cookie-basiert: Der LB setzt einen Cookie, der die Server-ID enthält
• IP-Hash: Der LB hasht die Client-IP und weist sie konsistent einem Server zu
• Timeout-basiert: Ein Client wird eine definierte Zeit dem gleichen Server zugeordnet

Moderne Best Practice: Sessions sollten in einer zentralen Session-Storage (z.B. Redis) abgelegt werden, nicht lokal auf Servern. Dann ist Sticky Sessions nicht nötig, und Skalierung wird viel einfacher.

4. Load Balancer Algorithmen im Detail

Der Algorithmus bestimmt, welcher Backend-Server für eine neue Anfrage gewählt wird. Jeder hat Vor- und Nachteile:

Für die meisten Fälle: "Least Connections" ist ein ausgezeichneter Kompromiss zwischen Einfachheit und Wirksamkeit. "Round Robin" reicht oft aus, wenn alle Server identisch sind.

5. Hardware vs. Software Load Balancer

Welcher Load Balancer passt zu deinem Unternehmen? Hier ist ein Vergleich:

6. Load Balancing bei Hosting-Anbietern

Viele Hosting-Provider bieten bereits verwaltete Load Balancer Services an. Hier ein Überblick:

Faustregel: Bei hohem Traffic oder Mission-Critical Applications lohnt sich ein Managed Load Balancer. Bei einfachen Web-Apps reicht oft auch Nginx auf einem einzelnen Server als Reverse Proxy.

7. Load Balancer mit Nginx einrichten: Schritt-für-Schritt

Nginx ist eine ausgezeichnete, kostenlose Lösung für Load Balancing. Hier zeigen wir eine praktische Konfiguration:

Schritt 1: Backend-Server definieren

In der Nginx-Konfiguration (/etc/nginx/nginx.conf) definierst du erst die Backend-Server als "Upstream":

upstream backend_servers {
    # Least Connections Algorithmus
    least_conn;

    # Backend-Server hinzufügen
    server 192.168.1.10:80 weight=1;
    server 192.168.1.11:80 weight=1;
    server 192.168.1.12:80 weight=1;

    # Keep-Alive für bessere Performance
    keepalive 32;
}

Schritt 2: Server-Block mit Reverse Proxy

server {
    listen 80;
    server_name example.com www.example.com;

    client_max_body_size 100M;

    location / {
        # Anfragen zum Upstream weiterleiten
        proxy_pass http://backend_servers;

        # Headers bewahren
        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-Einstellungen
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # Buffering
        proxy_buffering on;
        proxy_buffer_size 4k;
        proxy_buffers 8 4k;
    }
}

Schritt 3: Health Checks aktivieren (Nginx Plus)

Hinweis: Health Checks sind in der kostenlos Open-Source-Version von Nginx leider nicht integriert. Mit Nginx Plus (kommerzielle Version) geht es so:

upstream backend_servers {
    least_conn;

    server 192.168.1.10:80 weight=1 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:80 weight=1 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:80 weight=1 max_fails=3 fail_timeout=30s;

    # Health Check
    check interval=3000 rise=2 fall=5 timeout=1000 type=http;
    check_http_send "GET /health HTTP/1.0\r\n\r\n";
    check_http_expect_alive http_2xx;
}

Schritt 4: Nginx neuladen und testen

sudo nginx -t
sudo systemctl reload nginx

Teste den Load Balancer, indem du einen Backend-Server temporary offline nimmst:

sudo systemctl stop nginx  # auf 192.168.1.10

Anfragen sollten automatisch zu den verbleibenden zwei Servern gehen. Wenn du den Server wieder startest, wird er wieder eingebunden.

Sticky Sessions mit Nginx (Cookie-basiert)

Falls du Sticky Sessions brauchst, kannst du einen Cookie-basierten Ansatz mit Map nutzen:

map $cookie_serverid $upstream_server {
    ~^(?P<server>.+)$ $server;
    default "";
}

upstream backend_servers {
    server 192.168.1.10:80;
    server 192.168.1.11:80;
    server 192.168.1.12:80;
}

server {
    listen 80;
    server_name example.com;

    location / {
        set $upstream_server "";

        if ($upstream_server != "") {
            proxy_pass http://$upstream_server;
        }

        if ($upstream_server = "") {
            proxy_pass http://backend_servers;
        }

        add_header Set-Cookie "serverid=$upstream;Path=/";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

SSL/TLS Offloading

Der Load Balancer terminiert SSL und leitet unverschlüsselt zu Backend-Servern weiter – spart CPU auf den Backends:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    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;
    }
}

8. Load Balancer für Hochverfügbarkeit (HA-Setup)

Ein Load Balancer ist selbst ein Single Point of Failure. Wenn er ausfällt, ist deine Website offline. Für echte Hochverfügbarkeit brauchst du mehrere Load Balancer mit automatischem Failover.

Active-Passive Konfiguration mit Floating IP

Floating IP ist ein Feature von Hetzner Cloud und DigitalOcean: Eine IP kann schnell zwischen Servern wechseln.

• Server 1 (Nginx LB): Primary, hält Floating IP
• Server 2 (Nginx LB): Secondary, Standby
• Heartbeat-Service: Prüft ständig, ob Server 1 lebt
• Failover: Wenn Server 1 nicht antwortet, Floating IP zu Server 2 verschieben

Implementierung mit Keepalived

Keepalived ist ein Linux-Tool für HA-Failover:

sudo apt install keepalived

# Konfiguration auf Primary Server (/etc/keepalived/keepalived.conf)
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.1.200/24  # Floating IP
    }
}

# Auf Secondary Server: priority 99, state BACKUP

Mit dieser Konfiguration übernimmt der Secondary automatisch die Floating IP, wenn der Primary ausfällt.

Active-Active Konfiguration (Advanced)

Mit DNS Round Robin oder Global Load Balancer (z.B. Cloudflare) können mehrere Load Balancer aktiv sein:

• DNS antwortet mit mehreren IPs (LB1, LB2, LB3)
• Client verbindet sich mit einer zufälligen IP
• Jeder LB balanciert Anfragen zu den Backend-Servern
• Fällt ein LB aus, wählt der Client die nächste IP

9. Session Management bei Load Balancern

Bei mehreren Backend-Servern muss das Session Management neu überdacht werden. Drei Ansätze:

1. Sticky Sessions (Problematisch)

Sessions liegen lokal auf dem Server. Der Load Balancer stellt sicher, dass der Client immer zum gleichen Server geht. Probleme: Ungleiche Auslastung, wenn ein Server ausfällt, sind Sessions weg.

2. Distributed Session Store (Empfohlen)

Sessions werden in einer zentralen Datenbank (z.B. Redis, Memcached) gespeichert. Alle Server greifen darauf zu – jeder Server kann jede Session bearbeiten.

# Redis-Konfiguration (Redis.conf)
port 6379
bind 0.0.0.0
requirepass dein_starkes_passwort

# PHP-Beispiel (sessions in Redis)
session.save_handler = redis
session.save_path = "tcp://192.168.1.50:6379?auth=passwort"

# Node.js mit connect-redis
const session = require('express-session');
const RedisStore = require('connect-redis').default;
const { createClient } = require('redis');

const redisClient = createClient({ host: '192.168.1.50', port: 6379 });

app.use(session({
    store: new RedisStore({ client: redisClient }),
    secret: 'secret',
    resave: false,
    saveUninitialized: false
}));

3. Stateless Application (Ideal)

Die beste Lösung: Apps speichern keinen State. Alle Daten gehen in eine zentrale Datenbank (MySQL, PostgreSQL). Jeder Server ist austauschbar – perfekt für Auto-Scaling.

Best Practice: JWTs (JSON Web Tokens) für Authentifizierung. Der Token enthält alle nötigen Infos und wird vom Client mit jedem Request mitgesendet – kein Server-seitiger State nötig.

10. Sicherheit und Load Balancer

Load Balancer können Teil deiner Sicherheits-Strategie sein:

DDoS-Schutz Integration

Der Load Balancer sitzt vor deinen Servern und kann einfache DDoS-Angriffe filtern:

• Rate Limiting: Maximal N Requests pro IP pro Sekunde
• Connection Limits: Maximal M gleichzeitige Verbindungen pro IP
• IP-Blacklisting: Bekannte Bot-IPs blocken

Nginx Rate Limiting Beispiel

limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

server {
    listen 80;
    server_name example.com;

    location / {
        limit_req zone=one burst=20 nodelay;
        proxy_pass http://backend_servers;
    }
}

WAF Integration (Web Application Firewall)

Moderne Load Balancer können WAF-Rules durchsetzen – etwa gegen SQL Injection, XSS, etc.

• AWS WAF: Integriert mit AWS ALB/ELB
• Cloudflare WAF: Mit Cloudflare Load Balancer
• ModSecurity: Open Source WAF für Nginx/Apache

SSL/TLS Offloading (Sicherheit + Performance)

Der Load Balancer terminiert alle SSL-Verbindungen (CPU-intensiv). Zu den Backend-Servern kommuniziert er unverschlüsselt über das interne Netzwerk. Spart CPU auf den Backends und zentralisiert Certificate Management.

IP Whitelisting / Blacklisting

geo $country {
    default ZZ;
    ip 192.168.1.0/24 DE;
}

server {
    listen 80;

    # Nur deutsche IPs erlauben
    if ($country != "DE") {
        return 403;
    }

    location / {
        proxy_pass http://backend_servers;
    }
}

11. Monitoring und Auto-Scaling

Ein guter Load Balancer sollte metriken liefern und mit Auto-Scaling integriert sein:

Wichtige Metriken

• Request Rate: Anfragen pro Sekunde (RPS)
• Response Time / Latency: Durchschnittliche Antwortzeit
• Error Rate: Prozentsatz von 4xx/5xx Responses
• Active Connections: Aktuelle gleichzeitige Verbindungen
• Backend Health: Wie viele Backend-Server sind online?
• Bandwidth: Durchsatz in Mbit/s oder GB/s

Monitoring mit Prometheus + Grafana

Nginx-Metriken in Prometheus exportieren:

sudo apt install nginx-module-geoip2 prometheus-nginx-exporter

# Dann in Grafana visualisieren

Auto-Scaling

Bei Cloud-Providern (AWS, DigitalOcean, Hetzner) können Backend-Server automatisch hinzugefügt/entfernt werden:

• Wenn CPU > 80 % für 5 Min: Neuen Server starten
• Wenn CPU < 20 % für 10 Min: Server abschalten
• Neue Server werden automatisch zum Load Balancer hinzugefügt
• Alte Server werden graceful heruntergefährt (keine neuen Anfragen)

12. Fazit: Load Balancer für Zuverlässigkeit und Skalierung

Load Balancer sind nicht mehr nur für große Tech-Companies – sie sind Standard-Infrastruktur für jede Website mit ernsthaftem Traffic. Die Kombination aus erhöhter Verfügbarkeit, besserer Performance und einfacherer Skalierung macht sie unverzichtbar.

Wo anfangen?

• Kleine Websites: Ein einzelner Nginx-Server als Reverse Proxy reicht oft
• Mittlere Websites: Nginx LB + 2-3 Backend-Server, zentrale Session-Datenbank
• Große Websites: Managed Load Balancer (AWS ALB, DigitalOcean LB) mit Auto-Scaling
• Enterprise: Redundante Hardware-LB mit vollständigem HA-Setup

Mit Nginx kostenfrei, und nur wenigen Minuten Konfiguration, können auch kleine Websites bereits von Load Balancing profitieren. Moderne Cloud-Provider wie Hetzner und DigitalOcean machen es noch einfacher mit verwalteten Load Balancer Services.