Contrôles d’intégrité actifs ou passifs : lesquels vous conviennent le mieux ?

Robert HaynesResponsable marketing technique

Tout comme les visites de contrôle régulières chez le médecin sont essentielles pour rester en bonne santé, la vérification régulière de l’état de vos applications est indispensable pour garantir des performances fiables. Lorsqu’il assure les fonctions de proxy inverse et d’équilibrage de charge du trafic, NGINX utilise des contrôles d’état passifs pour protéger les utilisateurs de vos applications contre les interruptions de service en redirigeant automatiquement le trafic vers d’autres serveurs lorsque certains ne répondent pas aux requêtes. NGINX Plus propose également des contrôles d’état actifs, qui envoient des sondes spécifiques capables de détecter les serveurs défaillants avant même qu’ils ne parviennent plus à traiter une requête. Quel type de contrôle d’état convient le mieux à vos applications ? Dans cet article, nous vous donnons les informations nécessaires pour faire votre choix.

Qu’est-ce qu’un contrôle d’intégrité ?

Au sens le plus élémentaire, une vérification de l’état de santé est une méthode permettant de déterminer si un serveur est en mesure de traiter le trafic. NGINX utilise des vérifications de l’état de santé pour surveiller les serveurs pour lesquels il assure la fonction de proxy inverse ou la répartition de charge du trafic – ce qu’il appelle des « serveurs en amont ».

Contrôles d’intégrité passifs

Les contrôles d’intégrité passifs, disponibles à la fois dans NGINX Open Source et NGINX Plus, reposent sur l’observation du comportement du serveur lors du traitement des connexions et du trafic. Ils permettent d’éviter que les utilisateurs ne subissent des interruptions dues à des délais d’attente dépassés côté serveur : lorsque NGINX détecte qu’un serveur est défaillant, il transmet immédiatement la requête à un autre serveur, cesse d’envoyer des requêtes au serveur défaillant et répartit les requêtes suivantes entre les serveurs opérationnels restants du groupe en amont.

Notez que les contrôles d’intégrité passifs ne sont efficaces que lorsque le groupe en amont comprend plusieurs membres. Lorsqu’un seul serveur en amont est défini, il n’est jamais marqué comme indisponible et les utilisateurs subissent une interruption de service lorsqu’il est défaillant.

Fonctionnement des vérifications d’état passives

Voici une présentation détaillée du fonctionnement des contrôles d’intégrité passifs, mais vous pouvez passer directement aux Contrôles d’intégrité actifs si cela ne vous intéresse pas.

Par défaut, NGINX considère qu’un serveur TCP/UDP (stream) est défaillant dès qu’une seule erreur ou expiration du délai d’attente survient lors de l’établissement d’une connexion avec celui-ci.

NGINX considère qu’un serveur HTTP est défaillant si une seule erreur ou expiration du délai se produit lors de l’établissement d’une connexion avec celui-ci, de la transmission d’une requête ou de la lecture de l’en-tête de réponse (l’absence totale de réponse est considérée comme une erreur de ce type). Vous pouvez utiliser la directive proxy_next_upstream pour personnaliser ces conditions pour le proxy HTTP, et il existe une directive équivalente pour les protocoles FastCGI, gRPC, memcached, SCGI, TCP/UDP et uwsgi.

Pour HTTP comme pour TCP/UDP, NGINX attend par défaut dix secondes avant de tenter à nouveau de se connecter à un serveur défaillant et de lui envoyer une requête. Vous pouvez utiliser le paramètre fail_timeout de la directive server[HTTP][Stream] pour modifier ce délai.

Vous pouvez utiliser le paramètre « max_fails » de la directive « server » pour augmenter le nombre d’erreurs ou d’expirations de délai nécessaires pour que NGINX considère le serveur comme défaillant ; dans ce cas, le paramètre « fail_timeout » définit la période pendant laquelle ce nombre d’erreurs ou d’expirations de délai doit être atteint, ainsi que la durée pendant laquelle NGINX attend avant de réessayer de contacter le serveur après l’avoir marqué comme défaillant.

Contrôles d’intégrité actifs

Les contrôles d’intégrité actifs, disponibles exclusivement avec NGINX Plus, sont des requêtes spéciales envoyées régulièrement aux points de terminaison de l’application afin de vérifier qu’ils répondent correctement. Ils sont distincts des contrôles d’intégrité passifs et viennent les compléter. Par exemple, NGINX Plus peut envoyer périodiquement une requête HTTP au serveur web de l’application pour s’assurer qu’il renvoie un code de réponse valide et le contenu attendu. Les contrôles d’intégrité actifs permettent de surveiller en continu l’état de composants et de processus spécifiques de l’application. Ils fournissent une mesure directe de la disponibilité de l’application, même si celle-ci dépend de la représentativité du contrôle d’intégrité défini par rapport à l’état global de l’application.

Vous pouvez personnaliser de nombreux aspects d’une vérification active de l’état de santé. Consultez la section « Cas d’utilisation des vérifications actives de l’état de santé ».

Cas d’utilisation des contrôles d’intégrité passifs

Les contrôles d’intégrité passifs sont indispensables. Il est recommandé à toutes les équipes de développement d’applications, DevOps, DevSecOps et d’exploitation des plateformes d’intégrer des contrôles d’intégrité passifs à leur programme de surveillance de l’infrastructure de production. Par défaut, NGINX effectue des contrôles d’intégrité passifs sur le trafic avec équilibrage de charge, notamment pour les configurations HTTP, TCP et UDP.

Les avantages des contrôles d’intégrité passifs sont notamment les suivants :

• Disponible dans NGINX Open Source
• Activé par défaut pour les serveurs inclus dans un bloc de configuration upstream{} configuration block
• Aucune charge supplémentaire sur les serveurs en amont
• Configurable en fonction du nombre minimal d’échecs sur une période donnée, comme décrit dans Fonctionnement des contrôles d’intégrité passifs
• Démarrage progressif configurable (exclusif à NGINX Plus) : lorsqu’un serveur redevient opérationnel, NGINX Plus augmente progressivement le volume de trafic qui lui est transmis afin de lui laisser le temps de « monter en régime »

Les avantages de NGINX Open Source sont son coût (nul, bien évidemment), sa configurabilité et sa vaste bibliothèque de modules tiers. Le code source étant disponible, les développeurs peuvent modifier et étendre les fonctionnalités afin de répondre à leurs besoins spécifiques.

Pour de nombreuses applications (et leurs développeurs), les contrôles d’intégrité passifs sont suffisants. Par exemple, les contrôles d’intégrité actifs peuvent être superflus pour les microservices qui ne sont pas directement accessibles aux clients et qui exécutent des tâches de moindre envergure. De même, ils peuvent ne pas être nécessaires pour les applications où la mise en cache permet de réduire les risques de latence, ou lorsque les réseaux de diffusion de contenu (CDN) peuvent prendre en charge certaines tâches de l’application. En résumé, les contrôles d’intégrité passifs seuls conviennent particulièrement aux cas suivants :

• Surveillance du trafic HTTP
• Surveillance de l’infrastructure séparément des applications
• Surveillance des applications pour lesquelles la latence est acceptable
• Surveillance des applications internes pour lesquelles des performances élevées ne sont pas essentielles

Cas d’usage des contrôles d’intégrité actifs

Pour les applications critiques, les contrôles d’intégrité actifs sont souvent indispensables, car les problèmes ont un impact direct sur les clients et les processus clés. Pour ces applications, il est essentiel de les tester dans des conditions aussi proches que possible de celles rencontrées par leurs clients ou utilisateurs, ce qui nécessite des contrôles d’intégrité actifs. Ces contrôles sont comparables aux outils de surveillance des performances applicatives tels que New Relic et AppDynamics, qui effectuent des vérifications hors bande pour mesurer la latence et les réponses des applications. Pour les contrôles d’intégrité actifs, NGINX Plus propose plusieurs fonctionnalités et capacités qui ne sont pas incluses dans NGINX Open Source :

• Contrôles d’intégrité hors bande pour vérifier la disponibilité des applications
• Testez les points de terminaison configurés et recherchez des réponses spécifiques
• Testez des ports différents de ceux qui gèrent le trafic réel de l’application
• Connexions HTTP persistantes pour les contrôles d’intégrité, évitant ainsi d’établir une nouvelle connexion à chaque contrôle
• Contrôle accru des conditions d’échec et de réussite
• Testez éventuellement les nouveaux serveurs avant qu’ils ne reçoivent du trafic applicatif réel

Grâce aux contrôles d’intégrité actifs, les développeurs peuvent configurer NGINX Plus pour détecter automatiquement lorsqu’un serveur backend est indisponible ou rencontre des problèmes, puis acheminer le trafic vers des serveurs opérationnels jusqu’à la résolution du problème. La configurabilité accrue des contrôles d’intégrité actifs permet d’effectuer des vérifications plus poussées et, éventuellement, de détecter les problèmes applicatifs avant qu’ils n’affectent les utilisateurs réels de l’application. Cela permet de réduire au minimum les temps d’arrêt et d’éviter toute interruption de l’accès des utilisateurs à l’application.

Comment configurer les contrôles d’intégrité

Les contrôles d’intégrité passifs sont activés par défaut, mais vous pouvez personnaliser leur fréquence et le nombre d’échecs requis avant qu’un service ne soit considéré comme défaillant, comme décrit dans Fonctionnement des contrôles d’intégrité passifs. Pour obtenir des instructions complètes sur la configuration des contrôles d’intégrité passifs et actifs, consultez notre documentation :

• Contrôles d’intégrité HTTP
• Contrôles d’intégrité TCP
• Contrôles d’intégrité UDP
• Contrôles d’intégrité gRPC

Conclusion : choisissez les contrôles d’intégrité adaptés aux exigences de votre application

Les contrôles d’intégrité jouent un rôle essentiel pour garantir le fonctionnement fluide et réactif de toute application en production. Ils constituent le meilleur moyen de détecter les problèmes et d’identifier les sources de latence croissante avant qu’elles n’affectent les utilisateurs finaux. Pour de nombreuses applications, les contrôles d’intégrité passifs sont suffisants.

Pour les applications plus critiques, qui nécessitent une visibilité directe sur le comportement de l’application du point de vue de l’utilisateur, les contrôles actifs sont préférables. NGINX Open Source est gratuit et propose des contrôles d’intégrité passifs configurables. NGINX Plus offre des fonctionnalités avancées de contrôle d’intégrité actif ainsi qu’un support commercial.

Vous souhaitez essayer les contrôles d’intégrité actifs avec NGINX Plus ? Commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Robert HaynesResponsable marketing technique

Autres articles de Robert Haynes