Lastverteilung verteilt die Besucher einer Site auf mehrere App-Server. Davor sitzt ein Load-Balancer-Server: Deine Domain zeigt auf ihn, er antwortet über HTTP und HTTPS, und Nginx leitet jeden Request an einen der App-Server dahinter weiter. Antwortet ein App-Server nicht mehr, übernehmen die anderen.
In Vimonto Deploy ist ein Load Balancer ein eigener Server mit einer lastverteilten Site darauf. Auf der Seite Lastverteilung dieser Site wählst du die App-Server, legst fest, wie der Traffic zwischen ihnen aufgeteilt wird, und bestimmst, welche nur einspringen, wenn die anderen ausfallen.
Wie funktioniert Lastverteilung?
| Teil | Was er tut |
|---|---|
| Load-Balancer-Server | Ein Server vom Typ Load Balancer, nur mit Nginx. Das DNS deiner Domain zeigt auf ihn. |
| Lastverteilte Site | Die Site auf dem Load Balancer, angelegt aus der Vorlage Load Balancer. Sie hat die Domain, das Zertifikat und die Liste der App-Server, aber keinen Code. |
| App-Server | App- oder Webserver in deiner Organisation, jeder mit einer Site für dieselbe Domain. Sie führen deinen Code aus und werden wie gewohnt deployt. |
Ein Besucher verbindet sich mit dem Load Balancer. Nginx wählt dort einen App-Server, leitet den Request mit dem ursprünglichen Host und den X-Forwarded-*-Headern weiter und schickt die Antwort zurück. Die App-Server sehen die IP-Adresse des Besuchers und ob er HTTPS genutzt hat, weil ihre Sites diesem Load Balancer vertrauen (siehe was die App-Server brauchen).
Einen Load Balancer einrichten
- Lege einen Server vom Typ Load Balancer an. Er bekommt nur Nginx; siehe Servertypen.
- Stelle sicher, dass jeder App-Server eine Site für deine Domain hat, zum Beispiel
shop.example.com, und dass sie deployt ist. Verwende dieselbe Domain oder füge sie unter Domains und SSL als Alias hinzu. - Klicke auf der Seite Sites des Load Balancers auf Neue Site und wähle Load Balancer unter Lastverteilung.
- Gib mit Eigene Domain verwenden dieselbe Domain ein und klicke auf Site anlegen. Eine lastverteilte Site hat kein Repository, keine Datenbank und keine Deploys.
- Öffne die Seite Lastverteilung der neuen Site und füge deine App-Server hinzu (siehe unten).
- Lass das DNS der Domain auf die IP-Adresse des Load Balancers zeigen und aktiviere HTTPS auf der Site des Load Balancers unter Domains und SSL.
Bis du einen App-Server hinzufügst, beantwortet der Load Balancer jeden Request mit 503 Service Unavailable, und die Übersicht der Site zeigt Noch keine App-Server. Besucher bekommen einen 503, bis du einen hinzufügst.
Ein Load-Balancer-Server nimmt nur lastverteilte Sites auf, und die Vorlage Load Balancer lässt sich nur auf einem Load-Balancer-Server anlegen: Das Formular listet nur die passenden Server auf.
Einen App-Server hinzufügen
- Klicke auf der Seite Lastverteilung der Site auf Server hinzufügen.
- Wähle den Server. Die Liste enthält die aktiven App- und Webserver deiner Organisation, auf die du Zugriff hast.
- Lege den Port fest, auf dem die Site des App-Servers lauscht: standardmäßig
80. - Lege das Gewicht fest, von 1 bis 100: Ein Server mit Gewicht 3 bekommt dreimal so viele Requests wie einer mit Gewicht 1.
- Schalte Reserveserver ein, wenn dieser Server nur Traffic bekommen soll, wenn die anderen Server ausgefallen sind.
- Klicke auf Server hinzufügen.
Der Load Balancer erreicht den App-Server über das private Netzwerk, wenn beide Server im selben sind, sonst über seine öffentliche IP-Adresse. Die Liste Server zeigt jeden App-Server mit der Adresse und dem Port, die der Load Balancer verwendet, seinem Gewicht und einem Badge Reserve.
Ein Server kann mehrmals hinzugefügt werden, auf verschiedenen Ports.
Einen App-Server bearbeiten
Klicke neben dem Server auf Bearbeiten, ändere seinen Port, sein Gewicht oder die Einstellung Reserveserver und klicke auf Speichern. Der Server selbst bleibt derselbe; um einen anderen zu verwenden, füge ihn hinzu und nimm diesen heraus. Die Änderung wird sofort angewendet.
Die Verteilungsmethode wählen
Klicke unter Methode auf eine der drei Optionen. Die Änderung wird sofort angewendet.
| Methode | Wie Nginx einen App-Server wählt |
|---|---|
| Round Robin (Standard) | Jeden Server der Reihe nach, nach Gewicht. |
| Wenigste Verbindungen | Den Server mit den wenigsten offenen Verbindungen, für Requests, die sehr unterschiedlich lange dauern. |
| IP-Hash | Jeder Besucher bleibt anhand seiner IP-Adresse bei einem Server. Nutze das nur, wenn deine App etwas auf einem Server ablegt. |
Nginx akzeptiert keine Reserveserver zusammen mit IP-Hash, deshalb lässt Vimonto Deploy dich beides nicht kombinieren. Ist IP-Hash gewählt, lässt sich Reserveserver nicht einschalten, und das Formular zeigt IP-Hash funktioniert nicht mit Reserveservern. Wähle zuerst eine andere Methode. Steht ein Reserveserver in der Liste, wird die Wahl von IP-Hash mit IP-Hash funktioniert nicht mit Reserveservern abgelehnt: Bearbeite zuerst deine Reserveserver, sodass sie keine Reserve mehr sind.
Was passiert, wenn ein App-Server ausfällt?
Der Load Balancer prüft die App-Server über die Requests, die er schickt; separate Health Checks gibt es nicht. Schlägt ein Request an einen App-Server mit einem Verbindungsfehler, einem Timeout oder einem 502, 503 oder 504 fehl, versucht Nginx den nächsten Server, sodass der Besucher trotzdem eine Antwort bekommt. Nach 3 Fehlern innerhalb von 10 Sekunden bekommt der Server 10 Sekunden lang keinen Traffic, danach versucht Nginx es erneut.
Reserveserver bekommen nur Traffic, wenn alle anderen Server nicht erreichbar sind.
Einen App-Server herausnehmen
Klicke neben dem Server auf Herausnehmen und bestätige. Der Load Balancer schickt keinen Traffic mehr an ihn, und die Sites auf diesem Server vertrauen dem Load Balancer nicht mehr (siehe unten). Sonst ändert sich nichts auf dem Server, und seine Site funktioniert unter ihrer eigenen Adresse weiter.
Dieselbe Bereinigung geschieht von selbst, wenn du die lastverteilte Site oder den Load-Balancer-Server löschst: Die Sites auf den App-Servern vertrauen ihm dann nicht mehr. Löschst du einen App-Server, schickt der Load Balancer keinen Traffic mehr an ihn.
Was brauchen die App-Server?
Jede Änderung auf der Seite Lastverteilung schreibt auch die Nginx-Konfiguration der Sites auf den App-Servern, die dieselbe Domain ausliefern. Diese Sites vertrauen dann dem Load Balancer, und nur ihm:
- Die IP-Adresse des Besuchers. Nginx übernimmt die Adresse aus
X-Forwarded-For, aber nur, wenn der Request vom Load Balancer kommt (set_real_ip_from). Deine App sieht die IP-Adresse des Besuchers als Remote-Adresse, ohne eigene Proxy-Einstellungen. - HTTPS. Hat der Load Balancer den Request über HTTPS empfangen, bekommt PHP
HTTPS=onund eine Node.js-AppX-Forwarded-Proto: https. Laravel und andere Frameworks erzeugen dannhttps://-Links ohne Trusted-Proxy-Konfiguration.
Requests von anderswo können diese Header nicht fälschen. Nimmst du einen Server heraus oder löschst du die lastverteilte Site oder den Load Balancer, wird das Vertrauen wieder entfernt. Eine Site mit einer eigenen Nginx-Konfiguration bleibt unangetastet; ergänze diese Zeilen dort selbst.
Deine App muss außerdem auf mehreren Servern gleichzeitig funktionieren:
- Lege Sessions und Cache in Redis oder der Datenbank ab, auf einem gemeinsamen Datenbank- oder Cache-Server, nicht in Dateien auf einem Server. Bei Laravel heißt das:
SESSION_DRIVERundCACHE_STOREstehen in der .env jedes App-Servers aufredisoderdatabaseund zeigen auf dasselbe Redis oder dieselbe Datenbank. - Lege Uploads in einem Object Storage wie S3 ab, nicht in
storage/eines einzelnen Servers. - Deploye die Site jedes App-Servers. Jeder App-Server hat sein eigenes Release und seinen eigenen Deploy, also deploye alle, wenn du eine neue Version veröffentlichst.
- Lass den Scheduler nur auf einem App-Server laufen, es sei denn, deine geplanten Aufgaben dürfen problemlos mehrfach laufen.
HTTPS gehört auf den Load Balancer, der mit den App-Servern einfaches HTTP spricht. Eine Site auf einem App-Server darf trotzdem ein eigenes Zertifikat haben, etwa um sie direkt zu erreichen: Sie leitet einfaches HTTP für alle auf HTTPS um, außer für den Load Balancer, den sie über einfaches HTTP bedient. So entsteht keine Weiterleitungsschleife.
HTTPS auf dem Load Balancer
Die lastverteilte Site hat ihre eigene Seite Domains und SSL. Weil deine Domain auf den Load Balancer zeigt, forderst du dort wie bei jeder Site ein kostenloses Let's-Encrypt-Zertifikat an, das sich automatisch verlängert. Der Load Balancer antwortet dann über HTTPS, leitet HTTP auf HTTPS weiter und reicht die Requests über HTTP an die App-Server weiter, mit X-Forwarded-Proto: https.
Der Traffic zwischen Load Balancer und App-Servern ist nicht verschlüsselt. Bring sie ins selbe private Netzwerk, damit er im Netzwerk deines Providers bleibt.
So sieht die Nginx-Konfiguration aus
Die Konfiguration der lastverteilten Site hat einen upstream-Block mit den App-Servern und eine location, die Requests daran weiterleitet:
upstream site_7_servers {
least_conn;
server 10.0.0.3:80 weight=3 max_fails=3 fail_timeout=10s;
server 10.0.0.4:80 max_fails=3 fail_timeout=10s backup;
keepalive 32;
}
server {
# listen, server_name, certificate and logs as for every site
location / {
proxy_pass http://site_7_servers;
proxy_http_version 1.1;
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;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade_keepalive;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_read_timeout 120;
}
}
Verbindungen zu den App-Servern bleiben offen und werden wiederverwendet, und WebSocket-Verbindungen werden durchgereicht. Jede Änderung wird als Hintergrundaufgabe geschrieben, mit nginx -t getestet und erst dann geladen; lehnt Nginx sie ab, bleibt die vorherige Konfiguration aktiv. Siehe Nginx.
Hast du auf der Seite Nginx der lastverteilten Site eine eigene Konfiguration gespeichert, werden Änderungen auf der Seite Lastverteilung gespeichert, aber nicht angewendet: Du siehst Gespeichert, nicht angewendet. Stelle auf der Seite Nginx die Standardkonfiguration wieder her, um sie zu nutzen.
Was hat eine lastverteilte Site noch?
Die Seitenleiste einer lastverteilten Site zeigt Übersicht, Lastverteilung, Domains und SSL, Logs, Nginx und Einstellungen. Sie hat keine Seite Deployments oder Umgebung, weil sie keinen Code hat. Ihre Seite Einstellungen hat nur Site löschen: Es gibt kein Web-Verzeichnis, keine Deploy-Einstellung und keine Isolation zu wählen. Der Site-Header zeigt, an wie viele App-Server sie Traffic weiterleitet.
- Logs zeigt die eigenen Nginx-Fehler- und Request-Logs des Load Balancers. Die Logs deiner App findest du bei den Sites auf den App-Servern.
- Passwortschutz im Framework-Menü des Site-Headers schützt alle App-Server hinter dem Load Balancer auf einmal. Es ist das einzige Site-Feature einer lastverteilten Site.
Jedes Mitglied kann die Seite Lastverteilung sehen. Server hinzufügen, bearbeiten und herausnehmen sowie die Methode ändern erfordern die Berechtigung, Sites zu verwalten; siehe Mitglieder und Rollen. Jede Änderung wird im Audit-Log festgehalten.
Häufig gestellte Fragen
Wie viele App-Server kann ich hinter einen Load Balancer setzen?
So viele du willst. Jeder ist eine Zeile im upstream-Block.
Brauche ich Sticky Sessions?
Nicht, wenn Sessions in Redis oder der Datenbank liegen, die jeder App-Server liest. Dann funktioniert Round Robin oder Wenigste Verbindungen am besten. Nutze IP-Hash nur, wenn wirklich etwas auf einem einzelnen Server liegt.
Kann ich einen Load Balancer für mehrere Domains nutzen?
Ja. Lege auf dem Load Balancer pro Domain eine lastverteilte Site an, jede mit ihren eigenen App-Servern.
Warum wird meine Domain auf den App-Servern so angezeigt, als zeige sie woandershin?
Weil sie auf den Load Balancer zeigt, wie es sein soll. Nur die Site des Load Balancers braucht den DNS-Eintrag und das Zertifikat.