CLB utilise des contrôles d'intégrité pour déterminer la disponibilité des serveurs backend. Si un serveur backend devient défectueux, CLB cesse de lui envoyer des requêtes et les distribue plutôt aux serveurs sains. Lorsque le serveur récupère, CLB reprend le transfert du trafic vers celui-ci. Ce mécanisme de contrôle d'intégrité améliore la disponibilité globale du service en empêchant les pannes de serveurs individuels d'affecter votre application.
Si votre service est sensible à la charge, des contrôles d'intégrité fréquents peuvent impacter le trafic normal du service. Vous pouvez réduire cet impact en diminuant la fréquence des contrôles d'intégrité, en augmentant l'intervalle entre les contrôles ou en passant des contrôles de couche 7 aux contrôles de couche 4. Toutefois, afin de garantir la continuité de la disponibilité du service, nous vous recommandons de ne pas désactiver les contrôles d'intégrité.
Processus de contrôle d'intégrité
Les contrôles d'intégrité confirment l'état des serveurs en envoyant des requêtes périodiques.
CLB est déployé dans un cluster. Les nœuds au sein de ce cluster effectuent à la fois le transfert de données et les contrôles d'intégrité. Si un serveur backend échoue à un contrôle d'intégrité, CLB arrête de distribuer de nouvelles requêtes client à ce serveur défectueux.
CLB utilise le bloc CIDR 100.64.0.0/10 pour les contrôles d'intégrité. 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é.
Bonnes pratiques pour la protection du groupe de sécurité des instances ECS backend
Pour empêcher les attaquants de contourner CLB et d'accéder directement à l'adresse IP publique d'une instance ECS backend, nous vous recommandons de configurer des règles entrantes pour le groupe de sécurité ECS. Ces règles doivent autoriser le trafic vers vos ports de service uniquement depuis les blocs CIDR nécessaires et rejeter les requêtes directes provenant d'Internet. Nous recommandons la configuration suivante :
Le bloc CIDR 100.64.0.0/10, utilisé pour les contrôles d'intégrité CLB et le transfert de trafic, n'est pas restreint par les règles entrantes du groupe de sécurité ECS backend. Vous n'avez pas besoin d'ajouter une règle d'autorisation spécifique pour ce bloc CIDR, car le trafic de CLB vers les instances ECS backend est toujours autorisé.
Dans les règles entrantes du groupe de sécurité ECS, autorisez l'accès à vos ports de service (tels que 80 et 443) uniquement depuis le bloc CIDR de votre VPC. N'autorisez pas l'accès à vos ports de service depuis Internet (0.0.0.0/0).
Une fois cette configuration terminée, le groupe de sécurité bloque les requêtes directes provenant d'Internet vers les ports de service de l'instance ECS. Le trafic normal transféré par CLB n'est pas affecté.
Contrôles d'intégrité HTTP et HTTPS
Les écouteurs de couche 7 (HTTP/HTTPS) effectuent des contrôles d'intégrité à l'aide de requêtes HEAD ou GET.
Pour les écouteurs HTTPS, les certificats sont gérés par CLB. CLB utilise HTTP pour l'échange de données avec les serveurs backend afin d'améliorer les performances.
Un contrôle d'intégrité d'écouteur de couche 7 fonctionne comme suit :
CLB envoie une requête HTTP HEAD au serveur backend.
Le serveur backend renvoie un code d'état HTTP.
Si CLB ne reçoit pas de réponse dans le délai d'expiration de la réponse, le contrôle d'intégrité échoue.
Si CLB reçoit une réponse dans le délai d'expiration de la réponse, il compare le code d'état avec les codes d'état sains configurés. Si le code correspond, le contrôle est réussi. Sinon, il échoue.
Par défaut, les contrôles d'intégrité CLB considèrent uniquement les codes d'état HTTP 2xx et 3xx comme sains. Si un serveur backend renvoie un code d'état 4xx (tel que 400, 403, 404 ou 429) ou 5xx (tel que 500, 502 ou 503), le contrôle d'intégrité échoue.
Nous vous recommandons de créer un endpoint de contrôle d'intégrité dédié, tel que /health, qui renvoie un code d'état HTTP 200, plutôt que d'ajouter des codes 4xx ou 5xx à la liste des codes d'état sains.
Contrôles d'intégrité TCP
Pour les écouteurs TCP de couche 4, CLB utilise des sondes TCP personnalisées pour vérifier l'état du serveur, comme illustré dans la figure suivante.
Un contrôle d'intégrité d'écouteur TCP fonctionne comme suit :
Un nœud du cluster de couche 4 envoie un paquet TCP SYN à l'adresse IP interne et au port de contrôle d'intégrité du serveur backend.
Après avoir reçu la requête, si le serveur écoute correctement sur le port, il renvoie un paquet SYN+ACK.
Si le nœud du cluster de couche 4 ne reçoit aucune réponse du serveur backend dans le délai d'expiration de la réponse, le contrôle d'intégrité échoue. Le nœud envoie alors un paquet RST pour terminer la connexion TCP.
Si le nœud du cluster de couche 4 reçoit une réponse du serveur backend dans le délai d'expiration de la réponse, le contrôle d'intégrité est réussi. Le nœud envoie alors un paquet RST pour terminer la connexion TCP.
Ce mécanisme peut amener le serveur backend à considérer les connexions TCP comme anormales et à enregistrer des erreurs, telles que Connection reset by peer, dans ses journaux d'application.
Solutions de contournement :
Pour les écouteurs TCP, utilisez des contrôles d'intégrité basés sur HTTP.
Après avoir configuré le serveur backend pour obtenir l'adresse IP réelle du client, ignorez les erreurs de connexion provenant du bloc d'adresses du service CLB.
Contrôles d'intégrité UDP
Pour les écouteurs UDP de couche 4, les contrôles d'intégrité utilisent des sondes de paquets UDP pour vérifier l'état du serveur, comme illustré dans la figure suivante.
Un contrôle d'intégrité d'écouteur UDP fonctionne comme suit :
Un nœud du cluster de couche 4 envoie un paquet UDP à l'adresse IP interne et au port de contrôle d'intégrité du serveur backend.
Si le serveur backend n'écoute pas sur le port, son système d'exploitation renvoie un message d'erreur ICMP tel que
port XX unreachable. Sinon, le serveur ne répond pas.Si le nœud du cluster de couche 4 reçoit ce message d'erreur du serveur backend dans le délai d'expiration de la réponse, le contrôle d'intégrité échoue.
Si le nœud du cluster de couche 4 ne reçoit aucune réponse du serveur backend dans le délai d'expiration de la réponse, le contrôle d'intégrité est réussi.
Pour les services UDP, l'état du contrôle d'intégrité peut ne pas toujours correspondre à l'état réel du service.
Si le serveur backend est un serveur Linux, les scénarios à haute concurrence peuvent déclencher le mécanisme de protection contre les inondations ICMP de Linux, qui limite le taux auquel le serveur envoie des messages ICMP. Dans ce cas, même si le service est arrêté, le serveur pourrait être incapable de renvoyer une erreur ICMP port XX unreachable. Par conséquent, lorsque CLB ne reçoit pas de réponse ICMP, il marque incorrectement le contrôle d'intégrité comme réussi. Cela entraîne une inadéquation entre l'état de santé signalé et l'état réel du service.
Solution de contournement :
Configurez l'équilibreur de charge pour envoyer une chaîne spécifique au serveur backend et considérez le contrôle comme réussi uniquement après avoir reçu une réponse spécifique. Ce mécanisme nécessite le support de votre application backend.
Fenêtre temporelle de contrôle d'intégrité
Le mécanisme de contrôle d'intégrité améliore la disponibilité du service. Toutefois, pour prévenir l'instabilité du système due à des changements d'état fréquents, CLB modifie l'état d'un serveur uniquement après qu'il a réussi ou échoué à un nombre spécifié de contrôles d'intégrité consécutifs au sein d'une fenêtre temporelle de contrôle d'intégrité. Cette fenêtre temporelle est déterminée par les trois facteurs suivants :
intervalle de contrôle d'intégrité (fréquence à laquelle un contrôle d'intégrité est effectué)
délai d'expiration de la réponse (temps d'attente pour qu'un serveur réponde à un contrôle d'intégrité)
seuil de contrôle (nombre de contrôles réussis ou échoués consécutifs requis pour un changement d'état)
La fenêtre temporelle de contrôle d'intégrité est calculée comme suit :
Fenêtre d'échec du contrôle d'intégrité = délai d'expiration de la réponse × seuil défectueux + intervalle de contrôle d'intégrité × (seuil défectueux - 1)
-
Fenêtre de succès du contrôle d'intégrité = (temps de réponse de succès du contrôle d'intégrité × seuil sain) + intervalle de contrôle d'intégrité × (seuil sain - 1)
RemarqueLe temps de réponse de succès du contrôle d'intégrité est la durée entre l'envoi d'une requête de contrôle d'intégrité et la réception d'une réponse. Pour les contrôles d'intégrité TCP, ce temps est négligeable. Pour les contrôles d'intégrité HTTP, ce temps dépend des performances et de la charge du serveur, mais se situe généralement dans la seconde.
L'état du contrôle d'intégrité affecte le transfert des requêtes comme suit :
Si un serveur backend cible échoue à un contrôle d'intégrité, les nouvelles requêtes ne lui sont plus distribuées. Cette redirection est transparente pour les nouveaux clients.
Si un serveur backend cible réussit un contrôle d'intégrité, les nouvelles requêtes lui sont distribuées et l'accès client est normal.
Si un serveur backend échoue à ses contrôles d'intégrité mais n'a pas encore atteint le seuil défectueux (trois échecs consécutifs par défaut), CLB continue de lui envoyer des requêtes. Cela peut entraîner l'échec des requêtes client.
Exemple de configuration de contrôle d'intégrité
Cet exemple utilise la configuration de contrôle d'intégrité suivante :
response timeout: 5 seconds
health check interval: 2 seconds
healthy threshold: 3
unhealthy threshold: 3
La fenêtre d'échec du contrôle d'intégrité est calculée comme suit : délai d'expiration de la réponse × seuil défectueux + intervalle de contrôle d'intégrité × (seuil défectueux - 1). Avec les valeurs données, cela donne 5 × 3 + 2 × (3 - 1) = 19 secondes. Il s'agit du temps total écoulé depuis le début du premier contrôle d'intégrité échoué jusqu'à ce que le serveur soit marqué comme défectueux.
La fenêtre de succès du contrôle d'intégrité est calculée comme suit : (temps de réponse de succès du contrôle d'intégrité × seuil sain) + intervalle de contrôle d'intégrité × (seuil sain - 1). En supposant un temps de réponse de succès de 1 seconde, cela donne (1 × 3) + 2 × (3 - 1) = 7 secondes. Il s'agit du temps total écoulé depuis le début du premier contrôle d'intégrité réussi jusqu'à ce que le serveur soit marqué comme sain.
Le temps de réponse de succès du contrôle d'intégrité est la durée entre l'envoi d'une requête de contrôle d'intégrité et la réception d'une réponse. Pour les contrôles d'intégrité TCP, ce temps est négligeable car ils sondent uniquement si un port est actif. Pour les contrôles d'intégrité HTTP, ce temps dépend des performances et de la charge du serveur d'application, mais se situe généralement dans la seconde.
Noms de domaine dans les contrôles d'intégrité HTTP
Lorsque vous configurez un contrôle d'intégrité HTTP, vous pouvez éventuellement spécifier un nom de domaine. Certains serveurs d'application exigent que l'en-tête host soit présent dans les requêtes. Si votre serveur a cette exigence, vous devez configurer un nom de domaine. CLB ajoute ce nom de domaine à l'en-tête host de la requête de contrôle d'intégrité. Si cet en-tête est manquant, le serveur pourrait rejeter la requête, entraînant l'échec du contrôle d'intégrité.
Par conséquent, si votre serveur d'application valide le champ host, configurez le nom de domaine pour garantir que les contrôles d'intégrité réussissent.
Références
Configurez les contrôles d'intégrité lors de l'ajout d'un écouteur. Pour les étapes spécifiques, consultez Configurer et gérer les contrôles d'intégrité CLB.
Pour les questions courantes sur les contrôles d'intégrité, consultez FAQ sur les contrôles d'intégrité CLB.