Technik & Betrieb

Load Balancing

Load Balancing verteilt eingehende Anfragen auf mehrere Server, damit keiner überlastet wird. Fällt einer aus, übernehmen die anderen — die Website bleibt erreichbar.

Redaktionell geprüft von Alexander SeidlertwentyonepixelsStand:

Zwei Gründe, einer davon der wichtigere

Der offensichtliche ist Leistung: mehr Anfragen als ein Server verkraftet. Der praktisch häufigere ist Verfügbarkeit — mit zwei Servern lässt sich einer aktualisieren oder neu starten, ohne dass Besucher etwas merken.

Gerade dieser zweite Punkt wird unterschätzt. Wartungsfenster nachts entfallen, wenn im laufenden Betrieb umgeschaltet werden kann.

Ab wann sich Verteilung lohnt

Nicht ab einer Besucherzahl, sondern ab einer Anforderung an die Ausfallsicherheit. Ein einzelner ordentlicher Server trägt für die meisten mittelständischen Websites mehr Last, als je anfällt — die Verteilung kauft man für den Fall, dass eine Maschine ausfällt, nicht für Tempo.

Wer sie einführt, verdoppelt die Systeme und damit die Pflege. Diese Rechnung gehört vor die Entscheidung, denn sie fällt bei kleinen Anwendungen oft gegen die Verteilung aus.

Was dabei zu klären ist

Wo die Sitzungsdaten liegen. Landet ein angemeldeter Nutzer beim zweiten Aufruf auf einem anderen Server, ist er abgemeldet — es sei denn, die Sitzung liegt zentral statt lokal.

Dasselbe gilt für hochgeladene Dateien: Sie gehören in einen gemeinsamen Speicher, nicht auf die lokale Platte eines der Server. Beides wird regelmäßig erst nach dem Umstellen bemerkt.

Häufige Fragen zu Load Balancing

Mit den Standardwerten verbreiteter Dienste dauert das bis zu etwa eine Minute: Die Prüfung läuft alle 30 Sekunden, und erst zwei aufeinanderfolgende Fehlschläge nehmen den Server aus dem Verkehr; das Zeitlimit je Prüfung beträgt 5 Sekunden, der einstellbare Abstand reicht von 5 bis 300 Sekunden. In dieser Minute laufen Anfragen weiter auf die ausgefallene Maschine und enden mit einer Fehlerseite.

So viel, dass die verbleibenden Server die gesamte Last allein tragen: Bei zwei Servern darf jeder im Normalbetrieb höchstens die Hälfte seiner Kapazität nutzen, bei drei höchstens zwei Drittel. Die Rechnung lautet Last geteilt durch die Zahl der Server minus eins. Wer zwei Maschinen zu je 80 Prozent auslastet, hat keine Verteilung mit Reserve gebaut, sondern zwei Server, die beim Ausfall des einen gemeinsam überlaufen.

Nicht mehr im Protokoll des Webservers: Der sieht nur die Adresse des Load Balancers und schreibt sie in jede Zeile. Die Herkunft steht dann allein im Kopffeld X-Forwarded-For, das die Anwendung ausdrücklich auswerten muss. Die Referenzdokumentation warnt, dass dieses Feld für sicherheitsrelevante Zwecke – Zugriffssperren, Begrenzung der Anfragezahl – nur dann brauchbar ist, wenn der Server nicht auch direkt aus dem Internet erreichbar bleibt.

Ein Auslieferungsnetz legt Kopien statischer Dateien in Rechenzentren nahe beim Besucher ab und verkürzt damit den Weg; Load Balancing verteilt Anfragen auf mehrere gleichwertige Server am selben Ort. Für dynamische Seiten, Anmeldungen und Formulare hilft das Auslieferungsnetz nicht – diese Anfragen landen weiter beim Ursprung. Fällt dort der einzige Server aus, liefert das Netz allenfalls noch veraltete Kopien; die Anwendung selbst ist nicht erreichbar.

Es schützt nicht vor dem Ausfall dieser Datenbank. Steht sie still, antworten alle verteilten Server gleichzeitig mit einem Fehler – die Verdopplung der Webserver hat die Verfügbarkeit dann nicht erhöht, sondern nur die Zahl der Stellen, die auf denselben Engpass warten. Wer Ausfallsicherheit als Ziel nennt, prüft deshalb jede gemeinsam genutzte Komponente einzeln: Datenbank, Dateispeicher, Zwischenspeicher, Namensauflösung. Verteilt ist ein System erst, wenn kein Bestandteil davon einzeln bleibt.

Mehr zum Thema

9 Min. Lesezeit

NIS2 für kleine Unternehmen: betroffen oder nur Zulieferer?

Unter 50 Beschäftigten ist ein Betrieb von NIS2 in aller Regel nicht direkt erfasst – und bekommt trotzdem Fragebögen seiner Kunden. Wer wirklich betroffen ist, was die Lieferkettenpflicht bedeutet und was ein Zulieferer realistisch vorlegen kann.

9 Min. Lesezeit

SonicWall SMA1000: Sicherheitslücke mit CVSS 10 schließen

SonicWall hat vier Lücken in der SMA1000-Reihe geschlossen, darunter eine SSRF ohne Anmeldung mit der Höchstwertung 10,0. Welche Firmware hilft, warum es keinen Workaround gibt und warum diese Gerätereihe in diesem Jahr schon zweimal angegriffen wurde.

Alle Fachbeiträge ansehen

Passende Leistungen

Hosting & Deployment

Ihre Web-App zuverlässig ausrollen und betreiben: automatische Deployments über GitHub Actions, gehostet auf Hetzner in der EU.

Mehr dazu

Cloud-Migration

Weg von teuren US-Clouds und Altservern: Umzug Ihrer Anwendung in die Hetzner Cloud — containerisiert, skalierbar und DSGVO-konform.

Mehr dazu

Performance-Optimierung

Analyse und Optimierung der Ladezeiten: Bundle-Analyse, Bild-Optimierung und Cache-Strategien für Top Core Web Vitals.

Mehr dazu