Nginx Reverse Proxy sendet dieselbe Anfrage an mehrere Backend-Server

Nginx Reverse Proxy sendet dieselbe Anfrage an mehrere Backend-Server

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_idlegt der Parameter den Namen des Cookies fest, das gesetzt oder überprüft wird. Der optionale expiresParameter legt die Zeit fest, die der Browser das Cookie speichert. Der optionale domainParameter definiert eine Domäne, für die das Cookie gesetzt wird. Der optionale pathParameter 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 creategibt 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 lookupgibt an, wie nach bestehenden Sessions gesucht werden soll. In unserem Beispiel werden bestehende Sessions im vom Client gesendeten Cookie „EXAMPLECOOKIE“ gesucht.

Der obligatorische Parameter zonegibt eine gemeinsam genutzte Speicherzone an, in der alle Informationen zu Sticky Sessions gespeichert werden. In unserem Beispiel hat die Zone einen Namen client_sessionsund 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.

verwandte Informationen