Load Balancer
Komponente, die eingehenden Netzwerk- oder Anwendungsverkehr nach definierten Algorithmen auf mehrere Backend-Server verteilt — Grundlage für Hochverfügbarkeit, Skalierung und Ausfallsicherheit von Web- und API-Diensten.
Ein Load Balancer (deutsch: Lastverteiler) ist eine Komponente, die eingehenden Datenverkehr auf mehrere gleichartige Backend-Server verteilt. Statt dass alle Anfragen auf einen einzelnen Server treffen, entscheidet der Load Balancer pro Verbindung, welche Instanz die Anfrage bearbeitet. Damit verfolgt er zwei eng verwandte Ziele: Skalierung — die Last wird auf mehrere Maschinen aufgeteilt, sodass mehr Anfragen parallel verarbeitet werden können — und Hochverfügbarkeit, weil der Ausfall eines einzelnen Backend-Servers nicht den gesamten Dienst lahmlegt. Load Balancing ist damit ein zentraler Baustein resilienter Web- und API-Infrastrukturen.
Layer 4 vs. Layer 7
Load Balancer unterscheiden sich grundlegend danach, auf welcher Ebene des OSI-Modells sie Entscheidungen treffen. Layer-4-Load-Balancing arbeitet auf der Transportschicht und routet anhand von IP-Adresse und Port, ohne den Inhalt der Verbindung zu kennen. Layer-7-Load-Balancing arbeitet auf der Anwendungsschicht und kann den HTTP-Inhalt — URL-Pfad, Header, Cookies — auswerten und entsprechend verteilen.
| Merkmal | Layer 4 (Transport) | Layer 7 (Anwendung) |
|---|---|---|
| Entscheidungsbasis | IP-Adresse, TCP/UDP-Port | HTTP-Pfad, Header, Cookies, Hostname |
| Sichtbarkeit der Nutzdaten | Keine (durchgereicht) | Volle Inspektion möglich |
| Performance | Sehr hoch, geringer Overhead | Höherer Overhead durch Parsing |
| Funktionen | Reines Verteilen | Routing-Regeln, TLS-Offloading, Content-Switching |
Ein Layer-7-Load-Balancer ist in der Praxis typischerweise auch ein Reverse Proxy: Er terminiert die Client-Verbindung, prüft den HTTP-Inhalt und baut eine eigene Verbindung zum Backend auf. Layer-4-Verteilung bleibt dagegen sinnvoll, wenn maximale Durchsatzleistung oder protokollunabhängiges Routing (etwa für Datenbanken oder reine TCP-Dienste) gefragt ist.
Verteilungsalgorithmen
Welcher Backend-Server eine Anfrage erhält, bestimmt der Load Balancer über einen Algorithmus. Round-Robin reicht Anfragen reihum an alle Server weiter und eignet sich, wenn alle Instanzen gleich leistungsfähig sind. Least-Connections leitet neue Verbindungen an den Server mit den aktuell wenigsten offenen Verbindungen — vorteilhaft bei unterschiedlich langen Anfragen. IP-Hash berechnet aus der Client-IP einen festen Zielserver und sorgt so für Session-Affinität, sodass ein Client während einer Sitzung beim selben Backend bleibt.
Health Checks und Failover
Damit der Load Balancer Ausfälle erkennt, prüft er die Backend-Server kontinuierlich über Health Checks — etwa periodische HTTP-Abfragen eines Status-Endpunkts. Antwortet ein Server nicht oder liefert er Fehler, nimmt der Load Balancer ihn automatisch aus der Rotation und leitet den Verkehr auf die verbleibenden gesunden Instanzen um (Failover). Sobald der Server wieder antwortet, wird er erneut aufgenommen. Diese Selbstheilung ist der eigentliche Kern der Hochverfügbarkeit: Ein einzelner Serverausfall bleibt für die Nutzer unsichtbar.
Sicherheits- und Verfügbarkeitsaspekte
Über die reine Lastverteilung hinaus übernimmt ein Load Balancer oft Sicherheitsfunktionen. Beim TLS-Offloading terminiert er die TLS-Verschlüsselung zentral, sodass die Backend-Server entlastet werden und Zertifikate nur an einer Stelle verwaltet werden müssen. In der DDoS-Abwehr spielt Load Balancing eine doppelte Rolle: Durch die Verteilung über mehrere Instanzen lassen sich Lastspitzen besser absorbieren, und Layer-7-Load-Balancer können auffällige Anfragen per Rate Limiting filtern, bevor sie die Backends erreichen. Gegen volumetrische DDoS-Angriffe reicht der Load Balancer allein jedoch nicht — hier sind vorgelagerte Scrubbing-Dienste oder ein CDN nötig; eine Anycast-Verteilung hilft, die Last über Standorte zu streuen, ersetzt aber keine spezifische Filterung. Für global verteilte Dienste kombiniert man Load Balancing daher häufig mit Anycast, um Nutzer zunächst zum nächstgelegenen Rechenzentrum und dort dann zum passenden Backend zu leiten.
Verbreitete Implementierungen reichen von Software-Load-Balancern wie haproxy und nginx über dedizierte Hardware-Appliances bis zu verwalteten Cloud-Diensten wie AWS Elastic Load Balancing, Google Cloud Load Balancing oder Azure Load Balancer.
Der Load Balancer als Single Point of Failure
So sehr der Load Balancer Verfügbarkeit schafft, so sehr wird er selbst zum kritischen Engpass, wenn er nicht redundant ausgelegt ist. Verteilt eine einzelne Instanz den Verkehr auf zehn hochverfügbare Backends, fällt bei ihrem Ausfall trotzdem der gesamte Dienst aus. In der Praxis betreibt man Load Balancer deshalb paarweise oder im Cluster — etwa mit einer virtuellen IP-Adresse, die per Protokoll wie VRRP zwischen aktivem und passivem Knoten umschwenkt. Wir finden in Assessments regelmäßig Architekturen, in denen die Backends sauber redundant sind, der davorgeschaltete Load Balancer aber als einzelne Maschine läuft und damit den ganzen Redundanzgedanken unterläuft.
Relevanz für KMUs
Für kleine und mittlere Unternehmen ist Load Balancing meist keine Frage eigener Hardware. Wer Anwendungen in der Cloud betreibt, nutzt verwaltete Load Balancer der jeweiligen Plattform; wer eigene Server hostet, kommt mit nginx oder haproxy bereits weit. Entscheidend ist, die Redundanz konsequent zu Ende zu denken: Ein Load Balancer, der selbst nicht doppelt ausgelegt ist, verschiebt das Verfügbarkeitsrisiko nur, statt es zu beseitigen. Wer einen Online-Shop, ein Kundenportal oder eine API betreibt, sollte daher früh klären, ob die Lastverteilung als hochverfügbares Paar konfiguriert ist und ob die Health Checks tatsächlich die Anwendungsgesundheit prüfen — und nicht nur, ob der Port offen ist.