Application Load Balancer (ALB) surveille en continu vos serveurs backend à l'aide de vérifications d'état et achemine automatiquement le trafic loin des serveurs défectueux.
Les vérifications d'état sont activées par défaut pour tous les groupes de serveurs et peuvent être configurées indépendamment pour chaque groupe.
Fonctionnement
ALB envoie périodiquement des requêtes de sonde à chaque serveur backend et évalue la réponse. Un serveur doit réussir un nombre consécutif de vérifications, appelé Healthy Threshold (seuil de bon état), avant qu'ALB ne le marque comme sain. Cela permet d'éviter que des fluctuations réseau transitoires ne déclenchent de faux positifs.
Lorsqu'un serveur échoue consécutivement aux vérifications au-delà du Unhealthy Threshold (seuil de mauvais état), ALB cesse d'acheminer de nouvelles requêtes vers celui-ci et les redirige vers des serveurs sains. Lorsque le serveur récupère, ALB le réintègre automatiquement.
Les vérifications d'état utilisent des connexions éphémères qui se ferment immédiatement après chaque sonde.
Comportement en cas de défaillance totale : si tous les serveurs d'un groupe de serveurs échouent simultanément aux vérifications d'état, ALB continue d'acheminer les requêtes vers l'ensemble d'entre eux selon l'algorithme de planification, plutôt que de supprimer totalement le trafic. Cette approche limite les interruptions de service en cas de panne généralisée.
Les serveurs backend dont le poids est de 0 ne participent pas aux vérifications d'état.
Adresses IP source
ALB sonde vos serveurs backend à partir d'adresses IP spécifiques. Assurez-vous que vos serveurs autorisent le trafic provenant de ces adresses, y compris dans les règles iptables, les logiciels de sécurité tiers ou les listes de contrôle d'accès réseau (ACL) du VPC. Si vous bloquez ces adresses IP, les sondes de vérification d'état ne peuvent pas atteindre vos serveurs ; ALB les marque alors comme défectueux et les retire de la rotation d'équilibrage de charge.
|
Type d'instance ALB |
Plage d'adresses IP source |
|
Instance ALB mise à niveau |
Adresses IP privées issues du bloc CIDR du vSwitch (Local IP). Consultez ces adresses sur la page des détails de l'instance. |
|
Instance ALB non mise à niveau |
|
Créer une vérification d'état
Console
Accédez à la page Health CheckHealth Check dans la console ALB.
Sélectionnez la région cible, puis cliquez sur Create Health Check.
Configurez les paramètres suivants et cliquez sur Create.
Paramètres de base
|
Paramètre |
Description |
|
Health Check Name |
Nom attribué à ce modèle de vérification d'état. |
|
Protocol |
Protocole de la sonde. Pour plus de détails, consultez la section Protocols. |
|
Health Check Method |
Méthode HTTP utilisée pour la requête de sonde. S'applique uniquement aux protocoles HTTP, HTTPS et gRPC. |
|
HTTP Version |
HTTP1,0 ou HTTP1,1. S'applique uniquement aux protocoles HTTP et HTTPS. |
|
Port |
Port à sonder. Laissez ce champ vide pour utiliser le port de chaque serveur backend. Valeurs valides : 1–65535. |
|
Path |
Chemin URL à sonder, par exemple |
|
Domain Name |
Valeur de l'en-tête |
Détermination de l'état
|
Paramètre |
Valeur par défaut |
Valeurs valides |
Description |
|
Health Check Status Codes |
|
Consultez la rubrique Health check status codes |
Codes d'état HTTP indiquant qu'un serveur est sain. S'applique uniquement aux protocoles HTTP, HTTPS et gRPC. |
|
Health Check Response Timeout |
5 secondes |
1–300 secondes |
Si le serveur ne répond pas dans ce délai, la vérification est considérée comme ayant échoué. |
|
Health Check Interval |
2 secondes |
1–50 secondes |
Délai entre deux vérifications consécutives. Des intervalles plus longs entraînent une détection plus lente des serveurs défectueux. |
|
Healthy Threshold |
3 |
2–10 |
Nombre de vérifications réussies consécutives requis pour marquer un serveur comme sain. |
|
Unhealthy Threshold |
3 |
2–10 |
Nombre de vérifications échouées consécutives requis pour marquer un serveur comme défectueux. |
Tags et groupe de ressources
|
Paramètre |
Description |
|
Tag Key / Tag Value |
Paires clé-valeur utilisées pour filtrer et gérer les modèles de vérification d'état. |
|
Resource Group |
Groupe de ressources auquel appartient cette vérification d'état. |
Après avoir créé la vérification d'état, sélectionnez-la dans la section Health Check Settings lors de la création d'un groupe de serveurs.
Vous pouvez également configurer les vérifications d'état lors de la création d'un groupe de serveurs et enregistrer la configuration en tant que modèle en sélectionnant Save the health check configurations as a template.
API
Appelez CreateHealthCheckTemplate pour créer un modèle de vérification d'état.
Appelez ApplyHealthCheckTemplateToServerGroup pour l'appliquer à un groupe de serveurs.
Protocols
Méthodes de vérification d'état (HTTP, HTTPS, gRPC)
|
Méthode |
Valeur par défaut pour |
Comportement |
|
HEAD |
HTTP, HTTPS |
Requiert uniquement les en-têtes. Assurez-vous que votre backend prend en charge les requêtes HEAD ; sinon, utilisez GET. |
|
POST |
gRPC |
Assurez-vous que votre backend prend en charge les requêtes POST ; sinon, utilisez GET. |
|
GET |
— |
Les réponses supérieures à 8 Ko sont tronquées, mais cela n'affecte pas le résultat de la vérification d'état. |
Détails des protocoles
|
Protocol |
Mécanisme |
|
HTTP |
ALB envoie des requêtes HEAD ou GET pour vérifier que l'application du serveur backend est saine. |
|
HTTPS |
ALB envoie des requêtes HEAD ou GET pour vérifier que l'application du serveur backend est saine. Pris en charge pour les instances ALB Standard et WAF-enhanced. Non pris en charge pour les instances ALB Basic. |
|
TCP |
ALB envoie des paquets de handshake SYN pour vérifier que le port du serveur backend est disponible. |
|
gRPC |
ALB envoie des requêtes POST ou GET pour vérifier que l'application du serveur backend est saine. |
ALB Extensible Edition prend uniquement en charge les protocoles de vérification d'état HTTP et TCP.
Codes d'état de vérification d'état (HTTP, HTTPS, gRPC)
ALB déclare un serveur sain uniquement lorsque la sonde renvoie l'un des codes d'état configurés.
HTTP/HTTPS : choisissez parmi
http_2xx,http_3xx,http_4xxethttp_5xx. Valeurs par défaut :http_2xxethttp_3xx.gRPC : les codes valides vont de 0 à 99. Spécifiez jusqu'à 20 plages de valeurs, séparées par des virgules.
L'inclusion de http_4xx ou http_5xx dans votre liste de codes d'état retarde la détection des serveurs défectueux. Limitez la liste à http_2xx et http_3xx, et corrigez les problèmes backend provoquant des réponses 4XX ou 5XX.
Modifier une vérification d'état
La désactivation des vérifications d'état signifie qu'ALB ne détecte plus les serveurs défectueux. Si un serveur tombe en panne, le trafic n'est pas automatiquement redirigé vers des serveurs sains.
Si vous spécifiez un intervalle de vérification d'état plus long, ALB mettra plus de temps à détecter les serveurs backend défectueux.
Console
Accédez à la page Health Check dans la console ALB.
Repérez la vérification d'état cible et cliquez sur Modify dans la colonne Actions.
Mettez à jour les paramètres dans la boîte de dialogue Modify Health Check Settings et cliquez sur Save.
Vous pouvez également modifier les vérifications d'état sur la page Server Groups.
API
Appelez UpdateHealthCheckTemplateAttribute pour mettre à jour un modèle de vérification d'état.
Consulter l'état des vérifications d'état
Si votre instance ALB dispose d'écouteurs et que les vérifications d'état sont activées, vous pouvez consulter l'état de santé des serveurs backend dans l'onglet Listener. L'état de vérification d'état d'un écouteur est agrégé à partir de tous les groupes de serveurs associés. Si un serveur backend d'un groupe de serveurs est défectueux, le groupe de serveurs est considéré comme défectueux. Si un groupe de serveurs associé à un écouteur est défectueux, l'état de vérification d'état de l'écouteur s'affiche comme défectueux.
Console
API
Appelez GetListenerHealthStatus pour interroger l'état de vérification d'état d'un écouteur.
Supprimer une vérification d'état
Console
Accédez à la page Health Check dans la console ALB.
Repérez la vérification d'état cible et cliquez sur Delete dans la colonne Actions.
Confirmez la suppression et cliquez sur OK.
API
Appelez DeleteHealthCheckTemplates pour supprimer un modèle de vérification d'état.
Mise en œuvre en production
Créez un endpoint de vérification d'état dédié. Ajoutez une route dédiée, telle que /health, qui renvoie toujours un code HTTP 200. Évitez d'utiliser des chemins métier : ils peuvent renvoyer des erreurs 4XX en raison de l'authentification ou de ressources manquantes, provoquant ainsi des échecs injustifiés.
Corrigez les problèmes backend au lieu d'assouplir les codes d'état. En cas d'échec des vérifications d'état, diagnostiquez et corrigez la cause racine afin que l'endpoint renvoie des codes 2XX ou 3XX. N'ajoutez pas les codes 4XX ou 5XX à la liste des codes d'état acceptés pour contourner le problème.
Ajustez les paramètres à votre environnement. Les paramètres par défaut conviennent à la plupart des scénarios. Pour les services à démarrage lent, augmentez l'Health Check Interval ou le Unhealthy Threshold afin d'éviter de marquer prématurément un serveur en cours de démarrage comme défectueux. Pour les réseaux à latence élevée, augmentez le Health Check Response Timeout.
Simulez les vérifications d'état avec curl. Lors du dépannage, utilisez la commande suivante pour reproduire le comportement de la sonde ALB. Remplacez la méthode, le domaine, l'adresse IP, le port et le chemin pour qu'ils correspondent à votre configuration :
curl -Iv -X HEAD --http1.0 -H "Host: your-domain.com" http://backend_ip:port/health_pathFacturation
Les vérifications d'état n'entraînent aucun frais supplémentaire. Pour plus de détails sur la tarification d'ALB, consultez les informations de facturation ALB.
Quota
Vous pouvez créer jusqu'à 50 modèles de vérification d'état par région. Ce quota ne peut pas être augmenté.