Was ist ein Load Balancer? Einfach erklärt, mit eigenen Tests (2026)

Ein Load Balancer ist ein Programm oder Gerät, das eingehende Anfragen auf mehrere gleichartige Server verteilt. Der Besucher spricht nur mit dem Load Balancer. Der entscheidet bei jeder Anfrage, welcher Server im Hintergrund sie bekommt, und schickt die Antwort zurück. Das Ziel ist zweierlei: Kein einzelner Server soll überlastet werden, und wenn einer ausfällt, sollen die anderen einfach weitermachen.

Das ist die kurze Antwort auf die Frage, was ein Load Balancer ist. Die lange ist interessanter, weil die meisten Erklärungen an genau der Stelle aufhören, an der es in der Praxis wehtut. Ein Load Balancer verteilt nicht nur, er verteilt auch Fehler. Er kann einen eingefrorenen Server minutenlang weiter mit Besuchern füttern, Nutzer zufällig ausloggen oder eine einzelne E-Mail dreimal verschicken lassen. Das klingt übertrieben. Wir haben es am 2. November 2026 auf unserem eigenen Server nachgestellt, mit nginx 1.24 und HAProxy 3.2.26 vor drei kleinen Test-Backends, und jede dieser Situationen ließ sich mit der Standardkonfiguration auslösen.

Dieser Artikel erklärt erst die Grundlagen, also wie ein Load Balancer arbeitet, welche Algorithmen es gibt und was Layer 4 und Layer 7 bedeuten. Danach kommen die Messungen. Am Ende steht die ehrliche Antwort auf die Frage, ob du überhaupt einen brauchst. Für sehr viele Projekte lautet sie: noch nicht.

Wenn du noch nicht weißt, was ein Reverse Proxy ist, lohnt sich vorher ein Blick in Was ist ein Reverse Proxy. Ein HTTP-Load-Balancer ist technisch nämlich nichts anderes als ein Reverse Proxy mit einer bestimmten Aufgabe.

Englisch, animiert, gut zehn Minuten: PowerCert erklärt im Video vom März 2026 die Grundidee mit Bildern. Wer lieber liest, findet alles Wichtige auch unten.

Was ist ein Load Balancer? Die Definition ohne Fachchinesisch

Stell dir eine Bäckerei mit drei Kassen vor. Ohne Einweiser stellen sich alle an die erste Kasse, weil sie am nächsten an der Tür liegt. Die zweite und dritte Kassiererin langweilen sich. Ein Einweiser an der Tür ändert das: Er schickt jeden neuen Kunden zu einer Kasse, und zwar so, dass keine Schlange zu lang wird. Fällt eine Kasse aus, schickt er dort einfach niemanden mehr hin.

Genau das macht ein Load Balancer, auf Deutsch auch Lastverteiler genannt. Die Kassen sind deine Server, im Fachjargon Backends, Upstreams oder Targets. Der Einweiser ist der Load Balancer. Und die Kunden sind Anfragen: ein Seitenaufruf, ein API-Call, eine Datenbankverbindung.

Drei Eigenschaften machen einen Load Balancer aus:

Ein Eingang, mehrere Ausgänge. Nach außen gibt es nur eine Adresse, zum Beispiel shop.example.de. Wie viele Server dahinter stehen, sieht der Besucher nicht. Du kannst morgen von zwei auf fünf Server gehen, ohne dass sich an der Adresse etwas ändert.

Die Backends sind austauschbar. Das ist der Unterschied zum gewöhnlichen Reverse Proxy. Ein Reverse Proxy schickt /api an die API und /blog an das Blog, also an verschiedene Programme. Ein Load Balancer schickt jede Anfrage an eine von mehreren gleichen Kopien desselben Programms. Welche Kopie es wird, ist für das Ergebnis egal, wenigstens in der Theorie.

Er beobachtet die Backends. Ein Load Balancer, der nicht merkt, wenn ein Server ausfällt, ist nur ein Würfel. Die eigentliche Arbeit steckt in den Health-Checks, also in der Frage, welcher Server gerade überhaupt Anfragen bekommen darf.

Wie funktioniert ein Load Balancer konkret?

Der Ablauf einer einzelnen Anfrage sieht so aus:

1. Der Browser löst shop.example.de per DNS auf und bekommt die IP-Adresse des Load Balancers, nicht die eines Servers.
2. Er baut eine Verbindung zum Load Balancer auf und schickt seine Anfrage.
3. Der Load Balancer wählt nach seinem Algorithmus ein Backend aus, das gerade als gesund gilt.
4. Er öffnet eine eigene Verbindung zu diesem Backend (oder nutzt eine offene) und reicht die Anfrage weiter.
5. Die Antwort fließt denselben Weg zurück.

Wichtig ist Schritt 4: Das Backend sieht als Absender den Load Balancer, nicht den Besucher. Deshalb hängen Load Balancer die echte Adresse in einen Header wie X-Forwarded-For oder nutzen das PROXY-Protokoll. Vergisst man das, steht in allen Logs dieselbe interne IP, und Werkzeuge wie Fail2ban sperren im schlimmsten Fall den eigenen Load Balancer aus.

Layer 4 und Layer 7: zwei Arten zu verteilen

Load Balancer arbeiten auf einer von zwei Ebenen, benannt nach dem OSI-Schichtenmodell.

Ein Layer-4-Load-Balancer sieht nur TCP- oder UDP-Verbindungen: Quell-IP, Ziel-IP, Ports. Was in der Verbindung steht, interessiert ihn nicht. Er kann deshalb alles verteilen, was über TCP läuft, also auch Datenbanken, Mailserver oder Spieleserver, und er ist sehr schnell. Dafür kann er keine Entscheidungen nach URL, Cookie oder Header treffen, und eine Verbindung bleibt ihr ganzes Leben lang beim selben Backend.

Ein Layer-7-Load-Balancer versteht HTTP. Er liest jede Anfrage, kann nach Pfad oder Host verteilen, Cookies setzen, Header ergänzen, Antworten auswerten und eine fehlgeschlagene Anfrage auf einem anderen Server wiederholen. Dafür muss er die Verschlüsselung aufbrechen, also die HTTPS-Verbindung selbst beenden. Das nennt man TLS-Terminierung.

Für Websites und APIs ist Layer 7 der Normalfall. Layer 4 nimmst du, wenn kein HTTP im Spiel ist oder wenn die Verschlüsselung bis zum Backend durchgehen soll.

Die wichtigsten Load-Balancing-Algorithmen

Wie entscheidet der Load Balancer, welcher Server die nächste Anfrage bekommt? Es gibt Dutzende Verfahren, in der Praxis begegnen dir vor allem diese:

Round Robin. Der Reihe nach: Server 1, 2, 3, 1, 2, 3. Einfach, fair bei gleichartigen Anfragen und der Standard in nginx und HAProxy. Bei uns bekamen die drei Backends bei 30 Anfragen 11, 10 und 9 Stück. Das Problem: Round Robin zählt Anfragen, nicht Arbeit. Ist ein Server langsamer, bekommt er trotzdem genauso viel.

Weighted Round Robin. Wie Round Robin, aber mit Gewichten. Ein Server mit doppelt so viel CPU bekommt weight=2 und damit doppelt so viele Anfragen. Sinnvoll bei unterschiedlich großen Maschinen.

Least Connections. Die nächste Anfrage geht an den Server mit den wenigsten offenen Verbindungen. Ein langsamer Server hält seine Verbindungen länger offen und bekommt deshalb automatisch weniger. Für Anwendungen mit sehr unterschiedlich langen Anfragen ist das fast immer die bessere Wahl. Unsere Messung weiter unten zeigt, wie groß der Unterschied sein kann.

IP-Hash. Aus der IP-Adresse des Besuchers wird ein Wert berechnet, der immer auf denselben Server zeigt. So landet derselbe Besucher immer beim selben Backend, ohne Cookie. Der Haken: Viele Besucher teilen sich eine IP, etwa in Firmennetzen, im Mobilfunk (Carrier-Grade NAT) oder hinter einem vorgeschalteten CDN. Die landen dann alle auf einem Server.

Consistent Hashing. Eine Verfeinerung, die nach einem Schlüssel verteilt (URL, Nutzer-ID) und beim Hinzufügen oder Entfernen eines Servers nur einen kleinen Teil der Zuordnungen verschiebt. Wichtig für Caches, bei denen jeder Server einen Teil der Daten vorhält.

Random mit zwei Auswahlmöglichkeiten. Der Load Balancer würfelt zwei Server und nimmt den weniger belasteten. Klingt banal, verteilt aber erstaunlich gut und braucht keinen gemeinsamen Zustand. Deshalb nutzen es große Systeme mit mehreren Load-Balancer-Instanzen gern.

Bei Cloud-Anbietern ist die Auswahl oft kleiner. Der Load Balancer von Hetzner Cloud bietet zum Beispiel laut Produktseite genau zwei Verfahren an, Round Robin und Least Connections. Für die meisten Websites reicht das völlig.

Health-Checks: woher der Load Balancer weiß, wer noch lebt

Ein Load Balancer erfährt auf zwei Wegen, dass ein Server Probleme hat.

Passive Checks schauen auf echte Anfragen. Schlägt eine Verbindung fehl oder läuft sie in einen Timeout, markiert der Load Balancer den Server für eine Weile als kaputt. Das kostet keinen zusätzlichen Verkehr. Aber jemand muss den Fehler zuerst erleben, nämlich ein echter Besucher. Open-Source-nginx kann nur passiv prüfen. Aktive Checks gibt es dort nur in der kommerziellen Version NGINX Plus.

Aktive Checks fragen jeden Server regelmäßig selbst ab, zum Beispiel alle zwei Sekunden GET /health. Erst nach mehreren Fehlschlägen hintereinander gilt der Server als tot, erst nach mehreren Erfolgen wieder als gesund. HAProxy, Traefik, Envoy und alle Cloud-Load-Balancer können das.

Ein guter Health-Check-Endpunkt prüft, ob die Anwendung wirklich arbeiten kann, also etwa ob sie die Datenbank erreicht. Er darf aber nicht so viel tun, dass er selbst zur Last wird. Und er sollte nicht von Dingen abhängen, die alle Server gemeinsam haben: Wenn /health bei einem kurzen Datenbank-Hänger auf allen Servern rot wird, nimmt der Load Balancer alle aus dem Verkehr und macht aus einem Schluckauf einen Komplettausfall.

Unsere Messungen: was in der Praxis passiert

Genug Theorie. Wir haben am 2. November 2026 auf unserem Ubuntu-Server drei winzige Python-Backends gestartet (app1 bis app3, jedes antwortet mit seinem Namen) und davor zuerst nginx 1.24.0 und danach HAProxy 3.2.26 gesetzt. Beide mit Konfigurationen, wie sie in jedem Einsteiger-Tutorial stehen. Gemessen wurde mit curl und wrk. Alles lief in Wegwerf-Prozessen und einem Wegwerf-Container und ist danach wieder gelöscht.

Test 1: Ein Server stürzt ab (die gute Nachricht)

Wir haben app2 hart beendet. Der Port war damit zu, jede Verbindung wurde sofort abgewiesen („Connection refused“).

nginx hat das vorbildlich weggesteckt: 30 von 30 Anfragen kamen mit 200 zurück, die langsamste brauchte 1,4 Millisekunden. Im Fehlerlog standen zwei Einträge connect() failed (111: Connection refused). nginx hat den toten Server probiert, sofort die Absage bekommen und die Anfrage an den nächsten gegeben. Danach hat er ihn für zehn Sekunden gemieden (Standard: max_fails=1, fail_timeout=10s).

Auch 30 POST-Anfragen gingen alle durch und wurden jeweils genau einmal ausgeführt. Das ist korrekt so, denn eine abgewiesene Verbindung hat das Backend nie erreicht. Wiederholen ist hier ungefährlich.

So stellt man sich Load Balancing vor. Leider ist ein sauber abgestürzter Server der freundlichste Fehler, den es gibt.

Test 2: Ein Server hängt (die schlechte Nachricht)

Echte Server sterben selten sauber. Sie hängen: Speicher voll, Festplatte voll, Deadlock in der Anwendung, Garbage Collector läuft Amok. Der Port bleibt offen, das Betriebssystem nimmt sogar noch Verbindungen an, aber es kommt keine Antwort mehr.

Das haben wir mit kill -STOP nachgestellt. Der Prozess app2 war eingefroren, aber nicht tot.

nginx schickte nach dem Neuladen von vier Anfragen eine an den hängenden Server. Die wartete 60,0 Sekunden und bekam dann trotzdem eine Antwort, weil nginx nach Ablauf des Standard-Timeouts proxy_connect_timeout 60s auf einen anderen Server auswich. Ein echter Besucher hätte eine Minute auf eine weiße Seite gestarrt und längst aufgegeben. Danach mied nginx den Server zehn Sekunden lang und probierte ihn dann wieder, mit dem nächsten unglücklichen Besucher als Versuchskaninchen.

HAProxy mit aktiven Health-Checks (alle 2 Sekunden, nach 3 Fehlschlägen als tot markiert) machte es besser, aber nicht perfekt. Wir schickten alle halbe Sekunde eine Anfrage, insgesamt 24:

• 17 Anfragen gingen an die gesunden Server und waren in rund einer Millisekunde fertig.
• 4 Anfragen landeten beim eingefrorenen Server, bevor er als tot galt. Sie warteten bis zum timeout server 30s und bekamen dann 504 Gateway Timeout, nach 30 Sekunden.
• 3 weitere bekamen nach 12 Sekunden 503, weil inzwischen nicht mal mehr der Verbindungsaufbau klappte (vier Verbindungsversuche à 3 Sekunden: der erste plus die drei Wiederholungen, die HAProxy standardmäßig macht).
• Etwa zehn Sekunden nach dem Einfrieren meldete HAProxy Server be/app2 is DOWN, reason: Layer4 timeout. Ab da liefen alle Anfragen glatt.

7 von 24 Anfragen sind also gescheitert, und zwar erst nach 12 bis 30 Sekunden. Ab dem Moment, in dem der Server als DOWN galt, verteilte HAProxy brav 6:6 auf die beiden gesunden Server. Als wir app2 wieder auftauten, war er nach zwei erfolgreichen Checks automatisch zurück im Spiel.

Die Lehre daraus: Health-Checks verkürzen das Problem, sie verhindern es nicht. Bis ein Server als krank erkannt ist, vergehen Sekunden, und in diesen Sekunden bezahlen echte Besucher. Die beiden Stellschrauben dafür sind kürzere Timeouts (60 oder 30 Sekunden sind für eine Webseite viel zu lang, 5 bis 10 sind realistischer) und kürzere Prüfintervalle. Beides hat seinen Preis: Zu knappe Timeouts werfen gesunde, aber gerade beschäftigte Server raus.

Test 3: Die E-Mail, die dreimal rausging

Jetzt der unangenehmste Fund. Viele Anleitungen empfehlen, den Lese-Timeout knapp einzustellen, damit langsame Server schnell übersprungen werden. Wir haben drei Backends gebaut, die für jede Anfrage drei Sekunden brauchen und jeden Aufruf in eine Datei schreiben, und davor nginx mit proxy_read_timeout 1s gesetzt. Dann ein einziger Aufruf: GET /mail/send.

Das Ergebnis im Protokoll der Backends:

slow1 GET /mail/send
slow2 GET /mail/send
slow3 GET /mail/send

Eine Anfrage, drei Ausführungen. nginx wartete eine Sekunde auf Server 1, gab auf, schickte dieselbe Anfrage an Server 2, gab wieder auf, dann Server 3. Der Besucher bekam nach drei Sekunden einen 504-Fehler, also die Meldung, dass es nicht geklappt hat. In Wahrheit hat es dreimal geklappt. Wäre das ein echter Mailversand gewesen, hätte der Empfänger drei Mails bekommen. Und wer bei einem Fehler nochmal klickt, löst die nächsten drei aus.

nginx wiederholt seit Version 1.9.13 keine POST-Anfragen mehr bei Timeouts, weil die als „nicht idempotent“ gelten, also nicht gefahrlos wiederholbar. Unser POST lief tatsächlich genau einmal. Aber nginx glaubt der HTTP-Methode. Wer Aktionen mit Nebenwirkungen hinter ein GET legt, und das tun erstaunlich viele Anwendungen (Abmelde-Links, Admin-Knöpfe, Webhooks), bekommt sie mehrfach ausgeführt.

Und es gab einen Nebeneffekt: Weil jeder Timeout als Fehlschlag zählte, galten danach alle drei Server für zehn Sekunden als tot. Die nächste Anfrage, ein harmloser POST, bekam in 0,4 Millisekunden 502 „no live upstreams“, obwohl alle drei Server liefen. Eine einzige langsame Anfrage hatte das komplette Backend für zehn Sekunden stillgelegt.

Die Gegenmittel: Aktionen mit Nebenwirkungen nie hinter GET legen, Wiederholungen bei Timeouts gezielt abschalten (proxy_next_upstream error; statt des Standards error timeout) oder die Anwendung idempotent bauen, also mit einer Anfrage-ID, die doppelte Ausführung erkennt.

Test 4: Der Nutzer, der sich ständig abmeldet

Viele Anwendungen speichern Logins im Arbeitsspeicher des Servers. Mit einem Server ist das kein Problem. Mit drei Servern und Round Robin schon. Wir haben uns über den Load Balancer angemeldet und danach sechsmal die Seite „Mein Konto“ aufgerufen:

app3 no-session 401
app1 no-session 401
app2 user 200
app3 no-session 401
app1 no-session 401
app3 no-session 401

Einmal angemeldet, fünfmal abgemeldet. Die Sitzung existierte nur auf app2, alle anderen Server kannten den Nutzer nicht. Für den Besucher sieht das aus wie eine kaputte Website, die ihn zufällig rauswirft. Genau dieser Fehler ist der häufigste Grund, warum der erste Versuch mit einem Load Balancer schiefgeht.

Es gibt zwei Lösungen. Die saubere: Sitzungen gehören nicht in den Arbeitsspeicher eines einzelnen Servers, sondern in einen gemeinsamen Speicher wie Redis oder die Datenbank, oder die Anwendung nutzt signierte Tokens, die jeder Server selbst prüfen kann. Dann ist es egal, welcher Server antwortet. Die schnelle: Sticky Sessions.

Sticky Sessions: Bequem, aber mit Haken

Sticky Sessions (auch Session Affinity) sorgen dafür, dass ein Besucher immer beim selben Server landet. Es gibt zwei Wege dahin.

Per IP-Hash. In nginx eine Zeile: ip_hash;. Wir haben es probiert, mit einer kleinen Überraschung: 30 von 30 Anfragen landeten auf app3. Logisch, denn alle Testanfragen kamen von derselben Adresse 127.0.0.1. Genau das passiert in der echten Welt, wenn der Load Balancer hinter einem CDN wie Cloudflare steht oder viele Besucher aus demselben Firmennetz kommen: Der Load Balancer sieht nur wenige Adressen und verteilt entsprechend schief. Im Extremfall arbeitet ein Server, die anderen schlafen.

Per Cookie. Der Load Balancer setzt beim ersten Besuch ein Cookie, in dem steht, welcher Server zuständig ist. HAProxy macht das mit cookie SRV insert. In unserem Test bekam der Browser das Cookie SRV=a1, und alle fünf folgenden Anfragen gingen an app1. Das funktioniert unabhängig von der IP und ist deshalb meist die bessere Variante.

Beide Varianten haben denselben grundsätzlichen Haken: Fällt „dein“ Server aus, ist deine Sitzung weg. Die Last verteilt sich ungleichmäßig, weil manche Besucher viel und andere wenig tun. Und wenn du einen Server für ein Update herausnimmst, verlieren alle seine Besucher ihre Sitzung. Sticky Sessions sind eine Krücke, um eine Anwendung lastverteilbar zu machen, die eigentlich nicht dafür gebaut ist. Als Übergang völlig in Ordnung, als Dauerlösung nicht.

Least Connections gegen Round Robin: Faktor 33

Zum Abschluss die Messung, die uns selbst am meisten überrascht hat. Wir haben app3 künstlich verlangsamt, jede Antwort brauchte 0,3 Sekunden statt einer Millisekunde. Das entspricht einem Server, der gerade ein Backup schreibt oder auf einer schwächeren Maschine läuft. Dann haben wir mit wrk 15 Sekunden lang 20 gleichzeitige Verbindungen auf den Load Balancer gegeben, einmal mit Round Robin, einmal mit Least Connections.

Least Connections schaffte rund 33-mal so viele Anfragen. Der Grund: Round Robin schickt jede dritte Anfrage stur an den langsamen Server, egal wie viele dort schon warten. Die Verbindungen stauen sich dort, und weil wrk immer erst die nächste Anfrage schickt, wenn die vorige fertig ist, bremst der langsame Server das ganze System auf sein Tempo herunter. Least Connections merkt, dass dort viele Verbindungen offen sind, und schickt fast alles an die beiden schnellen Server.

Fair muss man sagen: Das 99. Perzentil war bei Least Connections schlechter. Die wenigen Anfragen, die trotzdem beim langsamen Server landeten, mussten sich dort länger anstellen. Und unser Test ist ein Extremfall mit einem 300-fach langsameren Server. In echten Systemen ist der Unterschied kleiner, die Richtung bleibt aber dieselbe: Wenn deine Server nicht exakt gleich schnell sind, nimm Least Connections.

Load Balancer vs. Reverse Proxy vs. CDN vs. DNS

Diese Begriffe werden ständig durcheinandergeworfen, weil sie sich überschneiden.

Reverse Proxy und Load Balancer sind auf Layer 7 dieselbe Software mit unterschiedlicher Aufgabe. nginx, Caddy und HAProxy können beides gleichzeitig. Der Unterschied liegt in den Backends: verschiedene Programme beim Reverse Proxy, gleiche Kopien beim Load Balancer. Die ausführliche Abgrenzung steht in unserem Reverse-Proxy-Artikel, die konkrete nginx-Konfiguration im Guide nginx als Reverse Proxy.

Ein CDN ist ein weltweit verteiltes Netz aus Caching-Servern. Es enthält intern jede Menge Load Balancer, ersetzt aber deinen eigenen nicht, sobald dynamische Inhalte im Spiel sind. Ein CDN entlastet deine Server, indem es Antworten zwischenspeichert. Ein Load Balancer verteilt das, was trotzdem bei dir ankommt.

DNS-Load-Balancing bedeutet, dass ein Domainname auf mehrere IP-Adressen zeigt. Die Clients nehmen sich eine davon. Das ist die einfachste Form der Verteilung und braucht keine zusätzliche Software. Der Nachteil: DNS weiß nicht, ob ein Server lebt. Fällt einer aus, schicken die Clients so lange weiter Anfragen dorthin, bis ihr DNS-Cache abläuft, und viele Clients probieren bei einem Fehler nicht automatisch die nächste Adresse. Als Grobverteilung zwischen Rechenzentren ist DNS gut, als einziger Ausfallschutz nicht.

Hardware, Software oder Cloud: welche Arten von Load Balancern gibt es?

Hardware-Load-Balancer sind spezialisierte Geräte von Herstellern wie F5 oder Citrix. Sie stehen in großen Rechenzentren, kosten fünf- bis sechsstellige Beträge und sind heute für kleine und mittlere Projekte praktisch bedeutungslos.

Software-Load-Balancer laufen auf ganz normalen Servern. Die bekanntesten:

• HAProxy, der Spezialist. Aktive Health-Checks, sehr detaillierte Statistiken, Cookie-basierte Sticky Sessions, Layer 4 und 7. Wenn Lastverteilung die Hauptaufgabe ist, die genaueste Wahl.
• nginx, der Allrounder. Webserver, Reverse Proxy und Load Balancer in einem. In der freien Version nur passive Health-Checks. Mehr dazu im Vergleich Apache vs. nginx.
• Caddy, der Bequeme. Automatisches HTTPS, aktive und passive Health-Checks, sehr kurze Konfiguration. Unser Vergleich: Caddy vs. nginx.
• Traefik, der Container-Freund. Findet Docker-Container und Kubernetes-Dienste automatisch und verteilt auf sie.
• Envoy, der Große. Grundlage vieler Service-Meshes, sehr mächtig, aber auch sehr komplex.

Cloud-Load-Balancer werden vom Anbieter betrieben: AWS Application/Network Load Balancer, Google Cloud Load Balancing, Azure Load Balancer und auch kleinere Anbieter wie Hetzner. Du klickst sie dir zusammen, der Anbieter kümmert sich um Ausfallsicherheit und Updates. Abgerechnet wird nach Laufzeit und oft zusätzlich nach Verkehr. Für den Einstieg ist das oft die entspannteste Lösung, weil du dich nicht selbst um das nächste Problem kümmern musst.

Deutsch, praktisch gezeigt: Raspberry Pi Cloud richtet einen Hetzner-Cloud-Load-Balancer Schritt für Schritt ein. Das Video ist vom Mai 2023, die Oberfläche hat sich seitdem leicht verändert, das Prinzip nicht. In der Videobeschreibung stehen Affiliate-Links.

Das nächste Problem: der Load Balancer selbst

Jetzt hast du drei Server, damit keiner allein ausfallen kann. Und davor genau einen Load Balancer. Fällt der aus, ist alles weg. Du hast den Single Point of Failure nicht beseitigt, sondern nur verschoben.

Die klassische Lösung sind zwei Load Balancer, die sich eine virtuelle IP-Adresse teilen. Einer ist aktiv, der andere wartet. Ein Programm wie keepalived (über das Protokoll VRRP) überwacht den aktiven und zieht die IP auf den zweiten, wenn der erste ausfällt. Bei Cloud-Anbietern übernimmt das eine Floating IP, die per API umgehängt wird, oder der Anbieter macht es intern. Das ist der eigentliche Grund, warum Cloud-Load-Balancer so beliebt sind: Ihre eigene Ausfallsicherheit ist im Preis enthalten.

Und dahinter wartet das übernächste Problem: die Datenbank. Drei Anwendungsserver, die alle auf eine einzige Datenbank zugreifen, sind nur so ausfallsicher wie diese Datenbank. Deine Backups schützen vor Datenverlust, nicht vor Ausfallzeit. Echte Hochverfügbarkeit bedeutet, jede Schicht doppelt zu haben, und mit jeder Schicht wächst der Aufwand. Deshalb lohnt sich die Frage, ob du das wirklich brauchst.

Brauchst du überhaupt einen Load Balancer?

Ehrliche Antwort: Die meisten kleinen und mittleren Websites brauchen keinen. Ein einzelner ordentlich eingerichteter Server, egal ob VPS oder dedizierter Server, schafft mit Caching locker tausende Besucher gleichzeitig. Ein Load Balancer verdoppelt mindestens die Zahl der Maschinen, die du pflegen musst, und bringt die Fehler aus unseren Tests mit, die es mit einem Server gar nicht gibt.

Einen Load Balancer brauchst du, wenn mindestens eines davon zutrifft:

• Ein Server reicht nachweislich nicht mehr. Nicht gefühlt, gemessen: CPU dauerhaft am Anschlag, obwohl Caching und Datenbank-Indizes schon optimiert sind. Vorher lohnt sich der Blick in Wie viel RAM braucht ein Server und ein einfaches Upgrade.
• Ausfallzeit kostet richtig Geld. Wenn eine Stunde Ausfall mehr kostet als ein zweiter Server im ganzen Jahr, rechnet sich Redundanz.
• Du willst Updates ohne Ausfall einspielen. Mit zwei Servern hinter einem Load Balancer nimmst du einen raus, aktualisierst ihn, nimmst ihn wieder rein und machst mit dem nächsten weiter. Das nennt man Rolling Update.
• Du betreibst Container oder Kubernetes. Dort ist ein Load Balancer eingebaut, du kommst gar nicht drum herum.

Einen Load Balancer brauchst du nicht, wenn deine Website langsam ist, weil die Anwendung langsam ist. Dann verteilst du die Langsamkeit nur auf mehrere Server. Und auch nicht, wenn deine Anwendung Daten lokal speichert, also Uploads auf der Festplatte, Sitzungen im Speicher oder eine SQLite-Datei. Die muss erst lastverteilbar gemacht werden.

So richtest du einen ersten Load Balancer ein

Wenn du es ausprobieren willst, reicht nginx auf einem eigenen Server. Die minimale Konfiguration:

upstream app {
    least_conn;
    server 10.0.0.11:3000 max_fails=3 fail_timeout=15s;
    server 10.0.0.12:3000 max_fails=3 fail_timeout=15s;
    keepalive 32;
}

server {
    listen 443 ssl;
    server_name shop.example.de;
    # ssl_certificate ... (oder Caddy nehmen, das macht HTTPS automatisch)

    location / {
        proxy_pass http://app;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 3s;
        proxy_read_timeout 15s;
        proxy_next_upstream error;   # bei Timeouts NICHT auf dem nächsten Server wiederholen
    }
}

Die Zeilen, die in vielen Tutorials fehlen, sind die mit den Timeouts und proxy_next_upstream. Sie sind die direkte Konsequenz aus unseren Tests 2 und 3: Ein hängender Server kostet einen Besucher dann höchstens drei Sekunden statt einer Minute, und eine langsame Anfrage wird nicht auf allen Servern nacheinander ausgeführt. Wenn du Wiederholungen bei Timeouts trotzdem willst, weil deine Anwendung sauber idempotent ist, kannst du timeout wieder dazunehmen. Aber dann bewusst.

Die Backends sollten nur über ein privates Netzwerk erreichbar sein und per Firewall nur Verbindungen vom Load Balancer annehmen. Sonst kann jeder den Load Balancer umgehen und direkt auf einen Server zugreifen.

Wer aktive Health-Checks will, nimmt HAProxy oder Caddy. In HAProxy sind es drei Zeilen:

backend app
    balance leastconn
    option httpchk GET /health
    default-server inter 2s fall 3 rise 2
    server app1 10.0.0.11:3000 check
    server app2 10.0.0.12:3000 check

Und dann der wichtigste Schritt, den fast alle überspringen: den Ausfall testen. Einen Server hart beenden, einen mit kill -STOP einfrieren, einen künstlich verlangsamen. Erst dann weißt du, was deine Konfiguration wirklich tut. Das hat bei uns keine zehn Minuten gedauert und vier Probleme gezeigt, die in keiner Standardkonfiguration abgefangen werden.

Häufig gestellte Fragen

Was ist ein Load Balancer einfach erklärt?

Ein Load Balancer ist ein Verteiler, der vor mehreren gleichen Servern steht. Alle Besucher schicken ihre Anfragen an ihn, und er entscheidet bei jeder Anfrage, welcher Server sie bearbeitet. So wird kein Server überlastet, und fällt einer aus, übernehmen die anderen.

Was macht ein Load Balancer genau?

Er nimmt Verbindungen oder Anfragen entgegen, wählt nach einem Algorithmus wie Round Robin oder Least Connections ein gesundes Backend aus, leitet die Anfrage weiter und gibt die Antwort zurück. Nebenbei prüft er laufend, welche Server noch funktionieren, und beendet oft auch die HTTPS-Verschlüsselung.

Was ist der Unterschied zwischen Load Balancer und Reverse Proxy?

Ein Reverse Proxy leitet Anfragen an verschiedene Anwendungen weiter, je nach Domain oder Pfad. Ein Load Balancer verteilt Anfragen auf mehrere gleiche Kopien derselben Anwendung. Auf HTTP-Ebene ist jeder Load Balancer technisch ein Reverse Proxy, und Programme wie nginx oder HAProxy erledigen beides gleichzeitig.

Was ist der Unterschied zwischen Layer 4 und Layer 7 Load Balancing?

Layer 4 verteilt TCP- oder UDP-Verbindungen und sieht nur IP-Adressen und Ports. Das ist schnell und funktioniert mit jedem Protokoll. Layer 7 versteht HTTP, kann nach URL, Header oder Cookie entscheiden und fehlgeschlagene Anfragen wiederholen, muss dafür aber die Verschlüsselung beenden.

Welcher Load-Balancing-Algorithmus ist der beste?

Für gleich starke Server mit ähnlich langen Anfragen reicht Round Robin. Sobald Server unterschiedlich schnell sind oder Anfragen unterschiedlich lange dauern, ist Least Connections fast immer besser. In unserem Test mit einem langsamen Server schaffte Least Connections rund 33-mal so viele Anfragen wie Round Robin.

Was sind Sticky Sessions?

Sticky Sessions sorgen dafür, dass ein Besucher immer beim selben Server landet, entweder per IP-Hash oder per Cookie. Sie sind nötig, wenn die Anwendung Sitzungen nur lokal speichert. Der Nachteil: Fällt der Server aus, ist die Sitzung weg, und die Last verteilt sich ungleichmäßiger. Besser ist ein gemeinsamer Sitzungsspeicher.

Ist ein Load Balancer nicht selbst ein Single Point of Failure?

Ja, wenn es nur einen gibt. Deshalb betreibt man zwei Load Balancer mit einer gemeinsamen virtuellen IP, die per keepalived oder Floating IP auf den zweiten wandert, wenn der erste ausfällt. Cloud-Load-Balancer bringen diese Redundanz bereits mit.

Was ist DNS Load Balancing?

Beim DNS-Load-Balancing zeigt ein Domainname auf mehrere IP-Adressen, und die Clients wählen eine davon. Das ist einfach und kostenlos, aber DNS weiß nicht, ob ein Server ausgefallen ist. Clients schicken daher noch Anfragen an tote Server, bis ihr DNS-Cache abläuft.

Was kostet ein Load Balancer?

Eine selbst betriebene Lösung mit nginx, HAProxy oder Caddy kostet nur den Server, auf dem sie läuft, plus deine Zeit. Cloud-Load-Balancer werden nach Laufzeit abgerechnet, oft zusätzlich nach Datenverkehr oder Verbindungen. Bei kleinen Anbietern liegt das im niedrigen einstelligen Euro-Bereich pro Monat, bei den großen Clouds kann es durch die Verkehrsabrechnung deutlich mehr werden. Hardware-Load-Balancer kosten fünfstellige Beträge.

Brauche ich einen Load Balancer für meine Website?

Meistens nicht. Ein einzelner gut eingerichteter Server mit Caching reicht für die allermeisten Websites. Ein Load Balancer lohnt sich, wenn ein Server nachweislich nicht mehr reicht, Ausfallzeit viel Geld kostet oder du Updates ohne Unterbrechung einspielen willst.

Kann ein Load Balancer Anfragen doppelt ausführen?

Ja. Wenn ein Load Balancer bei einem Timeout eine Anfrage auf dem nächsten Server wiederholt, hat der erste Server sie vielleicht trotzdem bearbeitet. In unserem Test wurde ein einziger GET-Aufruf so auf drei Servern ausgeführt. nginx wiederholt POST-Anfragen seit Version 1.9.13 nicht mehr, GET aber schon. Aktionen mit Nebenwirkungen gehören deshalb nie hinter GET.

Fazit: Verteilen ist leicht, Ausfälle sind schwer

Was ist ein Load Balancer? Ein Verteiler vor mehreren gleichen Servern, der Last aufteilt und Ausfälle abfängt. Das Verteilen selbst ist trivial, das zeigen 30 Anfragen, die sich 11:10:9 auf drei Server aufteilen. Schwierig wird es bei den Ausfällen, und zwar nicht beim sauberen Absturz, den nginx in einer Millisekunde wegsteckt, sondern beim hängenden Server, der einen Besucher eine Minute warten lässt, bei der Wiederholung, die eine Aktion dreimal auslöst, und bei der Sitzung, die nur auf einem von drei Servern existiert.

Wenn du einen Load Balancer einsetzt, dann mit kurzen Timeouts, aktiven Health-Checks, Least Connections bei ungleichen Servern, einem gemeinsamen Sitzungsspeicher und ohne automatische Wiederholung bei Timeouts. Und probier den Ausfall aus, bevor er von selbst passiert. Wenn du keinen brauchst, freu dich: Ein Server weniger, um den du dich kümmern musst, ist auch eine Form von Hochverfügbarkeit.