Nous sommes très heureux d’annoncer la disponibilité de NGINX Plus Release 5 (R5). Cette version réunit les fonctionnalités récemment intégrées à la distribution NGINX Open Source et plusieurs fonctionnalités disponibles uniquement dans NGINX Plus.
La principale nouveauté est l’équilibrage de charge pour les protocoles génériques basés sur TCP, tels que les protocoles de base de données, RPC et de messagerie instantanée. L’article de blog associé, « Équilibrage de charge TCP dans NGINX Plus R5 », fournit tous les détails.
NGINX Plus R5 comprend également plusieurs améliorations en matière de répartition de charge et de mise en cache.
Envisagez NGINX Plus si vous recherchez une solution d’accélération web, d’équilibrage de charge ou de mise à disposition d’applications, ou encore un serveur web entièrement pris en charge avec des API supplémentaires de surveillance et de gestion.
Répartition de charge TCP
NGINX Plus R5 introduit l’équilibrage de charge pour les connexions TCP, mis en œuvre dans le module stream. Vous pouvez équilibrer la charge d’un large éventail 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 mail existant avec le nouveau module stream.
Cette version propose plusieurs méthodes de répartition de charge (Round Robin, Least Connections, Hash, IP Hash), le contrôle des paramètres de connexion, une haute disponibilité grâce à des contrôles d’intégrité intégrés, un démarrage progressif des serveurs rétablis, ainsi que la possibilité de désigner manuellement les serveurs comme actifs, de secours ou hors service.
Pour plus d’informations, consultez l’article « Équilibrage de charge TCP dans NGINX Plus R5 » sur notre blog ainsi que la section « Équilibrage de charge TCP » du guide d’administration de NGINX Plus. Cette fonctionnalité est propre à NGINX Plus.
Meilleur contrôle des sessions utilisateur avec répartition de charge
Il est parfois nécessaire de mettre hors service un nœud en amont pour effectuer une opération de maintenance ou une mise à niveau. Grâce à la nouvelle fonctionnalité de drainage des sessions de la version 5, vous pouvez demander à NGINX Plus de ne plus envoyer de nouvelles connexions à ce nœud, tout en y maintenant les sessions établies jusqu’à leur terme.
Vous pouvez utiliser la surveillance de l’activité en temps réel pour surveiller le trafic sur le nœud en cours de retrait, et attendre d’être certain que les sessions utilisateur sont terminées avant de le mettre hors ligne :
# 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`[Note de l’éditeur – Les commandes précédentes utilisent le module Status de NGINX Plus (activé par la directive « status »). Ce module est remplacé par l’NGINX Plus API et obsolète depuis NGINX Plus Release 13 (R13) et les versions ultérieures. Il ne sera plus disponible après NGINX Plus R15.]
Le mécanisme de cookie persistant utilisé pour suivre les sessions utilisateur a été mis à jour afin que le délai d’expiration s’applique à la requête la plus récente de la session, et non à la première. Les sessions sont ainsi suivies avec davantage de précision.
Les fonctionnalités de drainage des sessions et de cookie persistant sont disponibles uniquement dans NGINX Plus.
Meilleur contrôle du trafic en cas de défaillance d’un nœud
Lorsqu’un serveur d’un groupe en amont ne répond pas à une requête, NGINX Plus relance automatiquement la requête sur d’autres serveurs du groupe. Les nouvelles directives « proxy_next_upstream_tries » et « proxy_next_upstream_timeout » vous permettent de mieux contrôler 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 à la mise en 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 selon le 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 contenant 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 afin d’indiquer aux proxys de mise en cache quels en-têtes de la requête du client il utilise pour déterminer la version à envoyer (et, par conséquent, quels en-têtes le proxy doit utiliser pour déterminer la version d’une ressource mise en cache à envoyer).
Un cas d’utilisation courant consiste à distinguer les versions compressée et non compressée d’une même ressource. Dans ce cas, l’en-tête Vary: Accept-Encoding de la réponse du serveur indique au cache d’utiliser la valeur de l’en-tête Accept-Encoding de la requête du client pour déterminer la version à fournir.
NGINX Plus prend désormais entièrement en charge l’en-tête « Vary » afin de mettre correctement en cache plusieurs variantes d’une 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 depuis le cache
Un client peut récupérer une partie spécifique d’un fichier – par exemple, un segment lors du téléchargement d’une vidéo ou une page d’un document PDF – en indiquant la plage d’octets appropriée dans sa requête. NGINX Plus peut répondre à ces requêtes et fournir aux clients des plages d’octets provenant de ressources mises en cache, 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 requête portant sur un fichier (qu’il s’agisse du fichier complet ou d’une plage d’octets), il demande l’intégralité du fichier au serveur d’origine et le met en cache. NGINX Plus répond ensuite aux requêtes de plages d’octets à partir du cache. Cela réduit la charge sur les serveurs en amont (serveurs d’origine).
Cette fonctionnalité a été introduite dans NGINX 1.7.7 et s’active à l’aide de la directive proxy_force_ranges.
Un meilleur contrôle de la bande passante en amont
La nouvelle directive « proxy_limit_rate » limite la vitesse à laquelle NGINX Plus lit les données provenant d’un serveur en amont. Cela empêche une requête volumineuse de monopoliser toute la bande passante entre NGINX et le serveur d’origine. Lorsque la mise en cache est activée, cette directive contrôle effectivement la vitesse à laquelle le contenu est écrit dans le cache sur disque, ce qui est utile si les disques présentent une latence élevée en écriture.
Cette directive a été introduite dans NGINX 1.7.7.
Autres modifications apportées à 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) sous Ubuntu 14.04 et pour SUSE Linux Enterprise Server 12.
Mettez à niveau ou essayez NGINX Plus
Nous recommandons vivement à nos clients NGINX Plus de passer à la version 5 dès que possible. Vous bénéficierez ainsi de plusieurs correctifs et améliorations, et cela nous permettra de mieux 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 encore essayé NGINX Plus, commencez votre essai gratuit de 30 jours dès aujourd’hui et découvrez comment NGINX Plus peut vous aider à faire évoluer et à déployer vos applications.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.