Documentation Oracle Cloud Infrastructure

Stratégies de vérification de l'état pour les équilibreurs de charge réseau

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

Une vérification d'état est un test qui permet de confirmer la disponibilité des serveurs back-end. Il peut s'agir d'une demande ou d'une tentative de connexion. En fonction de l'intervalle indiqué, l'équilibreur de charge réseau applique la stratégie de vérification de l'état afin de surveiller les serveurs back-end de façon continue. Si un serveur échoue au test de vérification de l'état, l'équilibreur de charge réseau le met temporairement hors service. Si ce même serveur le réussit ultérieurement, l'équilibreur de charge réseau le remet en service.

Vous configurez la stratégie de vérification de l'état lorsque vous créez un équilibreur de charge réseau. Vous pouvez également configurer la stratégie de vérification de l'état lors de la création ou de la modification d'un ensemble de back-ends pour un équilibreur de charge existant. Voici un récapitulatif des protocoles que vous pouvez utiliser avec votre stratégie de vérification de l'état :

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

    Si la création d'une demande pour le protocole que vous utilisez n'est pas pratique, vous pouvez omettre les données de demande. Dans ce cas, le back-end est considéré comme en bon état si la connexion TCP est établie.

  • Les vérifications de l'état au niveau HTTP envoient des demandes aux serveurs back-end sur un URI donné et valident la réponse en fonction du code de statut ou des données d'entité (corps) renvoyées.
  • Les vérifications de l'état au niveau HTTPS envoient des demandes aux serveurs back-end avec un URI spécifique et valident la réponse en fonction du code de statut ou des données d'entité (corps) renvoyés via un protocole HTTPS sécurisé et crypté.
  • Les vérifications de l'état au niveau UDP envoient une seule demande au serveur back-end et mettent en correspondance la réponse (si elle est reçue) avec les données de réponse que vous spécifiez.
  • Les vérifications de l'état au niveau du DNS envoient des demandes aux serveurs back-end à l'aide du protocole UDP ou TCP. La vérification de l'état utilise également le nom de la requête et les informations connexes à fournir à la réponse DNS du serveur back-end.

Le service fournit des fonctions de vérification de l'état propres à l'application afin d'améliorer la disponibilité et de réduire la fenêtre de maintenance de l'application.

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

Configuration du protocole de vérification de l'état pour qu'il corresponde à l'application ou au service

Si vous exécutez un service HTTP, veillez à configurer une vérification de l'état au niveau HTTP. Si vous exécutez une vérification de l'état au niveau TCP sur un service HTTP, vous pouvez ne pas obtenir de réponse correcte. L'établissement de liaison TCP peut réussir et indiquer que le service est actif même lorsque le service HTTP n'est pas configuré correctement ou rencontre d'autres problèmes. La vérification de l'état affiche alors un résultat positif, mais les clients peuvent rencontrer des échecs de transaction. Par exemple :

  • Le service HTTP back-end rencontre des problèmes lors de la communication avec l'URL de vérification de l'état, qui renvoie des messages 5XX. Une vérification de l'état HTTP détecte le message de l'URL de vérification de l'état et marque le service comme étant arrêté. Dans cette situation, l'établissement de liaison de vérification de l'état au niveau TCP réussit et marque le service comme étant en bon état, alors que le service HTTP n'est peut-être pas utilisable.
  • Le service HTTP back-end répond avec des messages 4XX en raison de problèmes d'autorisation ou d'absence de contenu configuré. La vérification de l'état au niveau TCP ne détecte pas ces erreurs.

Indicateurs d'état

Le service d'équilibreur de charge réseau fournit des indicateurs d'état qui utilisent les stratégies de vérification de l'état pour générer des rapports sur l'état général des équilibreurs de charge réseau et de leurs composants. Vous pouvez afficher les indicateurs d'état dans la console , sur les pages Liste et Détails pour les équilibreurs de charge, les ensembles de back-ends et les serveurs back-end. Vous pouvez également utiliser l'API pour extraire ces informations.

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

Niveau Couleur Description
OK Vert Aucune attention n'est requise.

La ressource fonctionne comme prévu.
Avertissement Jaune Certaines entités de génération de rapports requièrent une attention particulière.

La ressource ne fonctionne pas de façon optimale. Elle peut également être incomplète et nécessiter un traitement supplémentaire.
Critique Rouge Tout ou partie des entités de génération de rapports requièrent une attention immédiate.

La ressource ne fonctionne pas ou un échec imminent.
Inconnu Gris Impossible de déterminer l'état.

La ressource ne répond pas. Elle peut également se trouver dans une phase de transition et prendre un autre état ultérieurement.

La signification précise de chaque niveau diffère en fonction des composants suivants :

Utilisation de l'état

Au niveau supérieur, l'état de l'équilibreur de charge réseau reflète l'état de ses composants. Les indicateurs d'état fournissent des informations dont vous pouvez avoir besoin pour effectuer une analyse descendante et examiner un problème existant. Voici quelques problèmes courants que les indicateurs d'état peuvent vous aider à détecter et à corriger :

Vérification de l'état configurée de façon incorrecte.

Dans ce scénario, tous les serveurs back-end des processus d'écoute concernés sont signalés comme étant en mauvais état. Si votre investigation trouve que les serveurs back-end ne présentent aucun problème, un ensemble de back-ends inclut probablement une vérification de l'état configurée de façon incorrecte.

Processus d'écoute configuré de façon incorrecte.

Tous les indicateurs d'état du serveur back-end affichent OK, mais l'équilibreur de charge réseau ne transmet pas le trafic sur un processus d'écoute.

Il se peut que le processus d'écoute soit configuré pour :

  • écouter sur un port incorrect,
  • utiliser un protocole incorrect,
  • utiliser une stratégie incorrecte.

Si vous découvrez que le processus d'écoute n'est pas en cause, vérifiez la configuration de la liste de sécurité.

Règle de sécurité configurée de façon incorrecte.

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

  • Tous les indicateurs d'état des entités affichent OK, mais le trafic ne circule pas (comme dans le cas de processus d'écoute configurés de façon incorrecte). Si le processus d'écoute n'est pas en cause, vérifiez la configuration des règles de sécurité.
  • Tous les indicateurs d'état des entités sont signalés comme étant en mauvais état. Vous avez vérifié la configuration de la vérification de l'état et les services s'exécutent correctement sur les serveurs back-end.

    Dans ce cas, les règles de sécurité peuvent ne pas inclure la plage d'adresses IP de la source des demandes de vérification de l'état. Vous pouvez trouver l'adresse IP source de la vérification de l'état sur la page Détails de chaque serveur back-end. Vous pouvez également utiliser l'API pour rechercher l'adresse IP dans le champ sourceIpAddress de l'objet HealthCheckResult.

    Remarque

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

Serveurs back-end signalés comme étant en mauvais état.

Un serveur back-end est peut-être en mauvais état ou la vérification de l'état est peut-être configurée de façon incorrecte. Pour consulter le code d'erreur correspondant, vérifiez le champ de statut sur la page Détails du serveur back-end. Vous pouvez également utiliser l'API pour rechercher le code d'erreur dans le champ healthCheckStatus de l'objet HealthCheckResult.

Autres cas où l'état peut s'avérer utile :

L'état est mis à jour toutes les trois minutes. Aucun degré de finesse supplémentaire n'est disponible.

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

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

Configurez le protocole de vérification de l'état pour qu'il corresponde à l'application ou au service. Si vous exécutez un service HTTP, veillez à configurer une vérification de l'état au niveau HTTP. Si vous exécutez une vérification de l'état au niveau TCP sur un service HTTP, vous pouvez ne pas obtenir de réponse correcte. L'établissement de liaison TCP peut réussir et indiquer que le service est actif même lorsque le service HTTP n'est pas configuré correctement ou rencontre d'autres problèmes. La vérification de l'état affiche alors un résultat positif, mais les clients peuvent rencontrer des échecs de transaction.

Par exemple :

  • Le service HTTP back-end rencontre des problèmes lors de la communication avec l'URL de vérification de l'état, qui renvoie des messages 5XX. Une vérification de l'état HTTP détecte le message de l'URL de vérification de l'état et marque le service comme étant arrêté. Dans cette situation, l'établissement de liaison de vérification de l'état au niveau TCP réussit et marque le service comme étant en bon état, alors que le service HTTP n'est peut-être pas utilisable.
  • Le service HTTP back-end répond avec des messages 4XX en raison de problèmes d'autorisation ou d'absence de contenu configuré. La vérification de l'état au niveau TCP ne détecte pas ces erreurs.

Effets secondaires courants d'une configuration incorrecte de la vérification de l'état

Vous trouverez ci-après les effets secondaires courants d'une configuration incorrecte de la vérification de l'état, qui peuvent être utilisés pour résoudre les problèmes.

  • Port incorrect

    Dans ce scénario, tous les serveurs back-end sont signalés comme étant en mauvais état. Si les serveurs back-end 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 autoriser le trafic sur le back-end.

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

  • Chemin incorrect

    Dans ce scénario, tous les serveurs back-end sont signalés comme étant en mauvais état. Si les serveurs back-end ne présentent aucun problème, vous avez peut-être commis une erreur lors de la définition du chemin de la vérification de l'état HTTP, qui doit correspondre à une véritable application sur le serveur back-end. Dans ce cas, vous pouvez utiliser un test de boucle à partir d'un système dans le 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 back-end sont signalés comme étant en mauvais état. Si les serveurs back-end ne présentent aucun problème, vous avez peut-être commis une erreur lors de la définition du protocole, qui doit correspondre au protocole qui écoute sur le back-end. Par exemple, nous prenons uniquement en charge les vérifications d'état TCP et HTTP. Si le serveur back-end 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 back-end sont signalés comme étant en mauvais état. Si les serveurs back-end ne présentent aucun problème, pour une vérification de l'état HTTP, vous avez peut-être commis une erreur lors de la définition du code de statut, qui doit correspondre au code de statut réel renvoyé par le back-end. Il arrive fréquemment qu'un back-end renvoie un code 302 alors que vous attendez un code 200. Ce résultat est probablement dû au fait que le back-end vous dirige vers une page de connexion ou un autre emplacement sur le serveur. Dans ce scénario, vous pouvez corriger le back-end pour qu'il renvoie le code attendu ou utiliser le code 302 dans la configuration de la vérification de l'état.

    Erreur de journalisation OCI :

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

    où XX est le code de statut renvoyé.

  • Modèle d'expression incorrect

    Tous les serveurs back-end sont signalés comme étant en mauvais état. Si les serveurs back-end ne présentent aucun problème, vous avez peut-être commis une erreur lors de la définition d'un modèle d'expression régulière incorrect, cohérent avec le corps, ou le back-end ne renvoie pas le corps attendu. Dans ce scénario, vous pouvez modifier le back-end afin qu'il corresponde au modèle ou corriger le modèle afin qu'il corresponde au back-end. Vous trouverez ci-après des exemples de modèle spécifiques.

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

Tous les serveurs back-end ou certains d'entre eux sont signalés comme n'étant pas en santé. Si les serveurs back-end ne présentent aucun problème, vous avez peut-être commis une erreur lors de la configuration des groupes de sécurité réseau, des listes de sécurité ou des pare-feu locaux tels que Firewallld, iptables ou 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é réseau que l'instance HTTP de l'équilibreur :

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 le pare-feu ne contient pas les règles attendues, vous pouvez utiliser un ensemble de commandes tel que celui-ci pour ajouter le service : (l'exemple suivant 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 pour qu'il corresponde à votre application ou service

Le service fournit des fonctions de vérification de l'état propres à l'application afin d'améliorer la disponibilité et de réduire la fenêtre de maintenance de l'application.

Si vous exécutez un service HTTP, veillez à configurer une vérification de l'état au niveau HTTP. Si vous exécutez une vérification de l'état au niveau TCP sur un service HTTP, vous pouvez ne pas obtenir de réponse correcte. L'établissement de liaison TCP peut réussir et indiquer que le service est actif même lorsque le service HTTP n'est pas configuré correctement ou rencontre d'autres problèmes. La vérification de l'état affiche alors un résultat positif, mais les clients peuvent rencontrer des échecs de transaction. Par exemple :

  • Le service HTTP back-end rencontre des problèmes lors de la communication avec l'URL de vérification de l'état, qui renvoie des messages 5XX. Une vérification de l'état HTTP détecte le message de l'URL de vérification de l'état et marque le service comme étant arrêté. Dans cette situation, l'établissement de liaison de vérification de l'état au niveau TCP réussit et marque le service comme étant en bon état, alors que le service HTTP n'est peut-être pas utilisable.
  • Le service HTTP back-end répond avec des messages 4XX en raison de problèmes d'autorisation ou d'absence de contenu configuré. La vérification de l'état au niveau TCP ne détecte pas ces erreurs.

Vérification de l'état du DNS

Le service d'équilibreur de charge réseau prend en charge la vérification de l'état DNS sur le transport TCP et UDP, pour les serveurs back-end IPv4 et IPv6. La vérification de l'état du DNS pour les serveurs back-end 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 back-end 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 des demandes et des 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). La gestion de tous ces scénarios à l'aide de la vérification de l'état TCP ou UDP standard n'est pas possible.

Lorsque vous créez un ensemble de back-ends, lors de la création initiale de l'équilibreur de charge réseau ou de l'ajout d'un ensemble de back-ends à un équilibreur de charge réseau existant, vous devez indiquer les configurations propres au protocole suivantes si vous utilisez la vérification de l'état DNS :

  • Nom de requête : indiquez un nom de domaine DNS pour la requête.
  • Classe de requête : sélectionnez l'une des options suivantes :
    • IN : Internet (par défaut)
    • CH : Chaos
  • Type de requête : 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 :
    • La requête 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 à la requête.