Server Load Balancer:FAQ sur les vérifications d'état CLB

Cette rubrique répond aux questions suivantes :

Comment fonctionnent les vérifications d'état ?

Les vérifications d'état confirment l'état du serveur en envoyant des requêtes périodiques.

CLB est déployé dans un cluster. Les nœuds de ce cluster effectuent à la fois le transfert de données et les vérifications d'état. Si un serveur backend échoue à une vérification d'état, CLB cesse de distribuer de nouvelles requêtes clientes à ce serveur non sain.

CLB utilise le bloc CIDR 100.64.0.0/10 pour les vérifications d'état. Vos serveurs backend ne doivent pas bloquer le trafic provenant de cette plage d'adresses. Vous n'avez pas besoin d'ajouter une règle d'autorisation dans votre groupe de sécurité ECS, mais si vous avez configuré d'autres politiques de sécurité telles qu'iptables, vous devez autoriser le trafic provenant de ce bloc CIDR. La plage 100.64.0.0/10 est un espace d'adressage réservé Alibaba Cloud et ne présente aucun risque de sécurité.

Pour plus d'informations, consultez Vérifications d'état CLB.

Quelles sont les configurations de vérification d'état recommandées ?

Nous recommandons les configurations de vérification d'état suivantes.

Pour éviter que des changements d'état fréquents n'affectent la disponibilité du système, une vérification d'état ne change de statut qu'après avoir réussi ou échoué plusieurs fois consécutives dans une fenêtre de temps. Pour plus d'informations, consultez Configurer et gérer les vérifications d'état CLB.

Puis-je désactiver les vérifications d'état ?

Oui. Pour plus d'informations, consultez Désactiver les vérifications d'état.

Comment choisir une méthode de vérification d'état pour un écouteur TCP ?

Les écouteurs TCP prennent en charge les méthodes de vérification d'état HTTP et TCP :

• La méthode TCP vérifie que le port du serveur est actif en envoyant des paquets SYN pour effectuer une poignée de main basique en trois étapes.

• La méthode HTTP envoie des requêtes HEAD ou GET pour simuler l'accès via un navigateur et vérifier si l'application du serveur est saine.

Les vérifications d'état TCP consomment moins de ressources serveur. Si vos serveurs backend sont très sensibles à la charge et que vous avez uniquement besoin de confirmer la disponibilité du port, choisissez la méthode TCP. Si vous devez confirmer plus précisément l'état de santé de l'application, choisissez la méthode HTTP.

Que se passe-t-il si je définis le poids d'une instance ECS sur zéro ?

La définition du poids d'une instance ECS backend sur 0 empêche CLB de lui transférer du trafic, bien que les vérifications d'état continuent de réussir. Cette pratique est courante lors d'une maintenance planifiée, telle que des redémarrages ou des modifications de configuration.

Méthode par défaut pour les vérifications d'état HTTP

La méthode HEAD.

curl -v -0 -I -H "Host:" -X HEAD http://IP:port

Adresses IP source des vérifications d'état

Les vérifications d'état CLB utilisent le bloc CIDR 100.64.0.0/10. Vous devez vous assurer que vos serveurs backend ne bloquent pas ce bloc CIDR. Vous n'avez pas besoin d'ajouter une règle d'autorisation spécifique dans votre groupe de sécurité ECS, mais si vous utilisez d'autres politiques de sécurité comme iptables, vous devez autoriser le trafic provenant de ce bloc. Le bloc CIDR 100.64.0.0/10 est un espace d'adressage réservé utilisé par Alibaba Cloud et ne présente aucun risque de sécurité.

Quand une vérification d'état CLB commence-t-elle ?

Une vérification d'état CLB commence immédiatement après sa configuration pour un écouteur, en envoyant des requêtes périodiques à l'intervalle de vérification d'état spécifié.

Échec de vérification d'état dû à une base de données défaillante

• Symptôme

  Une instance ECS héberge deux sites web : www.example.com (un site web statique) et aliyundoc.com (un site web dynamique), et les deux sont configurés avec l'équilibrage de charge. Un problème avec le service de base de données backend provoque une erreur 502 lorsque vous accédez à www.example.com.

• Cause

  La vérification d'état est configurée avec le domaine de vérification d'état aliyundoc.com. Une défaillance de l'instance ApsaraDB RDS backend ou d'une base de données autogérée rend aliyundoc.com inaccessible, ce qui entraîne l'échec de la vérification d'état pour l'ensemble du serveur backend.

• Solution

  Modifiez le domaine de vérification d'état dans la configuration de votre écouteur CLB pour utiliser un domaine statique qui ne dépend pas de la base de données, tel que www.example.com.

Erreurs de connexion malgré des vérifications d'état TCP réussies

• Symptôme

  Après avoir configuré un écouteur TCP sur CLB, les journaux de l'application backend affichent fréquemment des erreurs de connexion réseau. L'analyse de la capture de paquets révèle que les requêtes proviennent des serveurs CLB, qui envoient activement des paquets RST pour mettre fin à la connexion.

  java.io.IOException  Connection reset by peer
  	at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
  	at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
  	at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
  	at sun.nio.ch.IOUtil.read(IOUtil.java:192)
  	at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
  	at io.netty.buffer.UnpooledUnsafeDirectByteBuf.setBytes(UnpooledUnsafeDirectByteBuf.java:446)
  	at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:871)
  	at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:225)
  	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:115)
  	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
  	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
  	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
  	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
  	at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
  	at java.lang.Thread.run(Thread.java:745)

• Cause

  Ce problème est dû au mécanisme de vérification d'état TCP. CLB vérifie l'état du port d'un écouteur TCP en effectuant une négociation en trois temps (three-way handshake), puis en envoyant immédiatement un paquet RST pour fermer la connexion. Le processus se déroule comme suit :

  1. Le serveur CLB envoie un paquet SYN au serveur backend.

  2. Le serveur backend répond par un paquet SYN+ACK.

  3. Après réception de la réponse, le serveur CLB considère le port comme sain et marque la vérification d'état comme réussie.

  4. Le serveur CLB envoie un paquet RST pour mettre fin à la connexion sans envoyer aucune donnée applicative.

  Étant donné que la connexion est interrompue immédiatement après une vérification d'état réussie, certains frameworks d'application (comme un pool de connexions Java) peuvent interpréter cela comme une anomalie de connexion, ce qui entraîne des erreurs telles que Connection reset by peer.

• Solution

  • Modifiez le protocole de vérification d'état de l'écouteur de TCP vers HTTP.

  • Au niveau de l'application, filtrez les entrées de journal provenant du bloc CIDR de vérification d'état de CLB (100.64.0.0/10) afin d'ignorer ces erreurs attendues.

Échecs des vérifications d'état sur un serveur sain

• Symptôme

  Les vérifications d'état HTTP de l'écouteur CLB échouent systématiquement, mais un test direct du serveur backend avec la commande curl renvoie un code d'état normal.

• Cause

  Une vérification d'état échoue si le code de réponse HTTP du serveur ne correspond pas aux codes d'état attendus dans la configuration de l'écouteur. Par exemple, si vous configurez http_2xx comme code d'état attendu, toute réponse non-2xx du serveur backend est considérée comme un échec de la vérification d'état.

  Dans une configuration Tengine/Nginx, la commande curl s'exécute sans problème, mais la commande echo correspond au site par défaut, ce qui entraîne le renvoi d'une erreur 404 pour le fichier de test test.html.

  [root@iZ28sxxxZ home]# echo -e "HEAD /test.html HTTP/1.0\r\n\r\n" | nc -t 10.161.93.136 80
  HTTP/1.1 404 Not Found
  Server: Tengine/2.1.0
  Date: Mon, 16 Feb 2015 07:29:32 GMT
  Content-Type: text/html
  Content-Length: 585
  Connection: close
  
  [root@iZ28sxxxZ home]# curl -I http://10.161.93.136/test.html
  HTTP/1.1 200 OK
  Server: Tengine/2.1.0
  Date: Mon, 16 Feb 2015 07:29:41 GMT
  Content-Type: text/html
  Content-Length: 5
  Last-Modified: Mon, 16 Feb 2015 07:27:00 GMT
  Connection: keep-alive
  ETag: "54e19bc4-5"
  Accept-Ranges: bytes

• Solution

  • Dans le fichier de configuration principal de votre serveur web, commentez ou configurez correctement l'hôte virtuel par défaut.

  • Spécifiez un domaine de vérification d'état dans la configuration de vérification d'état de l'écouteur CLB afin de garantir que les requêtes sont acheminées vers l'hôte virtuel correct.

Incohérence de la fréquence des vérifications d'état dans les journaux

Le service de vérification d'état de CLB s'exécute sur un cluster de nœuds pour éviter les points de défaillance uniques. Chaque nœud du cluster effectue indépendamment les vérifications d'état. Cette architecture augmente le nombre total de requêtes de vérification d'état envoyées à vos serveurs backends. Par conséquent, la fréquence des entrées de vérification d'état dans les journaux de votre serveur web sera supérieure à celle que vous avez configurée dans la console. Il s'agit d'un comportement attendu.

Comment séparer les journaux de vérification d'état des journaux d'application ?

• Symptôme

  Les journaux des requêtes de vérification d'état sont mélangés aux journaux du trafic applicatif normal, ce qui rend les fichiers journaux volumineux et difficiles à analyser.

• Cause

  Les vérifications d'état envoient des requêtes HTTP, TCP ou UDP pour tester la disponibilité des serveurs backends. Ces requêtes sont enregistrées par le service backend comme tout autre trafic, ce qui les mélange aux journaux d'application.

• Solution

  • Réduire la fréquence des vérifications d'état : Augmentez l'intervalle de vérification d'état pour générer moins d'entrées de journal de vérification d'état.

  • Utiliser un chemin de vérification d'état dédié (pour les vérifications d'état HTTP) : Définissez le chemin de vérification d'état sur un chemin dédié et non métier, tel que /health. Vous pouvez ensuite filtrer vos journaux par chemin de requête pour séparer le trafic de vérification d'état.

  • Désactiver les vérifications d'état (non recommandé) : Si vous êtes certain que les vérifications d'état ne sont pas nécessaires pour votre cas d'utilisation, vous pouvez les désactiver pour arrêter la génération de journaux de vérification d'état.

Comment résoudre les problèmes liés à un échec de vérification d'état ?

Les vérifications d'état déterminent si les serveurs backends fonctionnent correctement. Lorsqu'une vérification d'état échoue, cela indique souvent un problème avec le serveur backend, mais une configuration incorrecte de la vérification d'état peut également provoquer des échecs. Suivez ces étapes pour résoudre le problème.

1. Étape 1 : Vérifiez que le bloc CIDR 100.64.0.0/10 n'est pas bloqué.

   Assurez-vous que vos serveurs backends ne bloquent pas le bloc CIDR 100.64.0.0/10 via iptables ou d'autres logiciels pare-feu ou de sécurité tiers. CLB utilise des adresses IP issues du bloc CIDR interne réservé 100.64.0.0/10 pour communiquer avec les serveurs backends. Si ce bloc CIDR est bloqué, des exceptions de vérification d'état se produiront.

2. Étape 2 : Sondez le service backend en fonction du protocole de l'écouteur.

   Choisissez la méthode de sondage appropriée en fonction du type d'écouteur :

   Couche 4 (TCP/UDP)

   Dans la console CLB, accédez à la page des détails de l'écouteur et vérifiez la configuration de la vérification d'état. Confirmez le Health Check Port, qui correspond par défaut au port du serveur backend. Ensuite, depuis une machine ayant accès au serveur, exécutez la commande telnet pour tenter une connexion au port de vérification d'état :

   telnet 172.17.58.131 80

   Remplacez 172.17.58.131 par l'adresse IP privée du serveur backend et 80 par le port de vérification d'état réel.

   • Cas normal : Renvoie Connected to xxx.xxx.xxx.xxx, indiquant que le port spécifié sur le serveur backend fonctionne correctement et que la vérification d'état est normale.

   • Résultat inattendu : La commande échoue avec un message « Connection refused » ou « Unable to connect ». Cela indique qu'aucun processus n'écoute sur ce port. Vérifiez que votre service backend est en cours d'exécution et qu'il écoute sur le même port que celui spécifié dans la configuration de la vérification d'état.

   Si un écouteur de couche 4 utilise la méthode HTTP pour les vérifications d'état, reportez-vous aux étapes de dépannage de l'onglet « Couche 7 (HTTP/HTTPS) ».

   Couche 7 (HTTP/HTTPS)

   Dans la console CLB, accédez à la page des détails de l'écouteur pour afficher la configuration de la vérification d'état de couche 7 et confirmez le Health Check Port, le Health Check Domain Name et le Health Check Path. Ensuite, depuis un serveur backend (par exemple, un système Linux), exécutez la commande nc ou curl pour sonder le service HTTP backend. Le chemin, le port et le domaine de vérification d'état doivent correspondre à la configuration réelle sur le serveur backend. Sinon, les vérifications d'état échoueront.

   Exemple utilisant la commande nc :

   echo -e "HEAD /test.html HTTP/1.0\r\nHost: www.slb-test.com\r\n\r\n" | nc -t 172.17.58.131 80

   Remplacez le chemin, le domaine, l'adresse IP et le port par les valeurs de votre environnement.

   • Cas normal : Un code d'état 200 ou un autre code 2xx/3xx est renvoyé, indiquant que le service HTTP backend est sain et que la vérification d'état a réussi.

   • Situation anormale : Un code d'erreur tel que 404 est renvoyé et ne correspond pas aux codes d'état 2xx/3xx configurés pour l'écouteur CLB. Vérifiez si la ressource située au chemin de vérification d'état existe, si le domaine de vérification d'état est configuré sur le serveur backend et si le port de vérification d'état est correct.

Pourquoi ne puis-je pas trouver d'enregistrements d'échec de vérification d'état CLB dans la console ?

Les journaux de vérification d'état sont générés une fois par heure et conservés par défaut pendant seulement 3 jours. Si l'état de vérification d'état d'un écouteur CLB ne change pas dans un délai de 3 jours, aucun journal de vérification d'état n'est généré. Vous pouvez stocker les journaux de vérification d'état dans OSS pour une conservation plus longue.