Ankündigung von NGINX Plus Release 5

Wir freuen uns sehr, die Verfügbarkeit von NGINX Plus Release 5 (R5) bekannt zu geben. Diese Version vereint die kürzlich in der Open-Source-Distribution NGINX veröffentlichten Funktionen und eine Reihe von Funktionen, die nur in NGINX Plus verfügbar sind.

Die wichtigste neue Funktion ist der Lastenausgleich für allgemeine TCP-basierte Protokolle wie Datenbank-, RPC- und Chat-Protokolle. Der zugehörige Blogbeitrag „TCP Load Balancing in NGINX Plus R5“ enthält umfassende Einzelheiten.

NGINX Plus R5 enthält außerdem zahlreiche Verbesserungen beim Lastenausgleich und Caching.

Ziehen Sie NGINX Plus in Betracht, wenn Sie nach einer Lösung zur Webbeschleunigung, zum Lastausgleich oder zur Anwendungsbereitstellung oder einem vollständig unterstützten Webserver mit zusätzlichen Überwachungs- und Verwaltungs- APIs suchen.

TCP-Lastausgleich

NGINX Plus R5 führt Lastausgleich für TCP-Verbindungen ein, implementiert im Stream -Modul. Sie können eine breite Palette von Nicht-HTTP-Verbindungen wie MySQL und SSL/TLS (ohne Entschlüsselung) ausgleichen. Sie können sogar die Last ausgleichen und E-Mail-Protokolle (SMTP, POP3, IMAP) verwalten, indem Sie das vorhandene Mail- Proxy-Modul mit dem neuen Stream- Modul kombinieren.

Diese Version bietet verschiedene Methoden zum Lastenausgleich (Round Robin, Least Connections, Hash, IP-Hash), Kontrolle über Verbindungsparameter, hohe Verfügbarkeit mit Inline-Integritätsprüfungen, langsamen Start für wiederhergestellte Server und die Möglichkeit, Server manuell als aktiv, Backup oder ausgefallen zu kennzeichnen.

Weitere Informationen finden Sie unter TCP Load Balancing in NGINX Plus R5 in unserem Blog und unter TCP Load Balancing im NGINX Plus Admin Guide. Diese Funktion ist einzigartig für NGINX Plus.

Bessere Kontrolle über Benutzersitzungen mit Lastenausgleich

Manchmal müssen Sie einen Upstream-Knoten zur Wartung oder Aktualisierung herunterfahren. Mit der neuen Funktion zum Session-Draining in Release 5 können Sie NGINX Plus signalisieren, keine neuen Verbindungen an diesen Knoten zu senden, sondern bestehende Sitzungen darauf aufrechtzuerhalten, bis sie abgeschlossen sind.

Mithilfe der Live-Aktivitätsüberwachung können Sie den Datenverkehr auf dem entleerten Knoten überwachen und mit der Offline-Schaltung warten, bis Sie sicher sind, dass die Benutzersitzungen abgeschlossen sind:

# Gibt die Unix-Epochenzeit in Sekunden (auf Millisekunden gerundet) zurück, als # Server 1 in der Upstream-Gruppe „Backends“ zuletzt verwendet wurde. $ curl http://localhost:8080/status/upstreams/backends/1/selected # Berechnen Sie, wie lange der Server im Leerlauf war (in Millisekunden). $ expr „date +%s000“ – „curl -s http://localhost:8080/status/upstreams/backends/1/selected“

[Editor – Die vorhergehenden Befehle verwenden das NGINX Plus-Statusmodul (aktiviert durch die Statusdirektive ). Dieses Modul wird durch die NGINX Plus-API in NGINX Plus Release 13 (R13) und höher ersetzt und verworfen und wird nach NGINX Plus R15 nicht mehr verfügbar sein.]

Der Sticky-Cookie -Mechanismus zum Verfolgen von Benutzersitzungen wurde aktualisiert, sodass die Ablaufzeit für die letzte Anfrage in der Sitzung gilt und nicht für die erste Anfrage. Dies bedeutet, dass Sitzungen genauer verfolgt werden.

Die Funktionen zum Session-Draining und Sticky-Cookie sind nur in NGINX Plus verfügbar.

Verbesserte Kontrolle des Datenverkehrs bei Knotenausfall

Wenn ein Server in einer Upstream-Gruppe nicht auf eine Anfrage antwortet, versucht NGINX Plus die Anfrage automatisch erneut auf anderen Servern in der Gruppe. Die neuen Anweisungen proxy_next_upstream_tries und proxy_next_upstream_timeout geben Ihnen mehr Kontrolle über dieses Verhalten, indem sie die Anzahl der Wiederholungsversuche bzw. die Dauer der Wiederholungsversuche durch NGINX begrenzen.

Diese Funktion wurde in 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 Art des anfordernden Clients unterschiedliche Versionen einer Ressource. Wenn ein Browser beispielsweise die Homepage einer Website anfordert, liefert der Server eine Version mit hochauflösenden Bildern. Handelt es sich beim Client jedoch um ein mobiles Gerät, liefert er eine Version ohne Bilder. Ein solcher Server kann den Vary -Header in seinen Antworten festlegen, um Caching-Proxys mitzuteilen, welche Header in der Client-Anforderung er verwendet, um die zu sendende Version zu bestimmen (und implizit, welche Header der Proxy verwenden muss, um zu bestimmen, welche Version einer zwischengespeicherten Ressource gesendet werden soll).

Ein häufiger Anwendungsfall ist die Unterscheidung zwischen komprimierten und unkomprimierten Versionen derselben Ressource. In diesem Fall lautet das Vary: Der Accept-Encoding- Header in der Serverantwort weist den Cache an, den Wert des Accept-Encoding- Headers in der Clientanforderung zu verwenden, um zu bestimmen, welche Version bereitgestellt werden soll.

NGINX Plus unterstützt jetzt vollständig den Vary- Header, um mehrere Varianten derselben Ressource korrekt zwischenzuspeichern. Diese Funktion wurde in 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 diesen Anfragen nachkommen und Bytebereiche aus zwischengespeicherten Assets an Clients bereitstellen, selbst wenn der Ursprungsserver für den Inhalt keine Bytebereiche unterstützt.

Wenn NGINX Plus zum ersten Mal eine Anforderung für eine Datei erhält (entweder die vollständige Datei oder ein Bytebereich), fordert es die gesamte Datei vom Ursprungsserver an und speichert sie im Cache. NGINX Plus erfüllt dann Byte-Range-Anfragen aus dem Cache. Dadurch wird die Belastung der Upstream-Server (Ursprungsserver) reduziert.

Diese Funktion wurde in NGINX 1.7.7 eingeführt und mit der Direktive proxy_force_ranges aktiviert.

Mehr Kontrolle über die Upstream-Bandbreite

Die neue Direktive „proxy_limit_rate“ begrenzt, wie schnell NGINX Plus Daten von einem Upstream-Server liest. Dadurch wird verhindert, dass eine große Anfrage die gesamte Bandbreite zwischen NGINX und dem Ursprungsserver verbraucht. Wenn die Zwischenspeicherung aktiviert ist, wird dadurch effektiv die Geschwindigkeit gesteuert, mit der Inhalte in den Festplattencache geschrieben werden. Dies ist nützlich, wenn die Festplatten eine hohe Latenz beim Schreiben aufweisen.

Diese Anweisung wurde in NGINX 1.7.7 eingeführt.

Weitere Änderungen in NGINX Plus R5

Das Drittanbieter- RTMP-Modul wurde dem NGINX Plus Extras -Paket hinzugefügt.

NGINX Plus ist jetzt für Ubuntu 14.10, für ARMv8 (aarch64) auf Ubuntu 14.04 und für SUSE Linux Enterprise Server 12 verfügbar.

Upgrade durchführen oder NGINX Plus testen

Wir empfehlen unseren NGINX Plus-Kunden dringend, so bald wie möglich auf Release 5 zu aktualisieren. Sie erhalten eine Reihe von Fehlerbehebungen und Verbesserungen und können Ihnen so leichter helfen, wenn Sie ein Support-Ticket erstellen müssen. Installations- und Upgrade-Anweisungen 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 Sie mit NGINX Plus Ihre Anwendungen skalieren und bereitstellen können.