Documentation Oracle Cloud Infrastructure

Effets secondaires courants de configurations incorrectes de la vérification de l'état d'équilibreur de charge

Découvrez les effets secondaires courants associés à une mauvaise configuration des vérifications de l'état de l'équilibreur de charge.

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 back-end. Dans ce scénario, vous pouvez vous servir de l'utilitaire curl pour effectuer un test à partir d'un système du même réseau. Par exemple : $ curl -i http://backend_ip_address/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 votre back-end utilise HTTPS, vous devez utiliser TCP comme protocole.

    Erreur de journalisation OCI : code:EPROTO, errno:EPROTO

  • Code 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. Voici un scénario courant : un back-end renvoie un code de statut 302 alors que vous attendez un code de statut 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:nnn,expected:200 où nnn 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 : .*

    • 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 configurés de façon incorrecte

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 configuré de manière incorrecte les groupes de sécurité réseau, les listes de sécurité ou les pare-feu locaux (par exemple, firewalld, iptables ou SELinux). Dans ce scénario, vous pouvez vous servir de l'utilitaire curl ou netcat pour effectuer un test à partir d'un système appartenant au même sous-réseau et au même groupe de sécurité réseau que votre instance HTTP d'équilibreur de charge. Par exemple : $ curl -i http://backend_ip_address/health TCP et nc -zvw3 backend_ip_address 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