Wir freuen uns sehr, die Verfügbarkeit von NGINX Plus Release 5 (R5) bekannt zu geben. Dieses Release vereint die kürzlich in der NGINX Open Source-Distribution veröffentlichten Funktionen mit einer Reihe von Funktionen, die ausschließlich in NGINX Plus verfügbar sind.
Die wichtigste neue Funktion ist der Lastenausgleich für allgemeine TCP-basierte Protokolle, beispielsweise für Datenbank-, RPC- und Chatprotokolle. Der zugehörige Blogbeitrag TCP-Lastenausgleich in NGINX Plus R5 enthält alle Einzelheiten.
NGINX Plus R5 enthält außerdem eine Reihe von Verbesserungen beim Lastenausgleich und Caching.
Ziehen Sie NGINX Plus in Betracht, wenn Sie eine Lösung für Webbeschleunigung, Lastverteilung oder Anwendungsbereitstellung oder einen vollständig unterstützten Webserver mit zusätzlichen APIs für Überwachung und Verwaltung suchen.
TCP-Lastverteilung
NGINX Plus R5 führt den Lastenausgleich für TCP-Verbindungen ein, der im stream-Modul implementiert ist. Sie können den Lastenausgleich für eine Vielzahl von Nicht-HTTP-Verbindungen durchführen, beispielsweise für MySQL und SSL/TLS (ohne Entschlüsselung). Durch die Kombination des vorhandenen mail-Proxy-Moduls mit dem neuen stream-Modul können Sie sogar E-Mail-Protokolle (SMTP, POP3, IMAP) per Lastenausgleich verteilen und verwalten.
Diese Version bietet verschiedene Lastverteilungsverfahren (Round Robin, Least Connections, Hash, IP-Hash), die Steuerung von Verbindungsparametern, Hochverfügbarkeit mit integrierten Zustandsprüfungen, einen langsamen Start für wiederhergestellte Server sowie die Möglichkeit, Server manuell als aktiv, Backup oder nicht verfügbar festzulegen.
Weitere Informationen finden Sie in unserem Blogbeitrag „TCP-Lastverteilung in NGINX Plus R5“ sowie unter „TCP-Lastverteilung“ im NGINX Plus-Administratorhandbuch. Diese Funktion ist ausschließlich in NGINX Plus verfügbar.
Bessere Kontrolle über Sitzungen mit Lastverteilung
Manchmal müssen Sie einen Upstream-Knoten zu Wartungs- oder Upgradezwecken außer Betrieb nehmen. Mit der neuen Funktion Session-Draining in Release 5 können Sie NGINX Plus anweisen, keine neuen Verbindungen an diesen Knoten zu senden, bestehende Sitzungen darauf jedoch bis zu ihrem Abschluss aufrechtzuerhalten.
Sie können die Live-Aktivitätsüberwachung verwenden, um den Datenverkehr auf dem aus dem Betrieb genommenen Knoten zu überwachen. Nehmen Sie ihn erst dann offline, wenn Sie sicher sind, dass die Benutzersitzungen beendet wurden:
# Return the Unix epoch time in seconds (rounded to milliseconds) when # Server 1 in upstream group 'backends' was last used
$ curl http://localhost:8080/status/upstreams/backends/1/selected
# Calculate how long the server has been idle (in milliseconds)
$ expr `date +%s000` - `curl -s http://localhost:8080/status/upstreams/backends/1/selected`[Redaktion – Die vorangehenden Befehle verwenden das NGINX Plus-Statusmodul (aktiviert durch die status-Direktive). Dieses Modul wurde ab NGINX Plus API in NGINX Plus Release 13 (R13) ersetzt und als veraltet eingestuft und ist nach NGINX Plus R15 nicht mehr verfügbar.]
Der Sticky-Cookie-Mechanismus zur Nachverfolgung von Benutzersitzungen wurde so aktualisiert, dass die Ablaufzeit für die jeweils letzte Anfrage der Sitzung gilt und nicht für die erste. Dadurch können Sitzungen genauer nachverfolgt werden.
Die Funktionen zum kontrollierten Beenden von Sitzungen und für Sticky Cookies sind nur in NGINX Plus verfügbar.
Verbesserte Steuerung des Datenverkehrs bei Ausfall eines Knotens
Wenn ein Server in einer Upstream-Gruppe nicht auf eine Anfrage antwortet, wiederholt NGINX Plus die Anfrage automatisch auf anderen Servern in der Gruppe. Mit den neuen Direktiven „proxy_next_upstream_tries“ und „proxy_next_upstream_timeout“ können Sie dieses Verhalten besser steuern, indem Sie die Anzahl der Wiederholungsversuche beziehungsweise die Dauer begrenzen, über die NGINX weitere Versuche unternehmen kann.
Diese Funktion wurde mit NGINX 1.7.5 veröffentlicht und gilt für das Proxying von HTTP-, FastCGI-, uWSGI-, SCGI- und memcached-Datenverkehr.
HTTP-Vary-Header wird für zwischengespeicherte Inhalte unterstützt
Einige Webserver liefern je nach Typ des anfragenden Clients unterschiedliche Versionen einer Ressource aus. Wenn beispielsweise ein Browser die Startseite einer Website anfordert, liefert der Server eine Version mit hochauflösenden Bildern aus, während er für ein Mobilgerät eine Version ohne Bilder bereitstellt. Ein solcher Server kann in seinen Antworten den Vary-Header setzen, um Caching-Proxys mitzuteilen, anhand welcher Header in der Clientanfrage er die auszuliefernde Version bestimmt (und damit auch, welche Header der Proxy berücksichtigen muss, um zu entscheiden, welche Version einer zwischengespeicherten Ressource ausgeliefert werden soll).
Ein häufiger Anwendungsfall ist die Unterscheidung zwischen komprimierten und unkomprimierten Versionen derselben Ressource. In diesem Fall weist der Vary:-Header Accept-Encoding in der Serverantwort den Cache an, anhand des Werts des Accept-Encoding-Headers in der Clientanfrage zu bestimmen, welche Version ausgeliefert werden soll.
NGINX Plus unterstützt jetzt vollständig den Vary-Header, um mehrere Varianten derselben Ressource korrekt zwischenzuspeichern. Diese Funktion wurde mit NGINX 1.7.7 eingeführt.
Verbesserte Unterstützung für die Bereitstellung von Bytebereichen aus dem Cache
Ein Client kann einen bestimmten Teil einer Datei abrufen – beispielsweise ein Segment eines Video-Downloads oder eine Seite eines PDF-Dokuments –, indem er in seiner Anfrage den entsprechenden Bytebereich angibt. NGINX Plus kann diese Anfragen erfüllen und Bytebereiche aus zwischengespeicherten Ressourcen an Clients ausliefern, selbst wenn der Ursprungsserver des Inhalts keine Bytebereiche unterstützt.
Wenn NGINX Plus zum ersten Mal eine Anfrage für eine Datei erhält (entweder für die vollständige Datei oder einen Bytebereich), fordert es die gesamte Datei vom Ursprungsserver an und speichert sie im Cache. Anschließend bedient NGINX Plus Anfragen nach Bytebereichen aus dem Cache. Dadurch wird die Last auf den vorgelagerten Ursprungsservern reduziert.
Diese Funktion wurde in NGINX 1.7.7 eingeführt und wird mit der Direktive „proxy_force_ranges“ aktiviert.
Mehr Kontrolle über die Upstream-Bandbreite
Die neue proxy_limit_rate-Direktive begrenzt, wie schnell NGINX Plus Daten von einem Upstream-Server liest. Dadurch wird verhindert, dass eine einzelne große Anfrage die gesamte Bandbreite zwischen NGINX und dem Ursprungsserver beansprucht. Wenn das Caching aktiviert ist, steuert sie effektiv die Geschwindigkeit, mit der Inhalte in den Festplatten-Cache geschrieben werden. Dies ist nützlich, wenn die Datenträger beim Schreiben hohe Latenzen aufweisen.
Diese Direktive wurde in NGINX 1.7.7 eingeführt.
Weitere Änderungen in NGINX Plus R5
Das Drittanbieter-RTMP-Modul wurde dem Paket NGINX Plus Extras hinzugefügt.
NGINX Plus ist jetzt für Ubuntu 14.10, für ARMv8 (aarch64) unter Ubuntu 14.04 und für SUSE Linux Enterprise Server 12 verfügbar.
NGINX Plus aktualisieren oder testen
Wir empfehlen unseren NGINX Plus-Kunden dringend, so bald wie möglich auf Release 5 zu aktualisieren. Dadurch erhalten Sie zahlreiche Fehlerbehebungen und Verbesserungen. Außerdem können wir Ihnen so besser helfen, falls Sie ein Support-Ticket erstellen müssen. Anleitungen zur Installation und zum Upgrade finden Sie im Kundenportal.
Wenn Sie NGINX Plus noch nicht ausprobiert haben, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion und erfahren Sie, wie NGINX Plus Sie bei der Skalierung und Bereitstellung Ihrer Anwendungen unterstützen kann.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.