Documentation sur Oracle Cloud Infrastructure

Politiques de vérification de l'état des équilibreurs de charge de réseau

Configurez et utilisez les vérifications de l'état afin de décider de la disponibilité des serveurs dorsaux pour un équilibreur de charge de réseau.

Une vérification de l'état est un test permettant de confirmer la disponibilité des serveurs dorsaux. Il peut s'agir d'une demande ou d'un essai de connexion. Selon l'intervalle que vous spécifiez, l'équilibreur de charge de réseau applique la politique de vérification de l'état pour surveiller les serveurs dorsaux en continu. Si la vérification de l'état d'un serveur échoue, l'équilibreur de charge de réseau retire temporairement ce dernier de la rotation. Si la vérification de l'état aboutit ultérieurement, l'équilibreur de charge de réseau replace le serveur dans la rotation.

Vous configurez la politique de vérification de l'état lorsque vous créez un équilibreur de charge de réseau. Vous pouvez également configurer la politique de vérification de l'état lors de la création ou de la modification d'un jeu dorsal pour un équilibreur de charge existant. Voici un sommaire des protocoles que vous pouvez utiliser avec votre politique de vérification de l'état :

  • Les vérifications d'état de niveau TCP tentent d'établir une connexion TCP avec les serveurs dorsaux et valident la réponse en fonction du statut de connexion.

    S'il n'est pas pratique de créer une demande pour le protocole que vous utilisez, vous pouvez omettre les données de la demande. Dans ce cas, le serveur dorsal est considéré comme sain si la connexion TCP réussit.

  • Les vérifications d'état de niveau HTTP envoient des demandes aux serveurs dorsaux sur des URI spécifiques et valident la réponse en fonction du code de statut ou des données d'entité (corps) retournés.
  • Les vérifications d'état de niveau HTTPS envoient des demandes aux serveurs dorsaux à un URI spécifique et valident la réponse en fonction du code de statut ou des données d'entité (corps) retournés au moyen d'un protocole HTTPS sécurisé et chiffré.
  • Les vérifications d'état de niveau UDP envoient une seule demande au serveur dorsal et comparent la réponse (si elle est reçue) aux données de réponse que vous spécifiez.
  • Les vérifications d'état de niveau DNS envoient des demandes aux serveurs dorsaux à l'aide d'UDP ou de TCP. La vérification d'état utilise également le nom de l'interrogation et les informations connexes que vous voulez fournir la réponse DNS du serveur dorsal.

Le service fournit des capacités de vérification de l'état propres à l'application afin d'accroître la disponibilité et de réduire la fenêtre de maintenance de l'application.

Vous pouvez effectuer les tâches suivantes de gestion des politiques de vérification de l'état :

Configuration du protocole de vérification de l'état correspondant à l'application ou au service

Si vous exécutez un service HTTP, veillez à configurer une vérification de l'état de niveau HTTP. Si vous exécutez une vérification de l'état de niveau TCP sur un service HTTP, la réponse risque d'être incorrecte. L'établissement d'une liaison TCP peut réussir et indiquer que le service fonctionne même si le service HTTP n'est pas configuré correctement ou présente d'autres problèmes. Bien que la vérification de l'état semble avoir abouti, les clients risquent de subir des échecs de transaction. Par exemple :

  • Le service HTTP dorsal présente des problèmes lorsqu'il communique avec l'URL de vérification de l'état et que celle-ci retourne des messages 5XX. Une vérification de l'état HTTP capte le message provenant de l'URL et marque le service comme arrêté. Dans ce cas, l'établissement d'une liaison de vérification d'état TCP réussit et marque le service comme sain, même si le service HTTP est en fait inutilisable.
  • Le service HTTP dorsal renvoie des messages 4XX en raison de problèmes d'autorisation ou d'absence de contenu configuré. Une vérification d'état TCP ne détecte pas ces erreurs.

Indicateurs de statut d'état

Le service d'équilibreur de charge de réseau fournit des indicateurs qui utilisent les politiques de vérification de l'état pour produire des rapports sur l'état général des équilibreurs de charge de réseau et de leurs composants. Vous pouvez voir les indicateurs de statut d'état dans les pages Liste et Détails de la console pour les équilibreurs de charge, les jeux et les serveurs dorsaux. Vous pouvez également utiliser l'API pour extraire ces informations.

Les indicateurs de statut d'état comportent quatre niveaux. Le tableau suivant indique la signification générale de chaque niveau :

Niveau Couleur Description
OK Vert Aucune attention requise.

La ressource fonctionne comme prévu.
Avertissement Jaune Certaines entités de production de rapports nécessitent votre attention.

La ressource ne fonctionne pas de manière optimale ou la ressource est incomplète et nécessite un travail supplémentaire.
Critique Rouge Certaines ou toutes les entités de production de rapports nécessitent une attention immédiate.

La ressource ne fonctionne pas ou une défaillance inattendue est immédiate.
Inconnu Gris Le statut de l'état ne peut pas être déterminé.

La ressource ne répond pas ou est en cours de transition et son statut peut évoluer.

La signification précise de chaque niveau diffère pour les composants suivants :

Utilisation du statut d'état

Au niveau supérieur, l'état de l'équilibreur de charge de réseau reflète celui de ses composants. Les indicateurs de statut d'état fournissent des informations sur lesquelles vous devrez peut-être forer pour examiner un problème existant. Voici certains problèmes courants que les indicateurs de statut d'état peuvent vous aider à détecter et à corriger :

La vérification de l'état est mal configurée.

Dans ce cas, tous les serveurs dorsaux d'un ou de plusieurs modules d'écoute concernés sont signalés comme peu sains. Si votre enquête indique que les serveurs dorsaux ne présentent pas de problèmes, il est probable qu'un jeu dorsal inclut une vérification d'état mal configurée.

Un module d'écoute est mal configuré.

Tous les indicateurs de statut d'état de serveur dorsal ont la valeur OK, mais l'équilibreur de charge de réseau ne transmet pas le trafic sur un module d'écoute.

La configuration du module d'écoute peut indiquer :

  • Un port erroné.
  • Un protocole erroné.
  • Une politique erronée.

Si votre enquête indique que le module d'écoute n'est pas à l'origine de l'erreur, vérifiez la configuration de la liste de sécurité.

Une règle de sécurité est mal configurée.

Les indicateurs de statut d'état vous aident à diagnostiquer deux cas de règles de sécurité mal configurées :

  • Les indicateurs de statut d'état de toutes les entités affichent la valeur OK, mais le trafic n'est pas fluide (comme dans le cas des modules d'écoute mal configurés). Si le module d'écoute n'est pas à l'origine de l'erreur, vérifiez la configuration de la règle de sécurité.
  • Les statuts d'état de toutes les entités signalent un état non sain. Vous avez vérifié la configuration de la vérification de l'état et les services s'exécutent correctement sur les serveurs dorsaux.

    Dans ce cas, il est possible que les règles de sécurité ne comprennent pas l'intervalle d'adresses IP pour la source des demandes de vérification de l'état. L'adresse IP source de la vérification de l'état figure sur la page Détails de chaque serveur dorsal. Vous pouvez également utiliser l'API pour rechercher l'adresse IP dans le champ sourceIpAddress de l'objet HealthCheckResult.

    Note

    L'adresse IP source des demandes de vérification de l'état provient d'une instance de calcul gérée par le service d'équilibreur de charge de réseau.

Un ou plusieurs serveurs dorsaux sont signalés comme non sains.

Il est possible qu'un serveur dorsal ne soit pas sain ou que la vérification de l'état soit mal configurée. Pour voir le code d'erreur correspondant, vérifiez le champ de statut dans la page Détails du serveur dorsal. Vous pouvez également utiliser l'API pour rechercher le code d'erreur dans le champ healthCheckStatus de l'objet HealthCheckResult.

Autres cas pour lesquels le statut d'état peut se révéler utile :

Le statut est mis à jour toutes les trois minutes. Aucune granularité plus précise n'est disponible.

Le statut d'état ne fournit pas de données historiques.

Meilleures pratiques en matière de vérification de l'état

Configurez le protocole de vérification de l'état correspondant à l'application ou au service. Si vous exécutez un service HTTP, veillez à configurer une vérification de l'état de niveau HTTP. Si vous exécutez une vérification de l'état de niveau TCP sur un service HTTP, la réponse risque d'être incorrecte. L'établissement d'une liaison TCP peut réussir et indiquer que le service fonctionne même si le service HTTP n'est pas configuré correctement ou présente d'autres problèmes. Bien que la vérification de l'état semble avoir abouti, les clients risquent de subir des échecs de transaction.

Par exemple :

  • Le service HTTP dorsal présente des problèmes lorsqu'il communique avec l'URL de vérification de l'état et que celle-ci retourne des messages 5XX. Une vérification de l'état HTTP capte le message provenant de l'URL et marque le service comme arrêté. Dans ce cas, l'établissement d'une liaison de vérification d'état TCP réussit et marque le service comme sain, même si le service HTTP est en fait inutilisable.
  • Le service HTTP dorsal renvoie des messages 4XX en raison de problèmes d'autorisation ou d'absence de contenu configuré. Une vérification d'état TCP ne détecte pas ces erreurs.

Effets secondaires courants de vérifications d'état mal configurées

Voici les effets secondaires courants d'une mauvaise configuration de la vérification de l'état. Vous pouvez les utiliser pour résoudre les problèmes.

  • Port incorrect

    Dans ce scénario, tous les serveurs dorsaux sont signalés comme non sains. Si les serveurs dorsaux ne présentent aucun problème, vous avez peut-être commis une erreur lors de la définition du port. Le port doit être à l'écoute et a autorisé le trafic sur le système dorsal.

    Erreur de journalisation OCI : errno":"EHOSTUNREACH","syscall":"connect".

  • Chemin incorrect

    Dans ce scénario, tous les serveurs dorsaux sont signalés comme non sains. Si les serveurs dorsaux ne présentent aucun problème, vous avez peut-être commis une erreur lors de la définition du chemin de la vérification d'état HTTP auquel il doit correspondre, c'est-à-dire à une application réelle sur le serveur dorsal. Dans ce cas, vous pouvez utiliser un test curl à partir d'un système du même réseau.

    Par exemple : 

    $ curl -i http://10.0.0.5/health

    Vous recevez le code de statut configuré dans la réponse Erreur de journalisation OCI : 

    "msg":"invalid statusCode","statusCode":404,"expected":"200".
  • Protocole incorrect

    Dans ce scénario, tous les serveurs dorsaux sont signalés comme non sains. Si les serveurs dorsaux ne présentent aucun problème, vous avez peut-être commis une erreur en définissant le protocole qu'il doit mettre en correspondance avec le protocole à l'écoute sur le système dorsal. Par exemple : Nous ne prenons en charge que les vérifications d'état TCP et HTTP. Si le serveur dorsal utilise HTTPS, utilisez TCP comme protocole.

    Erreur de journalisation OCI :

    "code":"EPROTO","errno":"EPROTO".
  • Code de statut incorrect

    Dans ce scénario, tous les serveurs dorsaux sont signalés comme non sains. Si les serveurs dorsaux ne présentent aucun problème, pour une vérification d'état HTTP, vous avez peut-être commis une erreur lors de la définition du code de statut pour qu'il correspond au code de statut réel retourné par le système dorsal. Un scénario courant est lorsqu'un système dorsal retourne un code 302 et que vous attendez un code 200. Le système dorsal vous envoie probablement à une page de connexion ou à un autre emplacement du serveur. Dans ce scénario, vous pouvez corriger le serveur dorsal pour qu'il retourne le code attendu ou utiliser 302 dans la configuration de la vérification d'état.

    Erreur de journalisation OCI :

    "msg":"invalid statusCode","statusCode":XX,"expected":"200"

    où XX désigne le code de statut retourné.

  • Modèle d'expression rationnelle incorrect

    Tous les serveurs dorsaux signalent un état peu sain. Si les serveurs dorsaux ne présentent aucun problème, vous avez peut-être commis une erreur en définissant un modèle d'expression rationnelle incorrect pour le corps ou le système dorsal ne retourne pas le corps attendu. Dans ce scénario, vous pouvez modifier le système dorsal pour qu'il corresponde au modèle ou corriger ce dernier pour qu'il corresponde au système dorsal. Voici quelques exemples de modèles spécifiques.

    • Tout contenu - ".*"
    • Une page retournant la valeur "Status:OK:" - "Status:OK:.*"
    • Erreur de journalisation OCI : "response match result: failed"
  • Groupes de sécurité de réseau, listes de sécurité ou pare-feu local mal configurés

Tous les serveurs dorsaux ou certains d'entre eux sont signalés comme non sains. Si les serveurs dorsaux ne présentent aucun problème, vous avez peut-être commis une erreur en configurant les groupes de sécurité de réseau, les listes de sécurité ou les pare-feu locaux tels que firewalld, iptables, or SELiinux. Dans ce scénario, vous pouvez utiliser un test curl ou netcat à partir d'un système qui appartient au même sous-réseau et au même groupe de sécurité de réseau que l'instance d'équilibreur HTTP :

Par exemple : 

$ curl -i http://10.0.0.5/health TCP: ex: nc -zvw3 10.0.05 443.

Vous pouvez vérifier le pare-feu local à l'aide de la commande suivante : 

firewall-cmd --list-all --zone=public.

Si les règles attendues sont manquantes dans le pare-feu, vous pouvez utiliser un jeu de commandes tel que celui-ci pour ajouter le service (cet exemple concerne le port HTTP 80) : 

  • firewall-cmd --zone=public --add-service=http
  • firewall-cmd --zone=public --permanent --add-service=http

Configuration du protocole de vérification de l'état correspondant à votre application ou service

Le service fournit des capacités de vérification de l'état propres à l'application afin d'accroître la disponibilité et de réduire la fenêtre de maintenance de votre application.

Si vous exécutez un service HTTP, veillez à configurer une vérification de l'état de niveau HTTP. Si vous exécutez une vérification de l'état de niveau TCP sur un service HTTP, la réponse risque d'être incorrecte. L'établissement d'une liaison TCP peut réussir et indiquer que le service fonctionne même si le service HTTP n'est pas configuré correctement ou présente d'autres problèmes. Bien que la vérification de l'état semble avoir abouti, les clients risquent de subir des échecs de transaction. Par exemple :

  • Le service HTTP dorsal présente des problèmes lorsqu'il communique avec l'URL de vérification de l'état et que celle-ci retourne des messages 5XX. Une vérification de l'état HTTP capte le message provenant de l'URL et marque le service comme arrêté. Dans ce cas, l'établissement d'une liaison de vérification d'état TCP réussit et marque le service comme sain, même si le service HTTP est en fait inutilisable.
  • Le service HTTP dorsal renvoie des messages 4XX en raison de problèmes d'autorisation ou d'absence de contenu configuré. Une vérification d'état TCP ne détecte pas ces erreurs.

Vérification de l'état du DNS

Le service d'équilibreur de charge de réseau prend en charge la vérification de l'état du DNS sur le transport TCP et UDP, pour les serveurs dorsaux IPv4 et IPv6. La vérification de l'état du DNS pour les serveurs dorsaux du résolveur DNS est une amélioration par rapport aux vérifications basées sur TCP ou UDP, car elle vérifie que le protocole DNS est fonctionnel pour les serveurs dorsaux du résolveur DNS. Ces protocoles utilisent le format base64 pour spécifier les messages de demande et de réponse, ce qui peut être difficile lors de la formation de demandes et de réponses DNS. En outre, il peut y avoir plusieurs réponses valides et RCODE dans le message de réponse, par exemple NOERROR(0) et NXDOMAIN(3). Il n'est pas possible de traiter tous ces scénarios à l'aide de la vérification d'état TCP ou UDP standard.

Lorsque vous créez un jeu dorsal, lors de la création initiale de l'équilibreur de charge de réseau ou lorsque vous ajoutez un jeu dorsal à un équilibreur de charge de réseau existant, vous devez spécifier les configurations propres au protocole suivantes si vous utilisez la vérification de l'état du DNS :

  • Nom d'interrogation : Fournissez un nom de domaine DNS pour l'interrogation.
  • Classe d'interrogation : Vous disposez des options suivantes :
    • ENTRÉE : Internet (par défaut)
    • CH : Chaos
  • Type d'interrogation : Sélectionnez l'une des options suivantes :
    • A : Indique un nom d'hôte correspondant à l'adresse IPv4. (par défaut)
    • AAAA : Indique un nom d'hôte correspondant à l'adresse IPv6.
    • TXT : Indique un champ de texte.
  • Codes de réponse acceptables : Sélectionnez une ou plusieurs des options suivantes :
    • L'interrogation DNS RCODE:0 NOERROR s'est terminée avec succès.
    • Le serveur RCODE:2 SERVFAIL n'a pas pu terminer la demande DNS.
    • Le nom de domaine RCODE:3 NXDOMAIN n'existe pas.
    • RCODE:5 REFUSED Le serveur a refusé de répondre à l'interrogation.