Was ist ein Load Balancer? Lastverteilung mit Nginx einrichten

Was ist ein Load Balancer und wofür brauchen Sie ihn?

Ein Load Balancer (Lastverteiler) ist eine vorgeschaltete Schicht, die eingehende Anfragen auf mehrere Backend Server verteilt, statt alles an eine einzige Maschine zu schicken. So wird kein Server überlastet, der Verkehr umgeht ausgefallene Server automatisch, und Ihre Besucher bemerken davon nichts.

Ein einfacher Vergleich hilft: In einer vollen Bankfiliale mit nur einem Schalter wächst die Schlange, und fällt die Mitarbeiterin aus, steht alles still. Weist dagegen jemand am Eingang die Kunden freien Schaltern zu, sinkt die Wartezeit. Zudem legt ein geschlossener Schalter die Filiale nicht mehr lahm. Genau diese Rolle übernimmt ein Load Balancer für den Webverkehr.

In diesem Beitrag erklären wir die Logik der Lastverteilung, den Unterschied zwischen L4 und L7, die Verfahren aus der offiziellen Nginx Dokumentation und eine funktionierende upstream Konfiguration. Wir, Talha Aslan und Team, arbeiten im digitalen Marketing und in der Webentwicklung; ein Hostinganbieter sind wir nicht. Deshalb stützen wir jedes technische Detail auf die Nginx Dokumentation und nennen keine Standardwerte, die wir nicht prüfen konnten.

Welche Vorteile bringt Lastverteilung einer Website?

Der Nutzen liegt nicht nur in der Geschwindigkeit. Der eigentliche Gewinn besteht darin, dass Ihre Website nicht mehr von einer einzelnen Maschine abhängt. Gerade für Onlineshops mit Lastspitzen während Kampagnen wirkt sich das direkt auf den Umsatz aus.

• Verteilung des Verkehrs: Anfragen landen auf mehreren Servern, daher wird weder CPU noch Arbeitsspeicher eines einzelnen Servers zum Engpass.
• Hochverfügbarkeit: Antwortet ein Backend nicht mehr, nimmt der Load Balancer es aus der Rotation und leitet den Verkehr an die übrigen Server.
• Wartung ohne Ausfall: Sie nehmen einen Server vorübergehend aus dem Pool, aktualisieren ihn, und die Website läuft dabei weiter.
• Horizontale Skalierung: Statt eine größere Maschine zu kaufen, fügen Sie dem Pool einen weiteren Server hinzu.
• Zentraler Einstiegspunkt: Zertifikate, Header Regeln und Zugriffsprotokolle liegen an einer Stelle.

Allerdings macht Lastverteilung eine langsame Anwendung nicht automatisch schneller. Braucht eine Seite wegen einer schweren Datenbankabfrage drei Sekunden, dann wird dieselbe Abfrage auf drei Servern für den einzelnen Besucher nicht kürzer. Deshalb empfehlen wir, zuerst die serverseitigen Ursachen langsamer Websites auszuschließen und erst danach über Skalierung zu entscheiden.

Worin unterscheidet sich ein Load Balancer von einem Reverse Proxy?

Die beiden Begriffe werden oft verwechselt, denn Nginx erledigt beides mit derselben Software. Ein Reverse Proxy steht zwischen Client und Backend und reicht Anfragen an das Backend weiter. Ein Load Balancer leitet ebenfalls weiter, verteilt die Anfragen aber nach einer Regel auf mehrere Ziele.

Anders gesagt: Jeder Load Balancer arbeitet in der Praxis wie ein Reverse Proxy, aber nicht jeder Reverse Proxy verteilt Last. Setzen Sie Nginx vor eine einzelne Node.js Anwendung, damit er TLS und Caching übernimmt, ist das ein Reverse Proxy. Starten Sie dagegen drei Kopien derselben Anwendung und lassen Nginx die Anfragen aufteilen, sprechen wir von Lastverteilung.

Die Grundinstallation von Nginx und den Reverse Proxy mit nur einem Ziel behandeln wir in separaten Beiträgen dieser Reihe; hier wiederholen wir diese Schritte nicht. Wir gehen also davon aus, dass Nginx auf Ihrem Server bereits läuft. Konkret geht es darum, wie Sie mehrere Server mit dem upstream Block verwalten.

Was ist der Unterschied zwischen L4 und L7 beim Load Balancer?

Lastverteiler lassen sich danach unterscheiden, auf welcher Netzwerkschicht sie den Verkehr betrachten. Ein L4 Verteiler (Transportschicht) sieht nur Verbindungsdaten wie IP Adresse und Port. Ein L7 Verteiler (Anwendungsschicht) liest dagegen die HTTP Anfrage selbst und entscheidet anhand von Pfad, Headern, Cookies und Hostname.

Für Websites ist L7 meist die richtige Wahl, weil Sie nach Inhalt routen können. Der offizielle Nginx Leitfaden zur TCP und UDP Lastverteilung beschreibt, dass L4 in einem eigenen stream Kontext läuft. Bei Open Source Nginx müssen Sie dieses Modul beim Kompilieren aktivieren oder dynamisch laden. Prüfen Sie daher, ob das Paket Ihrer Distribution es bereits enthält.

Welche Verfahren zur Lastverteilung unterstützt Nginx?

Die offizielle Nginx Seite zur Lastverteilung und die Referenz des upstream Moduls listen die Verfahren der Open Source Version klar auf. Geben Sie kein Verfahren an, nutzt Nginx standardmäßig Round Robin.

1. Round Robin (Standard): Verteilt Anfragen der Reihe nach. Zudem können Sie einem stärkeren Server mit dem Parameter weight einen größeren Anteil geben.
2. least_conn: Schickt jede neue Anfrage an den Server mit den wenigsten aktiven Verbindungen. Das gleicht besser aus, wenn Anfragen unterschiedlich lange dauern.
3. ip_hash: Bildet einen Schlüssel aus der IP des Clients; derselbe Client landet daher immer auf demselben Server, solange dieser erreichbar ist.
4. hash: Den Schlüssel wählen Sie selbst, zum Beispiel die angefragte URI. Mit consistent verschieben sich weniger Schlüssel, wenn Sie Server hinzufügen oder entfernen.
5. random: Wählt einen Server zufällig. Mit two zieht Nginx zunächst zwei Kandidaten und nimmt dann den weniger ausgelasteten.

Die Dokumentation nennt außerdem least_time, das die Antwortzeit auswertet. Allerdings gehört dieses Verfahren zum kommerziellen NGINX Plus Abonnement. Tragen Sie es in eine Open Source Konfiguration ein, schlägt der Konfigurationstest also fehl. Kurz gesagt: Prüfen Sie jede Direktive für Ihre Version auf der offiziellen Seite.

Welches Verfahren sollten Sie wann wählen?

Die passende Methode hängt davon ab, wie sich Ihre Anwendung verhält. Haben Ihre Server ähnliche Hardware und enden Anfragen schnell, reicht Round Robin meist aus. Es ist zudem die einfachste Variante und überrascht selten.

Unterscheiden sich die Laufzeiten stark, verteilt least_conn dagegen gerechter. Manche Anfragen antworten etwa sofort, andere erzeugen sekundenlang einen Bericht. Weil least_conn die aktuelle Last statt der Reihenfolge betrachtet, kommt es mit dieser Mischung besser zurecht. Dateiuploads, lange API Aufrufe und WebSocket Verbindungen sind typische Beispiele.

ip_hash ist eine schnelle Lösung für ältere Anwendungen, die Sitzungsdaten auf der eigenen Festplatte oder im eigenen Speicher halten. Allerdings teilen sich viele Nutzer oft eine einzige IP, etwa hinter einem Firmennetz, einem Mobilfunkanbieter oder einem Unternehmensproxy. Dann ist ein Server überlastet, während die anderen kaum etwas tun.

hash sehen Sie häufig vor Cache Servern. Landet dieselbe URL immer auf demselben Cache Knoten, steigt die Trefferquote. Schließlich ist random two sinnvoll, wenn mehrere Load Balancer denselben Backend Pool teilen; die Dokumentation nennt verteilte Umgebungen als Haupteinsatz.

Wie richten Sie einen Load Balancer mit Nginx ein?

Lastverteilung in Nginx besteht aus zwei Teilen: einem upstream Block, der den Serverpool definiert, und einer proxy_pass Zeile, die Anfragen dorthin schickt. Das folgende Beispiel nutzt drei Anwendungsserver. Die Adressen stammen aus dem für Dokumentation reservierten Bereich 192.0.2.x; ersetzen Sie sie durch Ihre eigenen.

upstream app_backend {
    least_conn;
    server 192.0.2.11:8080 weight=2;
    server 192.0.2.12:8080;
    server 192.0.2.13:8080 backup;
}

server {
    listen 80;
    server_name example.com;

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

Diese Datei legen Sie üblicherweise unter /etc/nginx/conf.d/ oder im Siteverzeichnis Ihrer Distribution ab. Danach prüfen Sie die Syntax mit sudo nginx -t. Ist alles korrekt, laden Sie die Konfiguration mit sudo systemctl reload nginx neu. Ein Reload übernimmt die neuen Einstellungen, ohne bestehende Verbindungen zu trennen.

Die Header Zeilen sind wichtig. Ohne sie sieht Ihr Backend jede Anfrage so, als käme sie von der IP des Load Balancers. Das verfälscht Protokolle, Sicherheitsregeln und jede IP basierte Auswertung.

Was bewirken weight, backup und down?

Jede server Zeile im upstream Block akzeptiert Parameter, die ihr Verhalten ändern. Laut der offiziellen upstream Referenz funktionieren die gängigsten so:

• weight: Legt den Anteil des Servers am Verkehr fest; der Standardwert ist 1. Im Beispiel der Dokumentation erhält ein Server mit Gewicht 3 drei von fünf neuen Anfragen.
• backup: Markiert den Server als Reserve. Verkehr geht erst dann an ihn, wenn alle primären Server nicht erreichbar sind.
• down: Markiert den Server dauerhaft als nicht verfügbar. Das ist der sauberste Weg, einen Server vor einer Wartung herauszunehmen.
• max_conns: Begrenzt gleichzeitige Verbindungen zum Server; der Standardwert 0 bedeutet keine Grenze.

Eine wichtige Einschränkung gibt es allerdings: Laut Dokumentation lässt sich backup nicht mit hash, ip_hash oder random kombinieren. Planen Sie einen Reserveserver, bleiben Sie deshalb bei Round Robin oder least_conn.

Eine Wartung läuft in der Praxis so ab: Zunächst ergänzen Sie down beim betroffenen Server, testen die Konfiguration und laden neu. Dann warten Sie, bis die aktiven Anfragen auf diesem Server abgeschlossen sind, und spielen das Update ein. Danach entfernen Sie down wieder und laden erneut. Für Besucher war die Website somit nie offline.

Wie prüft Nginx die Erreichbarkeit der Server?

Open Source Nginx arbeitet mit passiven Health Checks. Nginx schickt also keine eigenen Testanfragen an das Backend, sondern wertet das Ergebnis echter Besucheranfragen aus. Scheitern innerhalb eines Zeitfensters genug Versuche, nimmt Nginx den Server vorübergehend aus der Rotation.

Zwei Parameter steuern dieses Verhalten. max_fails legt fest, wie viele Fehlversuche im Zeitfenster einen Server als nicht verfügbar markieren; der Standardwert ist 1, und mit 0 schalten Sie die Zählung ab. fail_timeout bestimmt zugleich das Zeitfenster für die Zählung und die Dauer der Sperre; sein Standardwert beträgt 10 Sekunden.

upstream app_backend {
    server 192.0.2.11:8080 max_fails=3 fail_timeout=30s;
    server 192.0.2.12:8080 max_fails=3 fail_timeout=30s;
}

Was zählt dabei als Fehlversuch? Das definiert die Direktive proxy_next_upstream. Standardmäßig zählen Verbindungsfehler und Zeitüberschreitungen. Zusätzlich können Sie bestimmte HTTP Statuscodes aufnehmen, etwa mit proxy_next_upstream error timeout http_502 http_503;.

Ein Detail verdient Aufmerksamkeit. Nicht idempotente Anfragen wie POST wiederholt Nginx standardmäßig nicht auf einem anderen Server, sobald die Anfrage ein Backend erreicht hat. Somit läuft ein Bestellformular nie doppelt durch. Ändern Sie diese Schutzeinstellung nur, wenn Sie die Folgen genau kennen.

Warum sind aktive Health Checks ein eigenes Thema?

Passive Prüfungen haben eine Schwachstelle. Nginx erkennt einen defekten Server erst, wenn ein echter Besucher dort landet und einen Fehler erhält. Mindestens ein Nutzer sieht den Fehler also. Aktive Prüfungen schicken dagegen in festen Abständen Testanfragen an jeden Server, unabhängig vom Verkehr, und finden das Problem vor den Nutzern.

Der offizielle NGINX Leitfaden zu HTTP Health Checks zieht diese Grenze klar. Passive Prüfungen gibt es sowohl in Open Source Nginx als auch in NGINX Plus. Aktive Prüfungen mit der Direktive health_check sind dagegen dem kommerziellen NGINX Plus vorbehalten. Laut Leitfaden brauchen sie zudem eine gemeinsame Speicherzone per zone im upstream Block.

Auf der Open Source Seite gibt es einige Wege, diese Lücke zu schließen. Sie können Ihrer Anwendung einen einfachen /health Endpunkt geben und ihn mit einem externen Monitoring regelmäßig abfragen. Außerdem lohnt ein Blick auf andere Lastverteiler mit eingebauten aktiven Prüfungen wie HAProxy oder auf den verwalteten Load Balancer Ihres Cloudanbieters. Was passt, hängt von Budget und Betriebskapazität Ihres Teams ab.

Was ist das Problem mit Sticky Sessions?

Viele Anwendungen speichern den Login oder den Warenkorb eines Nutzers im Speicher oder auf der Festplatte des jeweiligen Servers. Auf einem einzelnen Server ist das unproblematisch. Sobald jedoch ein Load Balancer dazukommt, kann die erste Anfrage auf Server A und die zweite auf Server B landen. Server B kennt diese Sitzung nicht, daher wirkt der Nutzer plötzlich abgemeldet oder der Warenkorb ist leer.

Dafür gibt es zwei Ansätze. Der erste ist Sitzungsaffinität, also Sticky Sessions: Der Load Balancer schickt denselben Nutzer immer an denselben Server. In Open Source Nginx ist ip_hash der bekannteste Weg. Laut offizieller upstream Referenz war die auf Cookies basierende Direktive sticky lange nur im kommerziellen Abonnement enthalten. Ein Hinweis auf dieser Seite besagt, dass sie ab Version 1.29.6 auch in der Open Source Version enthalten ist. Prüfen Sie deshalb Ihre Version mit nginx -v, bevor Sie sich darauf verlassen.

Auch Stickiness hat ihren Preis. Stürzt ein Server ab, gehen die daran gebundenen Sitzungen trotzdem verloren. Zudem kann die Last je nach Nutzerverteilung aus dem Gleichgewicht geraten. Deshalb sehen wir Stickiness als Übergangslösung, nicht als Dauerlösung.

Warum sind gemeinsame Sitzungen in Redis die robustere Lösung?

Der zweite Ansatz nimmt die Sitzungen ganz von den Anwendungsservern und legt sie in einen gemeinsamen Speicher. Dann liest jeder Server, egal welcher die Anfrage erhält, die Sitzung vom selben Ort. Ihre Backends werden somit zustandslos; Sie können jeden davon stoppen oder starten, ohne Nutzer zu stören.

Als gemeinsamer Speicher ist Redis am verbreitetsten, weil es im Arbeitsspeicher läuft und sehr schnell antwortet. In Frameworks wie Laravel ist der Wechsel des Sitzungstreibers auf Redis eine Konfigurationsänderung. Auch in PHP können Sie den Session Handler mit der passenden Erweiterung auf Redis umstellen. Mehr zu Redis für Caching und Sitzungen lesen Sie in unserem Beitrag zu Redis und Memcached.

Bedenken Sie allerdings: Eine einzelne Redis Instanz wird dann zum neuen Single Point of Failure. Für kritische Projekte sollten Sie daher auch für Redis Redundanz einplanen. Dieselbe Logik gilt für Uploads. Liegt ein hochgeladenes Bild nur auf der Festplatte von Server A, kann Server B es nicht anzeigen. Uploads gehören folglich in einen gemeinsamen Speicher oder einen Object Storage.

Wie funktioniert die TLS Terminierung am Load Balancer?

Bei der TLS Terminierung, oft noch SSL Terminierung genannt, entschlüsselt der Load Balancer die HTTPS Verbindung und leitet die Anfrage über das interne Netz an das Backend weiter. Somit verwalten Sie das Zertifikat an einer Stelle, statt es auf jedem Anwendungsserver zu installieren. Die Grundlagen erklärt unser Leitfaden zum SSL Zertifikat.

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Der Header X-Forwarded-Proto spielt hier eine zentrale Rolle. Das Backend erhält nämlich reines HTTP. Ohne diesen Header weiß es nicht, dass der Nutzer per HTTPS kam, und gerät womöglich in eine Weiterleitungsschleife. Vertrauen Sie in der Proxy Einstellung Ihres Frameworks außerdem nur der IP des Load Balancers.

Ist das Netz zwischen Load Balancer und Backends geteilt oder nicht vertrauenswürdig, verschlüsseln Sie auch den internen Verkehr. Dann verwenden Sie https in proxy_pass. Prüfen Sie nach der Einrichtung die Zertifikatskette mit unserem SSL Check.

Was passiert, wenn der Load Balancer selbst ausfällt?

Diesen Punkt übersehen viele Teams. Selbst mit drei Backend Servern legt ein einzelner Load Balancer davor die ganze Website lahm, sobald er ausfällt. Sie haben den Single Point of Failure also nicht beseitigt, sondern nur verschoben.

Die klassische Lösung sind zwei Load Balancer, einer aktiv und einer passiv. Beide verwalten über das Protokoll VRRP eine gemeinsame virtuelle IP; keepalived ist dafür ein verbreitetes Open Source Werkzeug. Fällt der aktive Knoten aus, wandert die virtuelle IP zum passiven, und der Verkehr läuft nach kurzer Unterbrechung weiter. Dafür müssen beide Maschinen im selben Netzsegment stehen; das unterstützt nicht jeder VPS Anbieter. Fragen Sie daher zuerst Ihren Anbieter.

Bei größerem Maßstab kommen zudem DNS und Anycast ins Spiel. Prüfen Sie nach jeder Änderung mit unserer DNS Abfrage, ob Ihre Domain auf die richtige IP zeigt. Der allgemeine Name für diese Denkweise lautet N+1 Redundanz: Sie planen zur benötigten Kapazität mindestens eine Reservekomponente ein. Dieses Konzept betrachten wir auf Rechenzentrumsebene in einem eigenen Beitrag.

Wie unterscheiden sich Cloud Load Balancer von Nginx?

Die großen Cloudanbieter bieten verwaltete Lastverteilung als Dienst an. Dabei übernimmt der Anbieter die Redundanz des Load Balancers selbst, aktive Health Checks und oft auch die Zertifikatserneuerung. Sie definieren dann nur noch die Regeln.

Ein eigener Nginx Load Balancer bietet dagegen volle Kontrolle und planbare Kosten. Sie sehen jede Zeile der Konfiguration, ergänzen gewünschte Module und binden sich nicht an einen Anbieter. Der Nachteil: Updates, Monitoring und Redundanz liegen vollständig bei Ihnen.

Stellen Sie sich vor der Entscheidung einige Fragen. Reagiert in Ihrem Team jemand nachts auf eine Störung? Schwankt Ihr Verkehr zudem plötzlich und stark? Und läuft Ihre Infrastruktur ohnehin bei einem einzigen Cloudanbieter? Lauten die meisten Antworten ja, ist ein verwalteter Dienst meist sinnvoller. Unser Vergleich von VPS, VDS und Cloud Server hilft bei der Infrastrukturseite. Nutzen Sie Container, lesen Sie außerdem unseren Beitrag zum Unterschied zwischen Docker und Kubernetes, denn Kubernetes verteilt Verkehr in einer eigenen Serviceschicht.

Wann reicht ein einzelner Server aus?

Seien wir ehrlich: Die meisten Unternehmenswebsites, Blogs und kleinen Onlineshops laufen mit einem gut eingerichteten Server problemlos. Ein Load Balancer erhöht Serveranzahl, Komplexität und monatliche Kosten. Diesen Aufwand sollten Sie deshalb nur bei echtem Bedarf eingehen.

Ein einzelner Server reicht in der Regel, wenn folgende Punkte zutreffen:

• CPU und Arbeitsspeicher bleiben auch zu Spitzenzeiten auf einem entspannten Niveau.
• Ein kurzes, geplantes Wartungsfenster schadet Ihrem Geschäft nicht ernsthaft.
• Der Engpass ist nicht der Server, sondern unoptimierte Abfragen, große Bilder oder fehlendes Caching.
• Ihre Anwendung speichert Sitzungen und Dateien lokal, und es fehlt das Budget, das zu ändern.

Ist zum Beispiel Ihre Ladezeit schlecht, bringen Caching, Bildoptimierung und Codeverbesserungen zunächst einen deutlich günstigeren Gewinn. Unser Leitfaden zur Auswahl des Webhostings hilft Ihnen außerdem, den Ressourcenbedarf realistisch einzuschätzen. Ein Load Balancer gehört erst dann auf die Agenda, wenn diese Schritte ausgeschöpft sind oder Ausfallsicherheit geschäftskritisch wird.

Wann sollten Sie die Einrichtung nicht selbst übernehmen?

Lastverteilung mit Nginx einzurichten ist technisch nicht schwer. Schwierig ist vielmehr, sie über Jahre sicher und aktuell zu halten. Bei Shared Hosting haben Sie ohnehin keinen Zugriff auf die Nginx Konfiguration, denn diese verwaltet Ihr Hostinganbieter. Auch bei verwalteten VPS Paketen sprechen Sie Änderungen an der Infrastruktur zunächst mit dem Anbieter ab.

Überlassen Sie die Aufgabe besser Ihrem Hostinganbieter oder einem erfahrenen Administrator, wenn:

• niemand in Ihrem Team fundierte Erfahrung mit Linux Serververwaltung und Monitoring hat.
• die Website Zahlungen abwickelt und schon wenige Minuten Ausfall echte Verluste verursachen.
• zusätzlich Änderungen an der Anwendung nötig sind, etwa Datenbankreplikation, gemeinsamer Dateispeicher und Umzug der Sitzungen.
• Firewall, DDoS Schutz und Protokollverwaltung gleichzeitig geplant werden müssen.

Auf der Anwendungsseite sorgen wir dafür, dass die Anwendung für Lastverteilung bereit ist, also Sitzungen und Dateien zustandslos funktionieren. Der Betrieb der Infrastruktur sollte dagegen bei Ihrem Anbieter oder Ihrem Systemteam bleiben. In unseren Projekten zur individuellen Softwareentwicklung klären wir diese Aufteilung von Anfang an.

Was sollten Sie nach der Einrichtung testen?

Die Konfiguration neu zu laden und die Website im Browser zu öffnen, ist kein echter Test. Ein Load Balancer zeigt seinen Wert erst, wenn etwas schiefgeht. Deshalb sollten Sie Ausfälle vor dem Livegang bewusst simulieren.

1. Ergänzen Sie vorübergehend einen Antwortheader, der sich je Backend unterscheidet, und prüfen Sie, ob sich die Anfragen wirklich verteilen.
2. Stoppen Sie die Anwendung auf einem Backend. Prüfen Sie, ob die Website weiter lädt und das Nginx Fehlerprotokoll die passende Warnung zeigt.
3. Melden Sie sich an, legen Sie ein Produkt in den Warenkorb und klicken Sie dann durch einige Seiten. Die Sitzung muss erhalten bleiben.
4. Kontrollieren Sie in den Backend Protokollen, ob die echte IP des Besuchers erscheint.
5. Testen Sie, dass zwischen HTTPS Anfragen und HTTP Antworten keine Weiterleitungsschleife entsteht.
6. Starten Sie den gestoppten Server neu und beobachten Sie, wie er nach Ablauf von fail_timeout in den Pool zurückkehrt.

Wir empfehlen, daraus eine Checkliste zu machen und sie nach jedem größeren Update zu wiederholen. Nehmen Sie außerdem die Konfigurationsdateien des Load Balancers in Ihre Backup Strategie für die Website auf. Fällt ein Server aus, brauchen Sie genau diese Dateien zuerst.

Welche Fehler passieren beim Load Balancer am häufigsten?

Die meisten Probleme bei der Lastverteilung stammen nicht von Nginx. Vielmehr liegen sie an Anwendungen, die nicht für mehrere Server vorbereitet sind. Prüfen Sie daher die Anwendungsseite genauso sorgfältig wie die Konfiguration.

Der erste häufige Fehler: Sitzungen und Dateien bleiben auf der lokalen Festplatte. Die Folge sind Nutzer, die zufällig abgemeldet werden, und Bilder, die verschwinden. Zweitens fehlen oft die Header X-Forwarded-For und X-Forwarded-Proto. Dann sehen Analyse und Sicherheitsregeln die falsche IP, und HTTPS Weiterleitungen laufen im Kreis. Drittens laufen geplante Aufgaben auf jedem Server. Startet etwa derselbe Newsletterjob auf drei Servern, erhält jeder Nutzer dreimal dieselbe Nachricht.

Ein weiterer Fehler ist, auf einen neuen Server eine ältere Codeversion zu spielen. Automatisieren Sie daher die Auslieferung, damit alle Server denselben Stand haben. Schließlich wird oft vergessen, den Load Balancer selbst zu überwachen. Wer nur die Backends beobachtet und die einzelne Maschine davor ignoriert, holt sich den beschriebenen Single Point of Failure zurück.

Wie treffen Sie die Entscheidung für Lastverteilung?

Zusammengefasst ist ein Load Balancer eine Schicht, die Verkehr verteilt, Kapazität schafft und den Ausfall einzelner Server vor Nutzern verbirgt. Open Source Nginx bietet dafür Round Robin, least_conn, ip_hash, hash und random sowie passive Health Checks. Aktive Health Checks bleiben dagegen eine Funktion von NGINX Plus.

Die Reihenfolge ist entscheidend. Zunächst messen und optimieren Sie Ihren einzelnen Server. Dann machen Sie Ihre Anwendung zustandslos, indem Sie Sitzungen in einen gemeinsamen Speicher wie Redis und Dateien in einen gemeinsamen Speicherort verlagern. Erst danach ergänzen Sie einen Load Balancer und planen auch für ihn eine Reserve ein.

Sollen Infrastruktur und Marketingziele Ihrer Website in dieselbe Richtung laufen, klären wir diese Fragen gern gemeinsam in einem Webdesign Projekt. Wir machen die Anwendung bereit für Lastverteilung und planen den Betrieb der Infrastruktur zusammen mit Ihrem Hostinganbieter.