Ankündigung von NGINX Plus R20

Liam CrillySenior Director, Produktmanagement

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 20 (R20) ab sofort verfügbar ist. NGINX Plus ist der einzige All-in-One-Load-Balancer, Content-Cache, Webserver und API-Gateway. NGINX Plus basiert auf NGINX Open Source und bietet exklusive erweiterte Funktionen sowie preisgekrönten Support.

NGINX Plus R20 baut auf den in R19 vorgenommenen Verbesserungen bei der Ratenbegrenzung und dem Schlüssel-Wert-Speicher auf. Zu den neuen Funktionen gehören:

• Echtzeitüberwachung und -protokollierung von zugratenbegrenztem Datenverkehr – Wenn die Zugratenbegrenzung konfiguriert ist, meldet die NGINX Plus API jetzt, wie viele Anfragen sofort weitergeleitet, verzögert oder abgelehnt werden. Sie können außerdem das Zugriffsprotokoll so konfigurieren, dass es Informationen zum Status der Zugratenbegrenzung einzelner Anfragen enthält.
• Verbesserungen bei der Verbindungsbegrenzung – Die mit R19 und dieser Version eingeführten Verbesserungen bei der Anfrageratenbegrenzung wurden auf die Verbindungsbegrenzung ausgeweitet.
• Präfixabgleich im Schlüssel-Wert-Speicher – Schlüssel im Schlüssel-Wert-Speicher können mit einem angegebenen Präfix (Zeichen am Anfang einer Zeichenfolge) abgeglichen werden. Ein wichtiger Anwendungsfall ist das dynamische Routing von Anfragen.
• DNS-Auflösung pro Upstream-Gruppe – Sie können jetzt für jede Upstream-Gruppe, die einen auflösbaren Hostnamen zur Angabe der Backend-Server in der Gruppe verwendet, einen eigenen Satz von DNS-Servern festlegen.
• Zusätzliche PROXY-Protokollvariablen – Neue Variablen erfassen die IP-Adresse und den Port des Proxyservers, mit dem der Client ursprünglich verbunden war.
• Sicherheitsverbesserungen für HTTP/2 – Mehrere Änderungen verbessern die allgemeine Sicherheit des HTTP/2-Datenverkehrs, darunter eine bessere Erkennung fehlerhaften oder ungültigen Clientverhaltens sowie eine robustere Implementierung bestimmter Direktiven.

Wichtige Verhaltensänderungen

• Veraltete APIs – Mit NGINX Plus R13 (veröffentlicht im August 2017) wurde die völlig neue NGINX Plus API<.htmlspan> zur Erfassung von Metriken und dynamischen Neukonfiguration von Upstream-Gruppen eingeführt. Sie ersetzte die Status- und Upstream-Conf-APIs, die diese Funktionen zuvor bereitstellten. Wie seinerzeit angekündigt, blieben die veralteten APIs noch über einen längeren Zeitraum verfügbar und wurden weiterhin unterstützt. Dieser Zeitraum endete mit NGINX Plus R16. Wenn Ihre Konfiguration die Direktiven status oder upstream_conf enthält, müssen Sie diese im Rahmen des Upgrades auf R20 durch die Direktive api ersetzen. Hinweise und Unterstützung bei der Migration zur neuen NGINX Plus API finden Sie im Migrationsleitfaden in unserem Blog. Alternativ können Sie sich an unser Supportteam wenden.
• Neue unterstützte Betriebssysteme –
  • CentOS 8.0+
  • FreeBSD 12.1
  • Red Hat Enterprise Linux 8.1
  • Ubuntu 19.10 („Eoan Ermine“)

Weitere Informationen zu unterstützten Plattformen finden Sie in den technischen Spezifikationen für NGINX Plus und dynamische Module.

Neue Funktionen im Detail

Echtzeitüberwachung und -protokollierung von ratenbegrenztem Datenverkehr

NGINX Plus R20 führt Funktionen ein, die es Operations- und DevOps-Teams erleichtern, die Ratenbegrenzungsaktivitäten in Echtzeit zu überwachen und genau zu ermitteln, welche Clients das Ratenlimit überschritten haben.
NGINX Plus bietet seit jeher ein hohes Maß an Flexibilität bei der Definition der Arten von Clientanfragen, die einer Ratenbegrenzung unterliegen sollen, und bei der Verarbeitung übermäßiger Anfragen. Jede Anfrage wird auf eine der folgenden Arten verarbeitet:

• Weitergeleitet ohne Verzögerung (weil die Anfragerate unter dem Grenzwert oder innerhalb der konfigurierten Burst-Größe liegt)
• Verzögert weitergeleitet, bis dadurch das Ratenlimit nicht mehr überschritten wird (auch als Drosselung bezeichnet)
• Abgelehnt mit einem HTTP-Fehlerstatuscode

In früheren Versionen war das Fehlerprotokoll die einzige Stelle, an der NGINX Plus in standardisierten Einträgen wie diesem festhielt, dass Anfragen verzögert oder abgelehnt wurden:

2019/12/02 11:42:12 [error] 57#57: *339 limiting requests, excess: 0.600 by zone "my_limit", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.0", host: "www.example.com:80"

Das Extrahieren nützlicher Informationen aus dem Fehlerprotokoll kann schwierig sein, da das Nachrichtenformat unstrukturiert und nicht konfigurierbar ist. Wenn die Ratenbegrenzung zudem auf einem anderen Nachrichtenmerkmal als den im Fehlerprotokolleintrag aufgeführten basiert – beispielsweise auf HTTP-Headern oder Identitätsinformationen –, müssen Sie den entsprechenden Eintrag im Zugriffsprotokoll finden, um genau zu ermitteln, welcher Client die Ratenbegrenzung überschritten hat. Die neuen Funktionen lösen diese Probleme.

Metriken zur Anfrageratenbegrenzung aus der NGINX Plus API

Ein neuer Endpunkt der NGINX Plus-API, /api/version/http/limit_reqs, führt für jede Zone, die durch eine limit_req_zone-Direktive definiert ist, Zähler für alle Ergebnisse von Entscheidungen zur Anforderungsbegrenzung. Diese Zähler können sowohl zur Echtzeitüberwachung solcher Entscheidungen verwendet als auch in APM-Lösungen integriert werden, um Dashboards und Warnmeldungen zu Aktivitäten im Zusammenhang mit der Anforderungsbegrenzung bereitzustellen.

Im folgenden Beispiel ist eine Zone definiert: „my_limit“.

$ curl http://localhost/api/6/http/limit_reqs
{
 "my_limit": {
   "delayed": 540,
   "delayed_dry_run": 12162,
   "passed": 804541,
   "rejected": 63,
   "rejected_dry_run": 1209
 }
}

Beachten Sie, dass diese Zähler auch Einträge für übermäßig viele Anfragen enthalten, die im Probelaufmodus verarbeitet wurden, der mit NGINX Plus R19 eingeführt wurde.

Protokollieren von Ratenbegrenzungsaktivitäten im Zugriffsprotokoll

Echtzeitmetriken sind sehr hilfreich, um zu verstehen, wann NGINX Plus übermäßig viele Anfragen verarbeitet. Sie geben jedoch keinen Aufschluss darüber, wer diese Anfragen erzeugt. Um dieses Problem zu lösen, stellt NGINX Plus R20 eine neue Variable namens $limit_req_status bereit. Sie erfasst den Status der Anfrageratenbegrenzung: DELAYED, DELAYED_DRY_RUN, PASSED, REJECTED oder REJECTED_DRY_RUN.

Anschließend können Sie weitere Variablen in das Protokollformat aufnehmen, die den Client, den URI und alle anderen relevanten Informationen eindeutig identifizieren. In der folgenden Konfiguration wird für jeden Client auf Grundlage der Validierung eines JSON Web Tokens (JWT) ein striktes Ratenlimit von 10 Anfragen pro Sekunde durchgesetzt (Zeile 1). Überzählige Anfragen werden abgelehnt (Zeile 16) und in einer separaten Protokolldatei protokolliert (Zeile 21), die außerdem die Variable $jwt_claim_sub enthält, um den sub-Claim zu erfassen (Zeile 4).

Codebeispiel wird geladen…

Beispieleinträge in der Datei „reject.log“:

time=1575289305.350 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTEDtime=1575289305.395 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED
time=1575289305.402 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED

Verbesserungen bei der Verbindungsbegrenzung

Zusätzlich zur Ratenbegrenzung für Anfragen unterstützt NGINX Plus mit dem Modul zur Begrenzung von Verbindungen auch die Begrenzung von Clientverbindungen. Sie können festlegen, wie viele separate Verbindungen ein Client zu NGINX Plus öffnen kann (bzw. wie viele gleichzeitige Anfragen bei Verwendung von HTTP/2 zulässig sind). Ein Client wird in der Regel anhand seiner Remote-IP-Adresse identifiziert (über die Variable $remote_addr oder $binary_remote_addr). Wenn die Remote-IP-Adresse jedoch nicht eindeutig ist oder möglicherweise von mehreren Clients gemeinsam genutzt wird, können Sie eine andere Variable verwenden (z. B. $jwt_claim_sub für den Benutzernamen in einem JWT).

NGINX Plus R20 erweitert die Verbindungsbegrenzung um dieselben Verbesserungen, die für die Anfrageratenbegrenzung in NGINX Plus R19 und in dieser Version eingeführt wurden:

• Testlaufmodus mit der limit_conn_dry_run-Direktive
• Echtzeitüberwachung am NGINX Plus-API-Endpunkt /api/version/http/limit_conns
• Eine neue Variable, $limit_conn_status, die für jede Anfrage die Entscheidung zur Verbindungsbegrenzung erfasst (PASSED, REJECTED oder REJECTED_DRY_RUN) und wie unter „Protokollieren von Aktivitäten zur Anfrageratenbegrenzung im Zugriffsprotokoll“ für die Variable $limit_req_status beschrieben verwendet werden kann

Die folgende Konfiguration begrenzt die Bandbreite für Clients, die mehr als zehn gleichzeitige Verbindungen öffnen.

Codebeispiel wird geladen…

Präfixabgleich im Schlüssel-Wert-Speicher

Mit dem In-Memory-Schlüssel-Wert-Speicher für NGINX Plus können Sie die NGINX Plus API verwenden, um die Datenverkehrssteuerung anhand von Attributen der Anfrage dynamisch zu konfigurieren. Beispiele für Anwendungsfälle sind die dynamische Sperrung von IP-Adressen, die dynamische Bandbreitenbegrenzung und das Zwischenspeichern von Authentifizierungstoken.

NGINX Plus R20 unterstützt nun den Abgleich von Schlüsseln mit einem angegebenen Präfix (Zeichen am Anfang einer Zeichenfolge) und eröffnet damit neue Einsatzmöglichkeiten für den Schlüssel-Wert-Speicher. Da sich Schlüssel beispielsweise mit URI-Präfixen (Basispfaden) statt mit exakten URIs abgleichen lassen, können Sie eine dynamische Routingtabelle erstellen, die jeden Basispfad einer Upstream-Gruppe zuordnet und die durch location-Direktiven definierten statischen Zuordnungen ersetzt oder ergänzt.

Um den Präfixabgleich zu aktivieren, fügen Sie der Direktive type=prefix den neuen Parameter keyval_zone hinzu. In der folgenden Konfiguration ordnet die Direktive keyval jedem URI-Präfix eine Cache-Control-Direktive (z. B. max-age oder no-cache) zu, und die Direktive add_header setzt den Cache-Control-Antwortheader auf diesen Wert, während NGINX Plus die Anfrage an den Upstream-Server weiterleitet.

Codebeispiel wird geladen…

Wir verwenden die NGINX Plus API, um den Wert des Cache-Control-Antwortheaders für jeden Basispfad (in diesem Fall Pfade, die mit /images/ oder /reports/ beginnen) im Schlüssel-Wert-Speicher zu definieren:

$ curl -i -X POST --data '{"/images/":"max-age=3600", "/reports/":"no-cache"}' http://localhost:8080/api/6/http/keyvals/pathsHTTP/1.1 201 Created
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:36:31 GMT
Content-Length: 0
Location: http://localhost:8080/api/6/http/keyvals/paths/
Connection: keep-alive

Wenn wir eine Anfrage mit einem Basispfad stellen, der im Schlüssel-Wert-Speicher vorhanden ist, enthält die Antwort den von uns festgelegten Cache-Control-Header:

$ curl -I http://localhost/images/sample.jpgHTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:27:39 GMT
Content-Type: image/jpeg
Content-Length: 120847
Connection: keep-alive
Cache-Control: max-age=3600

Da der Schlüssel-Wert-Speicher über einen Cluster von NGINX Plus-Instanzen hinweg synchronisiert werden kann, müssen Sie jeden API-Aufruf nur an eine einzige Instanz richten. Dadurch lassen sich Änderungen an der Clusterkonfiguration wesentlich einfacher automatisieren als Änderungen an Konfigurationsdateien zu koordinieren.

DNS-Auflösung pro Upstream-Gruppe

Wenn Sie NGINX Plus für den Lastenausgleich zwischen mehreren Upstream-Servern verwenden, können Sie die Mitglieder der Upstream-Gruppe definieren, indem Sie einen Hostnamen angeben, der in mehrere IP-Adressen aufgelöst wird. Dies ist besonders in dynamischen oder automatisch skalierenden Umgebungen nützlich, in denen sich die Mitglieder der Upstream-Gruppe häufig ändern können.

Um die Konfiguration dieser dynamischen Upstream-Gruppen abzuschließen, fügen Sie außerdem die resolver-Direktive hinzu, um den oder die DNS-Server festzulegen, die NGINX Plus nach den mit dem Hostnamen verknüpften IP-Adressen abfragt. In früheren Versionen galt eine resolver-Direktive für alle Upstream-Gruppen, auf die durch proxy_pass-Direktiven in dem Kontext (http, server oder location) verwiesen wurde, der die Direktive enthielt. Mit NGINX Plus R20 können Sie nun für jede Upstream-Gruppe einen anderen DNS-Resolver angeben.

Die neue Flexibilität ist besonders in einer DevOps-Umgebung von Vorteil: Anwendungsteams können damit einen größeren Teil ihrer Infrastruktur für die Anwendungsbereitstellung selbst verwalten, einschließlich der DNS-Server und Dienstregistrierungen, anstatt auf zentralisierte, gemeinsam genutzte Dienste angewiesen zu sein.

Sie können weiterhin einen globalen Resolver im übergeordneten http-Kontext sowie in server- und location-Blöcken definieren. Wenn ein upstream-Block keine resolver-Direktive enthält, übernimmt er wie in früheren Versionen die resolver-Einstellung des Kontexts oder Blocks, der eine auf die Upstream-Gruppe verweisende proxy_pass-Direktive enthält.

Im folgenden Beispiel verwendet die Upstream-Gruppe website den globalen Resolver, während mobile_app einen eigenen Resolver verwendet:

Codebeispiel wird geladen…

Beachten Sie, dass wir den Parameter „status_zone“ (eingeführt in NGINX Plus R19) in beide resolver-Direktiven aufnehmen, um Fehler- und andere Metriken zur Resolver-Aktivität zu erfassen.

Variablen für PROXY-Protocol-Servermetadaten

Das PROXY-Protokoll ist ein Mechanismus, mit dem ein Layer-4-Proxy Informationen über die ursprüngliche Clientverbindung an den nächsten Proxy oder Load Balancer übermitteln kann, der die Clientanfrage verarbeitet. Dies ist besonders wichtig für Anwendungsfälle, in denen Sie die IP-Adresse des Clients kennen müssen – beispielsweise um die Anzahl der von jedem Client hergestellten Verbindungen zu begrenzen (mit der least_conn-Direktive) oder einfach um die tatsächliche IP-Adresse des Clients zu protokollieren. Wie bereits in früheren Versionen erfasst die Variable $proxy_protocol_addr diese Informationen.

Wenn in einer Anwendungsumgebung mehrere Layer-4-Proxys eingesetzt werden, ist es mitunter wichtig, dass NGINX Plus auch die IP-Adresse und den Port des Proxyservers kennt, mit dem der Client ursprünglich verbunden war. Die Metadaten des PROXY-Protokolls enthalten diese Informationen, und NGINX Plus R20 führt Variablen ein, mit denen sie erfasst werden können:

• $proxy_protocol_server_addr
• $proxy_protocol_server_port

Die Variablen sind sowohl für die HTTP- als auch für die Stream-Module (TCP/UDP) verfügbar und unterstützen die Versionen 1 und 2 des PROXY-Protokolls. Beachten Sie, dass Sie NGINX Plus vor der Verwendung der Variablen ausdrücklich für die Verarbeitung des PROXY-Protokolls aktivieren müssen, indem Sie der proxy_protocol-Direktive den Parameter listen hinzufügen.

Sicherheitsverbesserungen für HTTP/2

NGINX Plus R18 P1 hat drei Sicherheitslücken in HTTP/2 behoben, die im August bekannt gegeben wurden. NGINX Plus R20 enthält zusätzliche Änderungen, die die allgemeine Sicherheit unserer HTTP/2-Implementierung verbessern:

• Verbesserte Erkennung von fehlerhaftem oder ungültigem Clientverhalten
• Verbesserter Versand von HTTP/2-Fehlerantworten, bevor der Text der Clientanfrage gelesen wurde
• Verbesserte Robustheit der worker_shutdown_timeout-Direktive bei langlebigen HTTP/2-Verbindungen
• Verbesserte Robustheit der Direktive „proxy_request_buffering“ für HTTP/2-Clients

Wenn Sie HTTP/2 in einer Produktionsumgebung mit NGINX Plus R18 (ohne Patch) oder einer früheren Version verwenden, empfehlen wir Ihnen, so bald wie möglich ein Upgrade auf NGINX Plus R20 durchzuführen.

Aktualisierungen im NGINX Plus-Ökosystem

NGINX-JavaScript-Modul

Das NGINX-JavaScript-Modul (njs) wurde auf Version 0.3.7 aktualisiert und unterstützt nun weitere JavaScript-Objekte:

• Function()-Konstruktor
• Object.assign()-Methode
• Number-Methoden: toFixed(), toPrecision() und toExponential()
• Array.prototype.copyWithin()-Methode
• Label-Parameter der Methode „console.time()“

Weitere Informationen zu njs finden Sie auf der Projekt-Homepage und in unserem Blog<.htmla>.

NGINX Plus upgraden oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R20 durchzuführen. Dadurch erhalten Sie außerdem eine Reihe zusätzlicher Fehlerbehebungen und Verbesserungen, und NGINX kann Sie besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen.

Bitte lesen Sie sich die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen sorgfältig durch, bevor Sie mit dem Upgrade fortfahren.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es selbst zu testen – für Sicherheit, Lastverteilung und als API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion. Überzeugen Sie sich selbst davon, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.

Über den Autor

Liam CrillySenior Director, Produktmanagement

Weitere Blogbeiträge von Liam Crilly