
Ich habe NGINX als Reverse-Proxy und zwei Apache als Upstream-Server.
Immer wenn ich example.com besuche (umgeleitet zu NGINX), erhalten beide Apache-Server die GET-Anforderung. Das scheint seltsam, da NGINX standardmäßig auf der Round-Robin-Methode basiert
Hier ist meine Konfiguration: -
upstream apache {
server 172.18.0.164;
server 172.18.8.18;
}
location / {
proxy_pass http://apache;
}
Protokolliert die Apache 1-Maschine: -
192.168.10.236 - - [05/Okt/2015:07:59:21 -0400] "GET / HTTP/1.0" 200
Protokolliert die Apache 2-Maschine: -
172.18.8.97 - - [05/Okt/2015:11:59:27 +0000] "GET /wordpress/ HTTP/1.0"
Antwort1
Direkt aus demNginx-Administratorhandbuch:
Aktivieren der Sitzungspersistenz
NGINX Plus unterstützt drei Methoden zur Session-Persistenz. Die Methoden werden mit demklebrigRichtlinie.
Derklebriger KeksMethode. Mit dieser Methode fügt NGINX Plus der ersten Antwort der Upstream-Gruppe ein Sitzungscookie hinzu und identifiziert den Server, der die Antwort gesendet hat. Wenn ein Client die nächste Anfrage stellt, enthält diese den Cookie-Wert und NGINX Plus leitet die Anfrage an denselben Upstream-Server weiter:
upstream backend {
server backend1.example.com;
server backend2.example.com;
sticky cookie srv_id expires=1h domain=.example.com path=/;
}
Im Beispiel srv_id
legt der Parameter den Namen des Cookies fest, das gesetzt oder überprüft wird. Der optionale expires
Parameter legt die Zeit fest, die der Browser das Cookie speichert. Der optionale domain
Parameter definiert eine Domäne, für die das Cookie gesetzt wird. Der optionale path
Parameter definiert den Pfad, für den das Cookie gesetzt wird. Dies ist die einfachste Methode zur Sitzungspersistenz.
Derklebrige RouteMethode. Mit dieser Methode weist NGINX Plus dem Client eine „Route“ zu, wenn er die erste Anfrage erhält. Alle nachfolgenden Anfragen werden mit derRouteParameter derServerDirektive zur Identifizierung des Servers, an den die Anfragen weitergeleitet werden. Die Routeninformationen werden entweder aus dem Cookie oder der URI übernommen.
upstream backend {
server backend1.example.com route=a;
server backend2.example.com route=b;
sticky route $route_cookie $route_uri;
}
DerKekse lernenMethode. Mit dieser Methode findet NGINX Plus zunächst Sitzungskennungen, indem es Anfragen und Antworten überprüft. Dann „lernt“ NGINX Plus, welcher Upstream-Server welcher Sitzungskennung entspricht. Im Allgemeinen werden diese Kennungen in einem HTTP-Cookie übergeben. Wenn eine Anfrage eine bereits „gelernte“ Sitzungskennung enthält, leitet NGINX Plus die Anfrage an den entsprechenden Server weiter:
upstream backend {
server backend1.example.com;
server backend2.example.com;
sticky learn
create=$upstream_cookie_examplecookie
lookup=$cookie_examplecookie
zone=client_sessions:1m
timeout=1h;
}
Im Beispiel erstellt einer der Upstream-Server eine Sitzung, indem er in der Antwort das Cookie „EXAMPLECOOKIE“ setzt.
Der obligatorische Parameter create
gibt eine Variable an, die angibt, wie eine neue Sitzung erstellt wird. In unserem Beispiel werden neue Sitzungen aus dem vom Upstream-Server gesendeten Cookie „EXAMPLECOOKIE“ erstellt.
Der obligatorische Parameter lookup
gibt an, wie nach bestehenden Sessions gesucht werden soll. In unserem Beispiel werden bestehende Sessions im vom Client gesendeten Cookie „EXAMPLECOOKIE“ gesucht.
Der obligatorische Parameter zone
gibt eine gemeinsam genutzte Speicherzone an, in der alle Informationen zu Sticky Sessions gespeichert werden. In unserem Beispiel hat die Zone einen Namen client_sessions
und eine Größe von 1 Megabyte.
Dies ist eine anspruchsvollere Methode zur Sitzungspersistenz, da keine Cookies auf der Clientseite gespeichert werden müssen: Alle Informationen werden serverseitig in der gemeinsam genutzten Speicherzone gespeichert.