Annonce de la version 5 de NGINX Plus

Nous sommes très heureux d’annoncer la disponibilité de NGINX Plus Release 5 (R5). Cette version rassemble les fonctionnalités récemment publiées dans la distribution NGINX Open Source et un certain nombre de fonctionnalités disponibles uniquement dans NGINX Plus.

La principale nouveauté est l’équilibrage de charge pour les protocoles généraux basés sur TCP , tels que les protocoles de base de données, RPC et de chat. L'article de blog associé à l'équilibrage de charge TCP dans NGINX Plus R5 fournit des détails complets.

NGINX Plus R5 inclut également un certain nombre d’améliorations de l’équilibrage de charge et de la mise en cache.

Envisagez NGINX Plus si vous recherchez une solution d’accélération Web, d’équilibrage de charge ou de distribution d’applications, ou un serveur Web entièrement pris en charge avec des API de surveillance et de gestion supplémentaires.

Équilibrage de charge TCP

NGINX Plus R5 introduit l'équilibrage de charge pour les connexions TCP, implémenté dans le module de flux . Vous pouvez équilibrer la charge d'une large gamme de connexions non HTTP, telles que MySQL et SSL/TLS (sans déchiffrement). Vous pouvez même équilibrer la charge et gérer les protocoles de messagerie (SMTP, POP3, IMAP) en combinant le module proxy de messagerie existant avec le nouveau module de flux .

Cette version fournit une gamme de méthodes d'équilibrage de charge (Round Robin, Least Connections, Hash, IP Hash), un contrôle des paramètres de connexion, une haute disponibilité avec des contrôles d'intégrité en ligne, un démarrage lent pour les serveurs récupérés et la possibilité de désigner manuellement les serveurs comme actifs, de sauvegarde ou hors service.

Pour plus d’informations, consultez l’équilibrage de charge TCP dans NGINX Plus R5 sur notre blog et l’équilibrage de charge TCP dans le guide d’administration NGINX Plus. Cette fonctionnalité est unique à NGINX Plus.

Meilleur contrôle des sessions utilisateur à charge équilibrée

Parfois, vous devez désactiver un nœud en amont pour des raisons de maintenance ou de mise à niveau. Avec la nouvelle fonctionnalité de drainage de session de la version 5, vous pouvez signaler à NGINX Plus de ne pas envoyer de nouvelles connexions à ce nœud, mais de conserver les sessions établies sur celui-ci jusqu'à ce qu'elles se terminent.

Vous pouvez utiliser la surveillance des activités en direct pour surveiller le trafic sur le nœud drainé, en attendant de le mettre hors ligne jusqu'à ce que vous soyez sûr que les sessions utilisateur sont terminées :

# Renvoie l'heure d'époque Unix en secondes (arrondie à la milliseconde) lorsque # Le serveur 1 du groupe en amont 'backends' a été utilisé pour la dernière fois $ curl http://localhost:8080/status/upstreams/backends/1/selected # Calcule la durée d'inactivité du serveur (en millisecondes) $ expr `date +%s000` - `curl -s http://localhost:8080/status/upstreams/backends/1/selected`

[Éditeur – Les commandes précédentes utilisent le module NGINX Plus Status (activé par la directive status ). Ce module est remplacé et obsolète par l' API NGINX Plus dans NGINX Plus Release 13 (R13) et versions ultérieures, et ne sera plus disponible après NGINX Plus R15.]

Le mécanisme de cookie collant pour le suivi des sessions utilisateur a été mis à jour afin que le délai d'expiration s'applique à la demande la plus récente de la session, et non à la première demande. Cela signifie que les sessions sont suivies avec plus de précision.

Les fonctionnalités de drainage de session et de cookie collant ne sont disponibles que dans NGINX Plus.

Contrôle amélioré du trafic en cas de défaillance d'un nœud

Lorsqu'un serveur d'un groupe en amont ne répond pas à une demande, NGINX Plus réessaye automatiquement la demande sur d'autres serveurs du groupe. Les nouvelles directives proxy_next_upstream_tries et proxy_next_upstream_timeout vous donnent plus de contrôle sur ce comportement, en limitant respectivement le nombre de tentatives et la durée pendant laquelle NGINX peut continuer à réessayer.

Cette fonctionnalité a été publiée dans NGINX 1.7.5 et s'applique au proxy du trafic HTTP, FastCGI, uWSGI, SCGI et memcached.

L'en-tête HTTP Vary est pris en charge pour le contenu mis en cache

Certains serveurs Web fournissent différentes versions d’une ressource en fonction du type de client qui la demande. Par exemple, lorsqu’un navigateur demande la page d’accueil d’un site Web, le serveur fournit une version avec des images haute résolution, mais il fournit une version sans images lorsque le client est un appareil mobile. Un tel serveur peut définir l'en-tête Vary dans ses réponses pour indiquer aux proxys de mise en cache quels en-têtes de la demande client il utilise pour déterminer la version à envoyer (et par implication, quels en-têtes le proxy doit utiliser pour déterminer quelle version d'une ressource mise en cache envoyer).

Un cas d'utilisation courant consiste à différencier les versions compressées et non compressées de la même ressource ; dans ce cas, la variable : Accepter-Encodage L'en-tête de la réponse du serveur indique au cache d'utiliser la valeur de Accepter-Encodage en-tête dans la requête du client pour déterminer quelle version livrer.

NGINX Plus prend désormais entièrement en charge l'en-tête Vary pour mettre en cache correctement plusieurs variantes de la même ressource. Cette fonctionnalité a été introduite dans NGINX 1.7.7.

Prise en charge améliorée de la diffusion de plages d'octets à partir du cache

Un client peut récupérer une certaine partie d’un fichier – par exemple, un segment dans un téléchargement vidéo ou une page dans un document PDF – en spécifiant la plage d’octets appropriée dans sa demande. NGINX Plus peut répondre à ces demandes et fournir des plages d’octets à partir des ressources mises en cache aux clients, même si le serveur d’origine du contenu ne prend pas en charge les plages d’octets.

La première fois que NGINX Plus reçoit une demande pour un fichier (le fichier complet ou une plage d'octets), il demande le fichier entier au serveur d'origine et le met en cache. NGINX Plus satisfait ensuite les demandes de plage d’octets à partir du cache. Cela réduit la charge sur les serveurs en amont (d'origine).

Cette fonctionnalité a été introduite dans NGINX 1.7.7 et est activée avec la directive proxy_force_ranges .

Plus de contrôle sur la bande passante en amont

La nouvelle directive proxy_limit_rate limite la vitesse à laquelle NGINX Plus lit les données à partir d'un serveur en amont. Cela empêche une requête volumineuse de consommer toute la bande passante entre NGINX et le serveur d'origine. Lorsque la mise en cache est activée, elle contrôle efficacement la vitesse à laquelle le contenu est écrit dans le cache du disque, ce qui est utile si les disques présentent une latence élevée pour les écritures.

Cette directive a été introduite dans NGINX 1.7.7.

Autres changements dans NGINX Plus R5

Le module RTMP tiers a été ajouté au package NGINX Plus Extras .

NGINX Plus est désormais disponible pour Ubuntu 14.10, pour ARMv8 (aarch64) sur Ubuntu 14.04 et pour SUSE Linux Enterprise Server 12.

Mettre à niveau ou essayer NGINX Plus

Nous encourageons vivement nos clients NGINX Plus à mettre à jour vers la version 5 dès que possible. Vous bénéficierez d'un certain nombre de correctifs et d'améliorations, et cela nous aidera à vous aider si vous devez ouvrir un ticket d'assistance. Les instructions d'installation et de mise à niveau sont disponibles sur le portail client .

Si vous n'avez pas essayé NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui et découvrez comment NGINX Plus peut vous aider à développer et à diffuser vos applications.