Server Load Balancer:Configurer et gérer les vérifications d'état CLB

Prérequis

Avant de configurer les vérifications d'état, assurez-vous que les services pertinents sont déployés sur vos serveurs backend.

Limites

Le protocole de l'écouteur et le protocole de vérification d'état doivent respecter les règles suivantes :

• Les écouteurs TCP prennent uniquement en charge les protocoles de vérification d'état TCP ou HTTP.

• Les écouteurs UDP prennent en charge les protocoles de vérification d'état TCP, UDP ou HTTP.

• Les écouteurs HTTP et HTTPS prennent uniquement en charge le protocole de vérification d'état HTTP.

Configurer les vérifications d'état

Vous pouvez configurer les vérifications d'état lors de l'ajout d'un écouteur. Dans la plupart des cas, les paramètres de vérification d'état par défaut sont suffisants.

1. Connectez-vous à la console CLB.

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

3. Sur la page Instances, localisez l'instance cible et cliquez sur son ID d'instance.

4. Sur la page des détails de l'instance, cliquez sur l'onglet Listener. Cliquez sur Add Listener, ou cliquez sur Modify Listener dans la colonne Actions de l'écouteur cible.

5. Suivez l'assistant de configuration jusqu'à l'étape Health Check. Les vérifications d'état sont activées par défaut.

6. Cliquez sur Advanced Settings, puis cliquez sur Modify à droite pour configurer les paramètres de vérification d'état.

   Configuration de la vérification d'état	Description
   Health Check Protocol	Sélectionnez un protocole pour les vérifications d'état. Les vérifications d'état TCP fonctionnent au niveau réseau en envoyant des messages de handshake SYN pour vérifier si le port du serveur est actif. Les vérifications d'état UDP utilisent des messages UDP pour obtenir des informations sur l'état. Les vérifications d'état HTTP envoient des requêtes HEAD ou GET pour simuler l'accès d'un navigateur et vérifier si l'application serveur est saine.
   Health Check Method (Prise en charge uniquement pour le protocole de vérification d'état HTTP)	Sélectionnez la méthode HEAD ou GET. Par défaut, la méthode HEAD est utilisée. Remarque Si la méthode HEAD n'est pas prise en charge ou est désactivée, utilisez plutôt la méthode GET. Si vous utilisez la méthode GET, les réponses dépassant 8 Ko sont tronquées. Cela n'affecte pas le résultat de la vérification d'état.
   Health Check Port	Le port utilisé pour les vérifications d'état sur les serveurs backend. Par défaut, CLB utilise le port de chaque serveur backend. Remarque Si les serveurs backend d'un groupe de serveurs utilisent des ports différents, ne spécifiez pas de port de vérification d'état. Dans ce cas, CLB utilise le port de chaque serveur backend pour les vérifications d'état.
   Health Check Path (Prise en charge uniquement pour le protocole de vérification d'état HTTP)	Par défaut, CLB envoie une requête HTTP à la page d'index par défaut de votre application pour les vérifications d'état. Si la page utilisée pour les vérifications d'état n'est pas la page d'index par défaut de votre application, spécifiez le chemin exact. Nous vous recommandons d'utiliser une page statique pour les vérifications d'état.
   Health Check Domain Name (Optional) (Prise en charge uniquement pour le protocole de vérification d'état HTTP)	Lorsque vous configurez un domaine de vérification d'état, CLB définit le champ Host dans l'en-tête de la requête sur ce domaine. Si aucun domaine n'est configuré, le champ Host est omis. Certains serveurs d'applications valident le champ Host. Si aucun domaine n'est configuré, les requêtes peuvent être rejetées, ce qui peut entraîner l'échec des vérifications d'état. Si votre serveur valide le champ Host, vous devez configurer un domaine de vérification d'état pour garantir le succès des vérifications. Remarque Lors de l'exécution d'une vérification d'état, l'équilibreur de charge ignore les règles de transfert et envoie des requêtes au chemin de vérification d'état configuré sur l'écouteur (le chemin racine par défaut). Si vos services backend répondent différemment selon le chemin de la requête, les vérifications d'état envoyées au chemin par défaut ou à un chemin non correspondant peuvent échouer. Vous pouvez configurer un chemin de vérification d'état personnalisé pour chaque règle de transfert selon vos besoins.
   Healthy Status Codes (Prise en charge uniquement pour le protocole de vérification d'état HTTP)	Sélectionnez les codes d'état HTTP indiquant qu'un serveur backend est sain. Les valeurs par défaut sont http_2xx et http_3xx. Vous pouvez sélectionner http_2xx, http_3xx, http_4xx ou http_5xx. Par défaut, CLB considère uniquement les codes d'état HTTP 2xx et 3xx comme sains. Si votre serveur backend renvoie un code d'état 4xx, tel que 400, 403 ou 404, ou un code d'état 5xx, tel que 500, 502 ou 503, la vérification d'état échoue. Ensuite, CLB marque le serveur backend comme anormal et cesse de transférer le trafic vers ce serveur. Avertissement Si vous acceptez les codes d'état 4xx ou 5xx comme sains, les instances défaillantes peuvent ne pas être rapidement retirées du pool de serveurs backend. Par exemple, si un serveur backend renvoie une erreur 500 et que vous avez configuré http_5xx comme code d'état normal, CLB continue d'acheminer le trafic vers l'instance défaillante. N'utilisez ce paramètre qu'après une évaluation attentive. Nous vous recommandons de vous assurer que votre serveur backend renvoie un code d'état 2xx ou 3xx dans la mesure du possible. Causes courantes des erreurs 4xx : Erreur 404 : Le chemin de vérification d'état n'existe pas, le service backend n'est pas correctement déployé, il existe un problème de liaison de domaine ou la méthode HEAD n'est pas prise en charge. Erreur 403 : Le serveur backend refuse l'accès, des restrictions basées sur l'adresse IP sont en place ou la vérification des autorisations échoue. Erreur 400 : L'en-tête Host est manquant, la version HTTP est incompatible ou la requête est mal formée.
   Health Check Response Timeout	La durée maximale d'attente d'une réponse à une vérification d'état. Si un serveur backend ne renvoie pas de réponse dans le délai d'attente spécifié, la vérification d'état échoue.
   Health Check Interval	L'intervalle entre les vérifications d'état. Tous les nœuds du cluster CLB effectuent indépendamment des vérifications d'état à l'intervalle spécifié. Étant donné que les vérifications d'état provenant de différents nœuds ne sont pas synchronisées, les requêtes de vérification d'état reçues par un serveur backend peuvent ne pas être espacées uniformément. Par défaut, les vérifications d'état HTTP utilisent la méthode HEAD. Les requêtes HEAD renvoient uniquement le code d'état HTTP et les en-têtes, et non le contenu complet de la page. Par conséquent, chaque vérification d'état impose une charge minimale aux serveurs backend. Si vous réduisez l'intervalle, le nombre de requêtes de vérification d'état augmente. Toutefois, la surcharge est généralement négligeable par rapport au trafic de service normal.
   Healthy Threshold	Le nombre de vérifications d'état réussies consécutives nécessaires pour qu'une instance Elastic Compute Service défaillante soit considérée comme saine.
   Unhealthy Threshold	Le nombre de vérifications d'état échouées consécutives après lequel une instance Elastic Compute Service est considérée comme non saine.
   Health Check Request et Health Check Result (Prise en charge uniquement pour le protocole de vérification d'état UDP)	Lorsque vous configurez des vérifications d'état pour un écouteur UDP, saisissez le contenu de la requête (par exemple, youraccountID) dans le champ Health Check Request et la réponse attendue (par exemple, slb123) dans le champ Health Check Result. Ajoutez également une logique à votre application backend pour gérer les réponses de vérification d'état, par exemple en la configurant pour répondre avec slb123 aux requêtes contenant youraccountID. CLB considère une vérification d'état comme réussie uniquement s'il reçoit la réponse correcte. Cette méthode maximise la fiabilité des vérifications d'état UDP.

7. Cliquez sur Next jusqu'à ce que l'écouteur soit configuré.

Consulter l'état des vérifications d'état

1. Connectez-vous à la console CLB.

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

3. Sur la page Instances, recherchez l'instance cible et cliquez sur son ID d'instance.

4. Sur la page des détails de l'instance, cliquez sur l'onglet Listener pour consulter l'état des vérifications d'état de chaque écouteur.

   L'état de la vérification d'état peut être l'un des suivants :

   • Initializing : La liste des serveurs backend est en cours d'initialisation pour les vérifications d'état.

   • Healthy : Tous les serveurs backend sont sains.

   • Error : Un ou plusieurs serveurs backend ne sont pas sains.

   • Disabled : Les vérifications d'état ne sont pas activées.

5. Cliquez sur Error ou Initializing à côté d'un écouteur pour afficher les détails, y compris l'écouteur ou la règle de transfert concerné(e), le groupe de serveurs, l'instance ECS et le port, l'état de santé et la raison de l'échec.

Désactiver les vérifications d'état

Vous pouvez désactiver les vérifications d'état. Toutefois, si une instance ECS backend devient anormale après la désactivation des vérifications d'état, CLB continue d'acheminer les requêtes vers cette instance. Cela entraîne une indisponibilité partielle du service. Par conséquent, nous vous recommandons de ne pas désactiver les vérifications d'état.

1. Connectez-vous à la console CLB.

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

3. Sur la page Instances, recherchez l'instance cible et cliquez sur son ID d'instance.

4. Sur la page des détails de l'instance, cliquez sur l'onglet Listener. Cliquez sur Add Listener, ou cliquez sur Modify Listener dans la colonne Actions de l'écouteur cible.

5. Suivez l'assistant de configuration jusqu'à l'étape Health Check.

6. Désactivez le commutateur de vérification d'état, cliquez sur Next, puis confirmez les modifications.

Bonnes pratiques pour les vérifications d'état

Pour garantir des vérifications d'état précises et fiables, nous vous recommandons de suivre ces bonnes pratiques :

• Créer un endpoint de vérification d'état dédié : Créez un endpoint de vérification d'état dédié sur votre serveur backend, tel que /health, qui renvoie toujours un code d'état HTTP 200. Évitez d'utiliser des chemins métier, tels que /, pour les vérifications d'état, car ils peuvent renvoyer des codes d'état 4xx en raison de vérifications d'autorisation ou de ressources manquantes.

• Prioriser la résolution des problèmes backend : Si les vérifications d'état renvoient des codes d'état inattendus, diagnostiquez et corrigez d'abord les problèmes du service backend pour vous assurer que le chemin de vérification d'état renvoie un code d'état 2xx ou 3xx. Ne vous contentez pas d'assouplir les critères des codes d'état normaux.

• Simuler les vérifications d'état à l'aide de curl : Lors du dépannage, connectez-vous à un serveur backend et exécutez la commande suivante pour simuler les vérifications d'état CLB :

  curl -Iv -X HEAD --http1.0 -H "Host: your-domain.com" http://127.0.0.1:80/health_path

  Dans cette commande, HEAD est la méthode de vérification d'état, your-domain.com est le domaine de vérification d'état et /health_path est le chemin de vérification d'état. Si aucun domaine n'est configuré, omettez le paramètre -H.

• S'assurer que les blocs CIDR de CLB ne sont pas bloqués : CLB utilise le bloc CIDR 100.64.0.0/10 pour communiquer avec les serveurs backend lors des vérifications d'état. Assurez-vous que ce bloc CIDR n'est pas bloqué par iptables ou d'autres règles de pare-feu.

Références

• Si vous n'êtes pas familier avec le mécanisme de vérification d'état de CLB, consultez la rubrique Vérifications d'état CLB.

• Si vous rencontrez des problèmes avec les vérifications d'état CLB, consultez la rubrique FAQ sur les vérifications d'état CLB pour le dépannage.

• Vous pouvez utiliser la fonctionnalité de journal des vérifications d'état de CLB pour analyser les journaux de vérification d'état des serveurs. Pour plus d'informations, consultez la rubrique Stocker et télécharger les journaux de vérification d'état.