Server Load Balancer:Dépannage des échecs de contrôle d'intégrité ALB

Description du problème

Le statut Health Check Status d'un écouteur sur une instance ALB est Unhealthy.

Causes

Solutions

Échec des contrôles d'intégrité lors de la configuration initiale

Cause 1 : Paramètres de contrôle d'intégrité incorrects

1. Connectez-vous à la console ALB.

2. Dans la barre de menu supérieure, sélectionnez la région où se trouve l'instance ALB.

3. Dans le volet de navigation de gauche, choisissez ALB > Server Groups.

4. Sur la page Server Groups, localisez le groupe de serveurs associé à l'instance ALB cible, puis cliquez sur l'ID du groupe de serveurs.

5. Sur la page des détails du groupe de serveurs, dans la section Health Check, cliquez sur Modify Health Check.

6. Dans la boîte de dialogue Modify Health Check, vérifiez les paramètres de contrôle d'intégrité. Nous vous recommandons d'utiliser les valeurs par défaut.

   Contrôles d'intégrité pour ALB

Cause 2 : Problèmes liés au port de contrôle d'intégrité

1. Connectez-vous à la console ALB.

2. Dans la barre de menu supérieure, sélectionnez la région où se trouve l'instance ALB.

3. Dans le volet de navigation de gauche, choisissez ALB > Server Groups.

4. Sur la page Server Groups, localisez le groupe de serveurs associé à l'instance ALB cible, puis cliquez sur l'ID du groupe de serveurs.

5. Sur la page des détails du groupe de serveurs, cliquez sur l'onglet Backend Servers pour afficher et noter le port du serveur backend.

6. Sur la page des détails du groupe de serveurs, cliquez sur l'onglet Details, puis dans la section Health Check, cliquez sur Modify Health Check. Dans la boîte de dialogue Modify Health Check, affichez et notez les paramètres de contrôle d'intégrité.

7. Connectez-vous au serveur backend et utilisez la commande nc ou curl pour sonder le serveur.

   Connexion à une instance ECS

   # nc command:
   echo -e "[$Method] [$PATH] [$VERSION]\r\nHost: [$Domain]\r\n\r\n" | nc -t [$IP] [$Port] # Format
   echo -e "HEAD /index.html HTTP/1.0\r\nHost: www.example.org\r\n\r\n" | nc -t 127.0.0.1 80 # Example
   # curl command:
   curl -X [$Method] -H "Host: [$Domain]" -I http://[$IP]:[$Port][$PATH]  # Format
   curl -X HEAD --http1.0 -H "Host: www.example.org" -I http://127.0.0.1:80/index.html # Example

   Remarque

   • [$Method] correspond à la méthode de contrôle d'intégrité configurée pour le groupe de serveurs.

   • [$PATH] correspond au chemin de contrôle d'intégrité configuré pour le groupe de serveurs.

   • [$VERSION] correspond à la version HTTP utilisée pour le contrôle d'intégrité, par exemple HTTP/1.0.

   • [$Domain] correspond au nom de domaine configuré pour le contrôle d'intégrité. Si cette valeur est -----, l'adresse IP privée de chaque instance ECS backend est utilisée par défaut. Dans ce cas, vous pouvez utiliser [$IP] à la place.

   • [$IP] correspond à l'adresse IP privée de l'instance ECS backend.

   • [$Port] correspond au port de contrôle d'intégrité configuré pour le groupe de serveurs. Si aucun port de contrôle d'intégrité n'est configuré manuellement, le port de l'instance ECS backend est utilisé par défaut. Si un port de contrôle d'intégrité est configuré, le port configuré est utilisé.

8. Vérifiez si le code d'état renvoyé indique une réponse normale pour votre service.

   • Si le code d'état est normal mais ne figure pas dans les codes d'état sains que vous avez configurés, ajoutez-le à la configuration du contrôle d'intégrité.

   • Si le code d'état indique une erreur, dépannez le problème à l'aide du tableau suivant.

     Code d'état	Description	Dépannage
     400	Format de requête HTTP invalide provenant du client.	Causes possibles : (1) Erreur de format d'en-tête HTTP, par exemple content-length vide ou une requête HTTP envoyée vers un port HTTPS — vérifiez le format de la requête HTTP. (2) Si une logique métier spécifique renvoie des codes 4xx et provoque des échecs de contrôle d'intégrité, sélectionnez 4xx sous Health Check Response Codes dans la configuration du contrôle d'intégrité pour traiter les codes d'état 4xx comme des réponses normales. Cela empêche la suppression des nœuds backend par les contrôles d'intégrité en raison de codes de retour métier spécifiques.
     403	L'accès est interdit. ALB lui-même ne renvoie pas de codes d'état 403 ; une réponse 403 provient généralement de la configuration du service web backend.	Vérifiez si le service backend (par exemple, Nginx ou Tomcat) dispose de règles de contrôle d'accès qui bloquent les requêtes provenant d'adresses IP sources spécifiques ou de modèles de requête particuliers. Si le backend bloque la source des requêtes de contrôle d'intégrité, les contrôles d'intégrité renvoient continuellement un code 403. Ajustez la configuration du contrôle d'accès du service backend pour autoriser les requêtes de contrôle d'intégrité.
     404	La ressource cible est introuvable. Cela est généralement dû à une inadéquation entre le chemin de contrôle d'intégrité et les chemins réellement disponibles sur le serveur backend.	Dépannez le problème comme suit : Vérifiez le préfixe de chemin exposé par la passerelle backend (par exemple, Nginx), tel que /api/v1, et assurez-vous que le Health Check Path configuré correspond à un chemin réellement accessible sur le backend. Si l'accès direct à l'adresse IP du serveur backend renvoie une réponse normale mais que l'accès via le nom de domaine renvoie un code 404, le service backend effectue généralement une correspondance d'hôte virtuel basée sur le nom de domaine (en-tête Host). Vérifiez que le Health Check Domain configuré pour le contrôle d'intégrité correspond à la configuration de domaine du service backend.
     405	La méthode de requête de contrôle d'intégrité n'est pas prise en charge.	Vérifiez si le service backend prend en charge la méthode de contrôle d'intégrité configurée.
     500	Une erreur interne du serveur s'est produite et la requête ne peut pas être traitée.	Vérifiez la logique métier du service backend.
     503	Le serveur est temporairement indisponible.	Vérifiez la logique métier du service backend ou déterminez si la charge du serveur est trop élevée.

Échecs de contrôle d'intégrité sur une configuration existante

Cause 1 : Interférence de logiciels de sécurité

ALB utilise des adresses IP issues d'un bloc CIDR réservé pour communiquer avec les instances ECS backend. Si ce bloc CIDR est bloqué, les contrôles d'intégrité échouent et ALB ne peut pas transférer les requêtes. L'exemple suivant utilise iptables pour vérifier les blocages sur 100.64.0.0/10.

1. Connectez-vous à l'instance ECS backend concernée et exécutez la commande suivante pour lister les règles de la table de filtrage.

   iptables -nL

   Une sortie similaire à la suivante indique que l'instance ECS backend bloque les requêtes provenant du bloc CIDR ALB.

   [root@xxx Z ~]# iptables -nL
   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination
   DROP       all  --  100.64.0.0/10        0.0.0.0/0
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination
   Chain OUTPUT (policy ACCEPT)
   target     prot opt source               destination
   Chain L (0 references)
   target     prot opt source               destination

2. Exécutez la commande suivante pour supprimer cette règle :

   iptables -t filter -D INPUT -s 100.64.0.0/10 -j DROP

3. Confirmez que le bloc CIDR ALB n'est plus bloqué :

   iptables -nL

En plus des règles iptables, vérifiez les configurations de sécurité suivantes pour vous assurer que le trafic de contrôle d'intégrité ALB peut atteindre le service backend :

1. Vérifiez l'état d'écoute du port sur le serveur backend : Confirmez que le serveur backend écoute sur le port backend configuré dans le groupe de serveurs (par exemple, le port 80). Exécutez la commande suivante pour vérifier l'état d'écoute du port :

   netstat -tlnp | grep <port>
   # Or use the ss command:
   ss -tlnp | grep <port>

   Si le port n'est pas dans l'état LISTEN, vérifiez si le service backend a démarré correctement.

2. Vérifiez les règles entrantes du groupe de sécurité de l'instance ECS backend : Assurez-vous que les règles entrantes du groupe de sécurité autorisent l'accès depuis la source suivante. Sinon, les sondes de contrôle d'intégrité ALB peuvent être bloquées par le groupe de sécurité :

   • Objet d'autorisation (adresse source) : Pour une instance ALB mise à niveau, le bloc CIDR du vSwitch où réside son adresse Local IP ; pour une instance ALB non mise à niveau, le bloc CIDR 100.64.0.0/10.

   • Protocole : TCP

   • Plage de ports : Le port du service backend configuré dans le groupe de serveurs.

Cause 2 : Configuration de routage incorrecte

Une route incorrecte pour le bloc CIDR 100.64.0.0/10 sur une instance ECS backend peut empêcher les réponses de contrôle d'intégrité d'atteindre l'instance ALB. L'exemple suivant utilise la commande Linux route pour vérifier la configuration.

1. Connectez-vous à l'instance ECS backend et exécutez la commande suivante pour vérifier la configuration de routage :

   route -n

   La route est incorrecte si une entrée avec Destination 100.64.0.0 et Genmask 255.192.0.0 possède une Gateway autre que la passerelle par défaut de l'interface réseau (la valeur Gateway où Destination est 0.0.0.0).

   [root@test-server2 ~]# route -n
   Kernel IP routing table
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   0.0.0.0         <Default gateway of eth0>  0.0.0.0         UG    100    0        0 eth0
   xxx             xxx             xxx             xxx   xxx    xxx      xxx xxx
   100.64.0.0      0.0.0.0         255.192.0.0     U     0      0        0 eth0

2. Exécutez la commande suivante pour supprimer la route incorrecte pour le bloc CIDR 100.64.0.0/10 :

   route del -net 100.64.0.0/10

Cause 3 : Charge élevée du serveur backend

Lorsqu'une instance ECS backend manque de ressources, elle peut ne pas répondre aux sondes de contrôle d'intégrité dans le délai d'attente configuré, ce qui entraîne des échecs de contrôle d'intégrité. L'insuffisance des ressources peut résulter d'une surcharge globale du système ou d'un problème spécifique, tel qu'une fuite de connexion, qui épuise progressivement les ressources système. Dépannez les deux sous-scénarios suivants.

Sous-scénario 1 : Surcharge des ressources système

Lorsque le processeur, la mémoire ou les E/S disque sont saturés, le serveur ne peut pas répondre aux sondes de contrôle d'intégrité à temps. Dépannage et gestion d'une charge élevée sur les instances Linux.

Sous-scénario 2 : Fuite de connexion épuisant les ressources (accumulation de CLOSE_WAIT)

Si les instances ECS backend accumulent un grand nombre de connexions TCP CLOSE_WAIT, la cause est généralement que l'application backend (par exemple, un service Java géré par jsvc.exec) n'appelle pas activement close() pour libérer les connexions après le traitement des requêtes. Cela laisse les connexions dans l'état CLOSE_WAIT et provoque leur accumulation au fil du temps. Un nombre excessif de connexions CLOSE_WAIT consomme des ressources système et peut affecter les réponses aux contrôles d'intégrité.

Étapes de dépannage :

1. Connectez-vous à l'instance ECS backend et exécutez la commande suivante pour vérifier le nombre actuel de connexions CLOSE_WAIT :

   netstat -an | grep CLOSE_WAIT | wc -l

3. Si le nombre de connexions CLOSE_WAIT continue d'augmenter ou est anormalement élevé, vérifiez le code de l'application backend ou la configuration du service pour vous assurer que l'application ferme correctement les connexions après le traitement des requêtes (par exemple, en appelant close() ou shutdown()). Pour les frameworks utilisant un pool de connexions, vérifiez les paramètres de délai d'inactivité et de récupération du pool.

FAQ

Pourquoi les serveurs backend reçoivent-ils des requêtes de contrôle d'intégrité à haute fréquence ?

ALB utilise une architecture de cluster distribué multi-zones. Tous les nœuds de transfert du cluster envoient indépendamment des sondes de contrôle d'intégrité aux serveurs backend. Par conséquent, la fréquence réelle des requêtes reçues par un serveur backend est égale à la fréquence par nœud multipliée par le nombre de nœuds. Par exemple, si l'intervalle de contrôle d'intégrité est défini sur 5 secondes et que le cluster contient 10 nœuds de transfert, le serveur backend reçoit environ 10 requêtes de contrôle d'intégrité toutes les 5 secondes, soit près de 2 requêtes par seconde. Il s'agit d'un comportement attendu par conception et n'indique pas un problème.

Si le volume de contrôles d'intégrité affecte les performances du backend, réduisez la fréquence en utilisant l'une des méthodes suivantes :

• Ajustez les paramètres de contrôle d'intégrité : Dans la configuration du contrôle d'intégrité, augmentez l'Health Check Interval (plage : 1–50 secondes) ou augmentez le Healthy Threshold. Notez qu'un intervalle plus long retarde la détection des pannes.

• Passez à un protocole de contrôle d'intégrité de couche 4 : Un contrôle d'intégrité de couche 4 effectue uniquement une poignée de main TCP sans envoyer de requête HTTP, ce qui réduit considérablement le trafic sur les serveurs backend.