Detaillierte Erläuterung der Nginx-Upstream-Konfiguration und -Funktion

Konfigurationsbeispiel

Upstream-Backend {
  Server backend1.example.com Gewicht=5;
  Server backend2.example.com:8080;
  Server-Unix:/tmp/backend3;

  Server-Backup1.example.com:8080-Backup;
  Server-Backup2.example.com:8080-Backup;
}

Server {
  Standort / {
    Proxy-Passwort http://backend;
  }
}

Anweisung

Definiert eine Gruppe von Servern. Diese Server können auf verschiedenen Ports lauschen. Darüber hinaus können Server, die auf TCP- und UNIX-Domänen-Sockets lauschen, gemischt werden.

Beispiel:

Upstream-Backend {
  Server backend1.example.com Gewicht=5;
  Server 127.0.0.1:8080 max_fails=3 Fail_Timeout=30s;
  Server-Unix:/tmp/backend3;
}

Standardmäßig verteilt nginx Anfragen im gewichteten Round-Robin-Verfahren an die Server. Im obigen Beispiel werden jeweils 7 Anfragen wie folgt verteilt: 5 Anfragen an backend1.example.com, 1 Anfrage an den zweiten Server und 1 Anfrage an den dritten Server. Wenn bei der Kommunikation mit einem Server ein Fehler auftritt, wird die Anforderung an den nächsten Server weitergeleitet, bis alle verfügbaren Server ausprobiert wurden. Wenn alle Server einen Fehler zurückgeben, erhält der Client das (Fehler-)Antwortergebnis des letzten Servers, mit dem kommuniziert wurde.

Definieren Sie die Serveradresse und andere Parameter. Die Adresse kann ein Domänenname oder eine IP-Adresse sein und der Port ist optional, oder der Pfad zu einem UNIX-Domänen-Socket, der mit dem Präfix „unix:“ angegeben ist. Wenn kein Port angegeben ist, wird Port 80 verwendet. Wenn ein Domänenname in mehrere IP-Adressen aufgelöst wird, werden grundsätzlich mehrere Server definiert.

Sie können die folgenden Parameter definieren: weight=number legt das Gewicht des Servers fest, der Standardwert ist 1. max_fails=number legt die Anzahl der fehlgeschlagenen Versuche von Nginx fest, mit dem Server zu kommunizieren. Wenn die Anzahl der Fehler diesen Wert innerhalb des durch den Parameter fail_timeout definierten Zeitraums erreicht, betrachtet Nginx den Server als nicht verfügbar. Während des nächsten Fail_Timeout-Zeitraums wird kein erneuter Versuch mit dem Server unternommen. Die Standardanzahl fehlgeschlagener Versuche beträgt 1. Wenn der Wert auf 0 gesetzt ist, werden die Versuche nicht mehr gezählt und es wird davon ausgegangen, dass der Server immer verfügbar ist. Sie können mit den Anweisungen proxy_next_upstream, fastcgi_next_upstream und memcached_next_upstream konfigurieren, was als fehlgeschlagener Versuch gilt. Standardmäßig wird der http_404-Status nicht als fehlgeschlagener Versuch betrachtet. fail_timeout=Zeiteinstellung

• Der Zeitraum für die Zählung fehlgeschlagener Versuche. Wenn der Server innerhalb dieser Zeit die angegebene Anzahl von Versuchen nicht schafft, gilt der Server als nicht verfügbar.
• Der Zeitraum, während dem der Server als nicht verfügbar gilt.

Standardmäßig beträgt das Timeout 10 Sekunden. Backup kennzeichnet den Server als Backup-Server. Wenn der primäre Server nicht verfügbar ist, werden Anfragen an diese Server weitergeleitet. down markiert den Server als dauerhaft nicht verfügbar und kann zusammen mit der Direktive ip_hash verwendet werden.

Beispiel:

Upstream-Backend {
  Server backend1.example.com Gewicht=5;
  Server 127.0.0.1:8080 max_fails=3 Fail_Timeout=30s;
  Server-Unix:/tmp/backend3;

  Server-Backup1.example.com:8080-Backup;
}

Gibt die Lastausgleichsmethode für die Servergruppe an. Anforderungen werden basierend auf der IP-Adresse des Clients auf die Server verteilt. Als Hash-Schlüssel werden die ersten drei Bytes der IPv4-Adresse bzw. die gesamte Adresse bei IPv6 verwendet. Diese Methode stellt sicher, dass Anfragen desselben Clients an denselben Server gesendet werden. Sofern ein Server nicht als nicht verfügbar gilt, werden diese Client-Anfragen an andere Server, höchstwahrscheinlich an denselben Server, weitergeleitet.

IPv6-Adressen werden ab den Versionen 1.3.2 und 1.2.2 unterstützt.

Wenn einer der Server vorübergehend entfernt werden soll, sollte der Down-Parameter hinzugefügt werden. Dadurch bleibt die aktuelle Hash-Verteilung der Client-IP-Adressen erhalten.

Beispiel:

Upstream-Backend {
  ip_hash;

  Server backend1.example.com;
  Server backend2.example.com;
  Server backend3.example.com ausgefallen;
  Server backend4.example.com;
}

Ab den Versionen 1.3.1 und 1.2.2 unterstützt die Lastausgleichsmethode „ip_hash“ das Festlegen von Servergewichtungswerten.

Diese Anweisung erschien in der Version 1.1.4.

Aktiviert das Caching von Verbindungen zu Upstream-Servern.

Der Verbindungsparameter legt die maximale Anzahl von Verbindungen fest, die jeder Arbeitsprozess mit dem Backend-Server aufrechterhält. Diese aufrechterhaltenen Verbindungen werden zwischengespeichert. Wenn die Anzahl der Verbindungen größer als dieser Wert ist, wird die am längsten ungenutzte Verbindung geschlossen.

Es ist wichtig zu beachten, dass die Keepalive-Direktive die Gesamtzahl der Verbindungen, die der Nginx-Prozess zu den Upstream-Servern herstellen kann, nicht begrenzt. Neue Verbindungen werden immer nach Bedarf erstellt. Der Verbindungsparameter sollte etwas niedriger eingestellt werden, damit der Upstream-Server die zusätzlichen eingehenden Verbindungen verarbeiten kann.

Beispiel für die Keepalive-Konfiguration der Memcached-Upstream-Serververbindung:

upstream memcached_backend {
  Server 127.0.0.1:11211;
  Server 10.0.0.2:11211;

  Keepalive 32;
}

Server {
  ...

  Standort /memcached/ {
    setze $memcached_key $uri;
    memcached_pass memcached_backend;
  }

}

Für HTTP-Proxys sollte die Direktive proxy_http_version auf „1.1“ gesetzt und der Wert des Headers „Connection“ gelöscht werden.

upstream http_backend {
  Server 127.0.0.1:8080;

  Keepalive 16;
}

Server {
  ...

  Standort /http/ {
    Proxy-Passwort http://http_backend;
    Proxy_http_Version 1.1;
    proxy_set_header Verbindung "";
    ...
  }
}

Alternativ können dauerhafte Verbindungen mit dem HTTP/1.0-Protokoll auch durch das Senden eines „Connection: Keep-Alive“-Headers hergestellt werden. Dies wird jedoch nicht empfohlen.

Für FastCGI-Server müssen Sie die Direktive fastcgi_keep_conn festlegen, damit die Verbindung erhalten bleibt:

upstream fastcgi_backend {
  Server 127.0.0.1:9000;

  am Leben bleiben 8;
}

Server {
  ...

  Standort /fastcgi/ {
    fastcgi_pass fastcgi_backend;
    fastcgi_keep_conn ein;
    ...
  }
}

Wenn Sie eine andere Lastausgleichsmethode als die standardmäßige Round-Robin-Methode verwenden, muss diese vor der Keepalive-Direktive konfiguriert werden.

Es gibt keine Pläne, Keepalive-Verbindungen für die SCGI- und uwsgi-Protokolle zu implementieren.

Diese Anweisung erschien in den Versionen 1.3.1 und 1.2.2.

Gibt die Lastausgleichsmethode für die Servergruppe an. Die Anforderung wird an den Server mit den wenigsten aktiven Verbindungen entsprechend seinem Gewichtungswert gesendet. Wenn mehrere solcher Server vorhanden sind, versuchen Sie es mit einer gewichteten Round-Robin-Methode.

Eingebettete Variablen

Das Modul ngx_http_upstream_module unterstützt die folgenden eingebetteten Variablen:

$upstream_addr enthält die IP-Adresse und den Port des Servers oder den Pfad zu einem UNIX-Domänen-Socket. Wenn während der Anforderungsverarbeitung mehrere Server ausprobiert werden, werden ihre Adressen aneinandergereiht und durch Kommas getrennt, zum Beispiel: „192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock“. Wenn es interne Weiterleitungen zwischen Servern über den Header „X-Accel-Redirect“ oder die Fehlerseite gibt, werden diese Servergruppen durch Doppelpunkte getrennt, zum Beispiel: „192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80“. $upstream_response_time enthält die Serverantwortzeit mit Millisekundengenauigkeit (Ausgabe) in Sekunden. Bei mehreren Antworten werden diese ebenfalls durch Kommas und Doppelpunkte getrennt. $upstream_status enthält den Antwortcode des Servers. Bei mehreren Antworten werden diese ebenfalls durch Kommas und Doppelpunkte getrennt. $upstream_http_... enthält den Wert des Antwortheaders des Servers. Beispielsweise kann der Wert des Antwortheaders „Server“ über die Variable $upstream_http_server abgerufen werden. Beachten Sie, dass nur die Header der letzten Antwort erhalten bleiben.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.