Effets secondaires courants des vérifications de l'état des équilibreurs de charge mal configurées

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

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 un port qui é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 en définissant le chemin de la vérification d'état HTTP auquel il doit correspondre, c'est-à-dire à une application réelle sur le système dorsal. Dans ce scénario, vous pouvez utiliser l'utilitaire curl pour effectuer des tests à 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 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 votre serveur dorsal utilise HTTPS, vous devez vous servir du protocole TCP.

  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 un serveur dorsal qui retourne un code de statut 302 alors que le code de statut 200 est attendu. 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:nnn,expected:200 où nnn est 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 - .*

  • 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 mal configuré les groupes de sécurité de réseau, les listes de sécurité ou les pare-feu locaux (par exemple firewalld, iptables ou SELinux). Dans ce scénario, vous pouvez utiliser les utilitaires curl ou netcat pour effectuer un test à 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 de charge HTTP. Par exemple : $ curl -i http://backend_ip_address/health TCP et nc -zvw3 backend_ip_address 443.

Vous pouvez vérifier votre pare-feu local à l'aide de la commande suivante : firewall-cmd --list-all --zone=public.. Si les règles attendues sont manquantes dans votre 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