Server Load Balancer:Dépannage des échecs de contrôle d'état NLB

Symptômes

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

Causes

Solutions

Les contrôles d'état échouent après la configuration initiale

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

1. Connectez-vous à la console NLB.

2. Dans la barre de navigation supérieure, sélectionnez la région dans laquelle l'instance NLB est déployée.

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

4. Sur la page Server Groups, localisez le groupe de serveurs associé à l'instance NLB cible, puis cliquez sur Modify Health Check Settings.

5. Dans la boîte de dialogue Modify Health Check Settings, vérifiez que les paramètres de contrôle d'état sont corrects. Il est recommandé d'utiliser les paramètres par défaut.

Cause 2 : Problèmes liés au port de l'écouteur

1. Vérifiez le port de contrôle d'état.

1. Connectez-vous à la console NLB.

2. Dans la barre de navigation supérieure, sélectionnez la région dans laquelle l'instance NLB est déployée.

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

4. Sur la page Server Groups, recherchez le groupe de serveurs attaché à l'instance NLB 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 les ports des serveurs backend.

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

2. Vérifiez que l'application s'exécute sur le serveur backend et utilise le bon port de contrôle d'état. Cette section utilise un service Nginx comme exemple.

1. Connectez-vous au serveur backend dont l'état est unhealthy et exécutez la commande suivante pour vérifier l'état du service Nginx.

   systemctl status nginx

2. Une réponse similaire à la suivante indique que le service ne s'exécute pas.

   ● nginx.service - The nginx HTTP and reverse proxy server
      Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

3. Exécutez la commande suivante pour démarrer le service Nginx.

   systemctl start nginx

4. Exécutez à nouveau la commande suivante pour vérifier l'état du service Nginx.

   systemctl status nginx

   Une réponse similaire à la suivante indique que le service est en cours d'exécution.

   ● nginx.service - The nginx HTTP and reverse proxy server
      Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
      Active: active (running) since Mon xxx CST; 2h 20min ago

5. Connectez-vous à la console Network Load Balancer (NLB) et effectuez les étapes suivantes.

   1. Dans le volet de navigation de gauche, choisissez NLB > Server Groups.

   2. Sur la page Server Groups, localisez le groupe de serveurs cible et cliquez sur Modify Health Check Settings dans la colonne Actions.

   3. Dans la boîte de dialogue Modify Health Check Settings, vérifiez le port de contrôle d'état [$Port]. Confirmez que l'option Health Check est activée, que le protocole Health Check Protocol est TCP et que le port Health Check Port est 80.

   4. Vérifiez l'état du contrôle d'état. S'il est toujours unhealthy, exécutez la commande suivante pour vérifier le port d'écoute du service Nginx.

      netstat -tanp |grep nginx

6. Si la sortie est similaire à la suivante, le port d'écoute ne correspond pas à la valeur [$Port].

   tcp        0      0 0.0.0.0:81              0.0.0.0:*               LISTEN      22855/nginx: master
   tcp6       0      0 :::81                   :::*                    LISTEN      22855/nginx: master

   Modifiez le fichier /etc/nginx/nginx.conf. Recherchez et modifiez la valeur listen pour la définir sur [$Port], puis enregistrez et quittez.

   Remarque

   Si vous ne pouvez pas modifier la valeur listen en raison de votre cas d'utilisation, vous pouvez modifier le port de contrôle d'état pour le protocole correspondant. Pour plus d'informations, consultez la rubrique Écouteurs NLB.

   server {
       listen       80;
       listen       [::]:80;
       server_name  _;
       root         /usr/share/nginx/html;
       # Load configuration files for the default server block.
       include /etc/nginx/default.d/*.conf;
   }

7. Exécutez la commande suivante pour redémarrer le service Nginx. Après un court instant, confirmez que le contrôle d'état est normal.

   systemctl restart nginx

Les contrôles d'état échouent après avoir fonctionné correctement

Cause 1 : Problèmes liés aux logiciels de sécurité

L'instance NLB utilise un bloc CIDR VPC pour communiquer avec les serveurs backend. Les logiciels de sécurité installés sur vos serveurs backend, tels qu'iptables ou tout autre logiciel de politique de sécurité tiers, ne doivent pas bloquer le trafic provenant de ce bloc CIDR. Le blocage du trafic entraîne des échecs de contrôle d'état et empêche le bon fonctionnement de NLB. Cette section utilise iptables comme exemple pour vérifier les plages d'adresses IP privées bloquées.

1. Connectez-vous à la console Network Load Balancer (NLB) et affichez l'adresse IP locale que l'instance NLB utilise pour communiquer avec les serveurs backend.

   Dans la liste des instances, localisez l'instance cible et affichez l'adresse IP dans la colonne Local IP, par exemple 192.168.20.75.

2. Connectez-vous à l'instance de serveur backend dont l'état est unhealthy et exécutez la commande suivante pour afficher toutes les règles de la table de filtrage.

   iptables -nL

   Une réponse similaire à la suivante indique que le serveur backend refuse les requêtes provenant de l'adresse IP locale de l'instance NLB.

   # iptables  -nL
   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination
   DROP       all  --  192.168.20.75        0.0.0.0/0
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination
   Chain OUTPUT (policy ACCEPT)
   target     prot opt source               destination

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

   iptables -t filter -D INPUT -s 192.168.20.75 -j DROP  # The IP address is for demonstration purposes only.

   Remarque

   Remplacez l'adresse IP dans la commande par l'adresse IP privée utilisée par votre instance NLB.

4. Exécutez la commande suivante pour confirmer que les requêtes provenant de la plage d'adresses IP privées NLB ne sont plus bloquées.

   iptables -nL

5. Confirmez que le statut Health Check Status de l'écouteur NLB passe à Healthy.

Cause 2 : Configuration de routage incorrecte

Une route incorrecte sur le serveur backend pour le bloc CIDR VPC utilisé par l'instance NLB peut empêcher l'instance NLB de recevoir les sondes de contrôle d'état, ce qui provoque des échecs. Cette section utilise la commande Linux route comme exemple pour vérifier la configuration de routage.

1. Connectez-vous à la console Network Load Balancer (NLB) et affichez l'adresse IP locale que l'instance NLB utilise pour communiquer avec les serveurs backend.

2. Connectez-vous au serveur backend dont l'état est unhealthy et exécutez la commande suivante pour vérifier la configuration de routage actuelle.

   route -n

   La configuration de routage est incorrecte si une entrée de route existe où la destination est l'adresse IP locale de l'instance NLB, le masque de sous-réseau (Genmask) est 255.255.255.255 et la passerelle (Gateway) n'est pas la passerelle par défaut de l'interface réseau. La passerelle par défaut est l'adresse IP répertoriée dans la colonne Gateway lorsque la destination est 0.0.0.0.

   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   0.0.0.0         xxx             0.0.0.0         UG    0      0        0 eth0
   xxx             0.0.0           255.255.0.0     U     1002   0        0 xxx
   192.168.20.75   0.0.0.0         255.255.255.255 UH    0      0        0 *

3. Exécutez la commande suivante pour supprimer la route incorrecte.

   ip route del blackhole 192.168.20.75 # The IP address is for demonstration purposes only.

   Remarque

   Remplacez l'adresse IP dans la commande par l'adresse IP privée utilisée par votre instance NLB.

4. Confirmez que le statut Health Check Status de l'écouteur NLB passe à Healthy.

Cause 3 : Charge élevée du serveur backend

Consultez la rubrique Dépannage et résolution des problèmes de charge élevée sur les instances Linux pour déterminer si une charge serveur élevée est à l'origine de l'échec.

Cause 4 : Limite de connexions atteinte sur le serveur backend

Lorsqu'un serveur backend (tel qu'un pod ACS) atteint sa limite de connexions TCP, il ne peut plus accepter de nouvelles connexions. Si NLB est configuré avec des contrôles d'état TCP, la sonde de contrôle d'état échoue car le backend ne peut pas accepter la nouvelle connexion, et NLB marque automatiquement le backend comme Unhealthy.

• Un backend Unhealthy ne reçoit pas de nouvelles connexions. Les connexions persistantes existantes ne sont pas affectées et continuent de fonctionner normalement.

• Ce comportement déclenche des alertes Unhealthy. Configurez des alertes de seuil de nombre de connexions dans Cloud Monitor pour recevoir un avertissement préalable avant d'atteindre la limite de connexions.

• Lorsque le backend récupère et peut à nouveau accepter de nouvelles connexions, les contrôles d'état réussissent automatiquement et NLB marque à nouveau le backend comme Healthy, reprenant ainsi le transfert des nouvelles connexions.

Références

Vous pouvez également utiliser la fonctionnalité de diagnostic des instances NLB pour résoudre les problèmes d'échec de contrôle d'état NLB. Pour plus d'informations, consultez la rubrique Diagnostic des instances NLB.