Was ist Lastverteilung (Load Balancing)?

• Server und Infrastruktur
• Aktualisiert: 04.10.2026
• Ca. 11 Min. Lesezeit

Wie funktioniert Lastverteilung?

1. 1

   Anfragen werden auf mehrere Server verteilt

   Ein Load Balancer ist ein Reverse Proxy, der zwischen dem Besucher und den Backend-Servern steht. Er bringt drei wesentliche Vorteile:

   • Kapazität: Eine Last, die ein einzelner Server nicht bewältigt, wird auf mehrere aufgeteilt. Steigt der Bedarf, kommt ein weiterer Server zur Gruppe hinzu.
   • Ausfallsicherheit: Fällt einer der Server aus, gehen die Anfragen an die übrigen; die Website wird vielleicht langsamer, bleibt aber erreichbar.
   • Einfachere Wartung: Der Server, der aktualisiert werden soll, wird aus der Gruppe genommen und danach wieder aufgenommen. Die Besucher bemerken die Wartung nicht.

   Lastverteilung ist für sich genommen keine Geschwindigkeitseinstellung: Sie beschleunigt keine langsame Abfrage, sondern sorgt nur dafür, dass mehr Anfragen gleichzeitig bedient werden können.

   : Vergrößern

2. 2

   Verteilungsverfahren wählen

   Das Verteilungsverfahren bestimmt, welcher Server die nächste Anfrage erhält. Die drei in Nginx am häufigsten verwendeten Verfahren sind:

   Verfahren	Wie wird verteilt?	Wann ist es geeignet?
   round-robin (Standard)	Verteilt die Anfragen reihum, entsprechend den Gewichten.	Wenn die Server ähnlich leistungsfähig sind und die Anfragen ähnlich lange dauern.
   least_conn	Gibt die Anfrage an den Server mit den derzeit wenigsten aktiven Verbindungen.	Wenn die Dauer der Anfragen stark schwankt (lange Berichte, Datei-Downloads).
   ip_hash	Leitet Anfragen von derselben Client-Adresse an denselben Server.	Als Übergangslösung, wenn Sitzungen auf dem Server gespeichert werden.

   Wenn Sie unsicher sind, beginnen Sie mit dem Standardverfahren; für die meisten Websites genügt es.

   : Vergrößern

3. 3

   Ein Server, der nicht antwortet, wird herausgenommen

   Ein Load Balancer muss aufhören können, Anfragen an einen defekten Server zu schicken. Das nennt man Zustandsprüfung (Health Check). Im quelloffenen Nginx ist diese Prüfung passiv: Nginx fragt die Server nicht gesondert ab, sondern beobachtet das Ergebnis echter Besucheranfragen. Schlägt die Kommunikation mit einem Server innerhalb einer bestimmten Zeit eine bestimmte Anzahl von Malen fehl, wird dieser Server eine Zeit lang nicht verwendet; nach Ablauf der Zeit wird er erneut versucht.

   Eine aktive Zustandsprüfung, die die Server von sich aus in regelmäßigen Abständen abfragt, ist in der quelloffenen Version nicht eingebaut; es gibt sie in der kommerziellen Version, in Zusatzmodulen oder in anderer Load-Balancer-Software.

   : Vergrößern

4. 4

   Sitzungen einplanen

   Viele Anwendungen speichern Sitzungsdaten (Anmeldestatus, Warenkorb) auf der eigenen Festplatte des Servers. Bei einem Server ist das kein Problem; bei mehreren kann die erste Anfrage des Besuchers an Server A gehen und die zweite an Server B, der ihn nicht kennt. Die Folge: Der Benutzer wird scheinbar grundlos abgemeldet oder der Warenkorb ist leer. Dieses Problem ist als Sitzungsbindung (Session Stickiness) bekannt; die Lösungen werden weiter unten in einem eigenen Abschnitt beschrieben.

   : Vergrößern

Der upstream-Block in Nginx

In Nginx werden die Backend-Server mit einem upstream-Block als Gruppe definiert. Der Block steht innerhalb des http-Blocks und außerhalb der server-Blöcke. Die Gruppe erhält einen Namen, der in der Direktive proxy_pass verwendet wird:

# Innerhalb des http-Blocks: Gruppe der Backend-Server
upstream app_backend {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;
}

server {
    listen 80;
    server_name beispiel.de www.beispiel.de;

    location / {
        proxy_pass http://app_backend;
        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;
    }
}

Da in diesem Beispiel nichts weiter eingestellt ist, werden die Anfragen reihum auf die drei Server verteilt. Die proxy_set_header-Zeilen sorgen dafür, dass der Backend-Server den vom Besucher angefragten Domainnamen, die echte IP-Adresse und die Information erhält, ob die Verbindung über HTTPS lief; ohne sie hält die Anwendung alle Anfragen für Anfragen des Load Balancers. Zur Grundeinrichtung siehe die Anleitung zur Einrichtung eines Reverse Proxys.

Wenn Sie HTTPS verwenden, wird das Zertifikat in der Regel auf dem Load Balancer installiert (SSL-/TLS-Terminierung); Einzelheiten finden Sie in der Anleitung HTTPS in Nginx.

Prüfen Sie die Konfiguration nach jeder Änderung zuerst und laden Sie sie nur neu, wenn keine Fehler gemeldet werden:

# Konfiguration prüfen
sudo nginx -t
# Ohne Fehler: neu laden, ohne Verbindungen zu trennen
sudo systemctl reload nginx

Verfahren: round-robin, least_conn, ip_hash

Für round-robin wird keine Direktive geschrieben; es ist der Standard. Die anderen Verfahren werden mit einer einzigen Zeile am Anfang des upstream-Blocks eingetragen.

least_conn gibt die Anfrage an den Server mit den derzeit wenigsten aktiven Verbindungen; die Gewichte werden dabei ebenfalls berücksichtigt:

upstream app_backend {
    least_conn;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;
}

ip_hash wählt den Server anhand der IP-Adresse des Clients; Anfragen von derselben Adresse gehen stets an denselben Server, solange dieser verfügbar ist. Bei IPv4-Adressen werden die ersten drei Oktette herangezogen, bei IPv6 die gesamte Adresse.

upstream app_backend {
    ip_hash;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080 down;   # in Wartung: Zuordnungen bleiben erhalten
    server 10.0.0.13:8080;
}

Müssen Sie bei ip_hash einen Server vorübergehend herausnehmen, kennzeichnen Sie ihn mit down, statt die Zeile zu löschen; so bleibt die Serverzuordnung der übrigen Clients erhalten.

Die Parameter weight, backup und down

Am Ende jeder server-Zeile können Parameter stehen, die das Verhalten dieses Servers festlegen:

• weight: Das Gewicht des Servers; der Standardwert ist 1. Ein Server mit Gewicht 3 erhält ungefähr dreimal so viele Anfragen wie ein Server mit Gewicht 1. Damit geben Sie einem leistungsfähigeren Server einen größeren Anteil.
• backup: Ein Reserveserver. Er erhält nur dann Anfragen, wenn keiner der Hauptserver verfügbar ist. Er lässt sich nicht mit dem Verfahren ip_hash kombinieren.
• down: Kennzeichnet den Server als dauerhaft außer Betrieb. Das ist der einfachste Weg, einen Server während der Wartung aus der Gruppe zu nehmen.

upstream app_backend {
    server 10.0.0.11:8080 weight=3;   # leistungsfähigerer Server: mehr Anfragen
    server 10.0.0.12:8080;            # weight=1 (Standard)
    server 10.0.0.13:8080 down;       # in Wartung, erhält keine Anfragen
    server 10.0.0.14:8080 backup;     # nur wenn die anderen nicht verfügbar sind
}

Der Wartungsablauf sieht so aus: down an die Zeile des Servers anfügen, Konfiguration prüfen und neu laden, Wartung durchführen, das Wort down entfernen und erneut neu laden. Beim Neuladen (Reload) werden laufende Verbindungen nicht getrennt; die alten Worker-Prozesse schließen die Anfragen ab, die sie gerade bearbeiten, und beenden sich dann.

Zustandsprüfung: max_fails und fail_timeout

Die passive Zustandsprüfung wird mit zwei Parametern eingestellt:

• max_fails: Die Anzahl fehlgeschlagener Versuche, nach der der Server als nicht verfügbar gilt. Der Standardwert ist 1; mit 0 wird die Zählung abgeschaltet.
• fail_timeout: Sowohl der Zeitraum, in dem fehlgeschlagene Versuche gezählt werden, als auch die Dauer, für die der Server als nicht verfügbar gilt. Der Standardwert beträgt 10 Sekunden.

upstream app_backend {
    # 3 Fehlversuche in 30 Sekunden: Server wird 30 Sekunden nicht verwendet
    server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.13:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name beispiel.de;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # Nicht lange auf einen ausgefallenen Server warten
        proxy_connect_timeout 3s;
        # In welchen Fällen soll der nächste Server versucht werden?
        proxy_next_upstream error timeout http_502 http_503;
        proxy_next_upstream_tries 2;
    }
}

In diesem Beispiel gilt: Schlägt die Kommunikation mit einem Server innerhalb von 30 Sekunden dreimal fehl, werden 30 Sekunden lang keine Anfragen an diesen Server geschickt. Nach Ablauf der Zeit versucht Nginx den Server mit einer echten Anfrage erneut.

Was als „fehlgeschlagen“ gilt, legt die Direktive proxy_next_upstream fest. Standardmäßig zählen Verbindungsfehler und Zeitüberschreitung (Timeout) als Fehlschlag; im Beispiel kommen die Antworten 502 und 503 hinzu. Die fehlgeschlagene Anfrage wird an den nächsten Server weitergegeben; proxy_next_upstream_tries begrenzt die Anzahl dieser Versuche. Ein kurzer Wert für proxy_connect_timeout verhindert, dass ein ausgefallener Server den Besucher lange warten lässt.

Die Grenze der passiven Prüfung: Ein Ausfall fällt erst auf, wenn die Anfrage eines Besuchers scheitert. Überwachen Sie die Server deshalb zusätzlich von außen; die Empfehlungen zur Verfügbarkeitsüberwachung in der Anleitung Backup und Überwachung gelten auch hier. Zu den Ursachen der Fehler 502 und 504, die Besucher zu sehen bekommen, lesen Sie die Anleitung zu den Fehlern 502 und 504.

Sitzungsbindung und ihre Lösungen

Liegen die Sitzungsdaten auf der Festplatte oder im Arbeitsspeicher eines einzelnen Servers, muss jede Anfrage dieses Besuchers bei genau diesem Server ankommen. Es gibt drei Lösungswege:

• Weiterleitung an denselben Server mit ip_hash: Am schnellsten umgesetzt, aber begrenzt. Viele Benutzer aus demselben Netz (ein Unternehmen oder eine Behörde) häufen sich auf einem Server; ein mobiler Benutzer verliert die Sitzung, sobald sich seine IP-Adresse ändert; fällt ein Server aus, gehen die Sitzungen auf diesem Server verloren. Steht vor dem Load Balancer ein CDN oder ein anderer Proxy, sieht Nginx die Adresse dieser Schicht und nicht die des Besuchers, und die Verteilung gerät aus dem Gleichgewicht.
• Sitzungen in einem gemeinsamen Speicher: Die Sitzungen liegen nicht auf den Festplatten der Server, sondern an einem gemeinsamen Ort, auf den alle zugreifen (ein In-Memory-Speicher wie Redis oder Memcached oder die Datenbank). Gleich welcher Server antwortet, die Sitzung wird gefunden. Das ist meist die dauerhafte Lösung.
• Zustandsloses Identitäts-Token: Der Server speichert keine Sitzung; die Identität des Benutzers steckt in einem Token, das der Server signiert hat und das mit jeder Anfrage mitgeschickt wird. Da jeder Server die Signatur prüfen kann, wird die Anfrage angenommen, gleich wo sie ankommt. Der Signaturschlüssel muss auf allen Servern derselbe sein, und die Gültigkeitsdauer des Tokens sollte kurz gehalten werden.

Sichere Einstellungen für Sitzungs-Cookies finden Sie in der Anleitung Anmelde- und Sitzungssicherheit.

Worauf Sie achten müssen

• Hochgeladene Dateien müssen gemeinsam verfügbar sein: Wird ein von einem Benutzer hochgeladenes Bild nur auf die Festplatte des Servers geschrieben, der die Anfrage erhalten hat, finden die anderen Server diese Datei nicht. Legen Sie hochgeladene Dateien in einem gemeinsamen Speicher ab, auf den alle Server zugreifen, oder gleichen Sie sie zwischen den Servern ab.
• Die Datenbank bleibt ein einzelner Punkt: Mehr Anwendungsserver bedeuten nicht mehr Datenbanken. Alle Server verbinden sich mit derselben Datenbank; liegt die Langsamkeit oder der Fehler dort, hilft Lastverteilung nicht. Für die Datenbank brauchen Sie ein eigenes Backup- und Reservekonzept.
• Der Load Balancer selbst ist ein Single Point of Failure: Auch mit drei Servern dahinter ist die Website nicht erreichbar, wenn der eine Load Balancer davor ausfällt. Ist unterbrechungsfreier Betrieb wichtig, wird auch der Load Balancer redundant ausgelegt (ein zweiter Load Balancer und eine gemeinsame IP-Adresse, die bei einem Ausfall zu ihm wechselt), oder Sie nutzen den verwalteten Lastverteilungsdienst Ihres Hosting-Anbieters.
• Versionen müssen einheitlich ausgerollt werden: Laufen auf den Servern unterschiedliche Codeversionen, sieht derselbe Besucher bei einer Anfrage die neue und bei der nächsten die alte Seite. Aktualisieren Sie, indem Sie die Server nacheinander aus der Gruppe nehmen, und achten Sie darauf, dass Datenbankänderungen auch mit der alten Version funktionieren.
• Geplante Aufgaben: Eine geplante Aufgabe, die auf jedem Server getrennt läuft, erledigt dieselbe Arbeit mehrfach (verschickt zum Beispiel dieselbe E-Mail dreimal). Lassen Sie solche Aufgaben nur auf einem Server laufen oder verwenden Sie eine Sperre.
• Cache und Protokolle: Ein Cache, der pro Server geführt wird, kann von Server zu Server unterschiedliche Ergebnisse liefern. Auch die Protokolle liegen verstreut; bei der Fehlersuche müssen Sie alle durchsehen.

Wenn Sie nicht sicher sind, dass ein Server nicht mehr ausreicht, prüfen Sie zuerst, ob sich der vorhandene Server verbessern lässt: Caching und Komprimierung bringen oft mit weniger Aufwand mehr Gewinn.

Häufige Fragen

Verwandte Anleitungen

• Was ist ein Reverse Proxy?Aufgaben eines Reverse Proxys, typische Architekturen, echte Besucher-IP und Header, Verhältnis zum CDN und ein kurzes Nginx-Beispiel.
• Nginx als Reverse Proxy einrichtenSchritt für Schritt: server-Block, proxy_pass, weitergereichte Header, WebSocket, Timeouts und echte Client-IP.
• 502, 504 und andere Nginx-Fehler: Ursachen und LösungenBedeutung, mögliche Ursachen, Diagnose über die Logs und Lösung für 502, 504, 413, 499, 403 und 404.
• Was ist ein CDN (Content Delivery Network)?Was ein CDN ist, wie es in Betrieb geht und worauf bei echter IP, Cache und Sicherheit des Ursprungsservers zu achten ist.