Contrôles de santé pour les groupes cibles de Network Load Balancer - Elastic Load Balancing

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Contrôles de santé pour les groupes cibles de Network Load Balancer

Vous pouvez enregistrer vos cibles auprès d'un ou de plusieurs groupes cibles. L'équilibreur de charge commence à acheminer les demandes vers une cible nouvellement enregistrée dès que le processus d'enregistrement est terminé et que les cibles passent les tests de santé initiaux. Quelques minutes peuvent être nécessaires pour que le processus d'inscription soit effectué et que les surveillances de l'état commencent.

Les Network Load Balancers utilisent des surveillances de l'état actives et passives pour déterminer si une cible est disponible pour traiter des demandes. Par défaut, chaque nœud d'équilibreur de charge achemine les demandes uniquement vers les cibles saines dans sa zone de disponibilité. Si vous activez l'équilibrage de charge entre zones permet, chaque nœud d'équilibreur de charge achemine les demandes vers les cibles saines dans toutes les zones de disponibilité activées. Pour de plus amples informations, veuillez consulter Equilibrage de charge entre zones.

Avec les vérifications de l'état passives, l'équilibreur de charge observe la façon dont les cibles répondent aux connexions. Les vérifications de l'état passives permettent l'équilibreur de charge de détecter une cible non saine avant que celle-ci soit signalée comme étant non saine par les vérifications de l'état actives. Vous ne pouvez pas désactiver, configurer ou surveiller les vérifications de l'état passives. Les contrôles de santé passifs ne sont pas pris en charge pour UDP le trafic, et les groupes cibles sont activés pour lesquels la fonction d'adhérence est activée. Pour plus d'informations, consultez la section Sessions persistantes.

Si une cible devient défectueuse, l'équilibreur de charge envoie un message TCP RST pour les paquets reçus sur les connexions client associées à la cible, sauf si la cible défectueuse déclenche l'échec de l'ouverture de l'équilibreur de charge.

Si les groupes cibles ne disposent pas d'une cible saine dans une zone de disponibilité activée, nous supprimons l'adresse IP du sous-réseau correspondant DNS afin que les demandes ne puissent pas être acheminées vers les cibles de cette zone de disponibilité. Si toutes les cibles échouent aux surveillances de l'état en même temps dans toutes les zones de disponibilité activées, l'équilibreur de charge passe en mode fail-open. Les équilibreurs de charge réseau échoueront également à s'ouvrir lorsque vous avez un groupe cible vide. Ce mode a pour effet d'autoriser le trafic à destination de toutes les cibles dans toutes les zones de disponibilité activées, quel que soit leur état de santé.

Si un groupe cible est configuré avec des contrôles de HTTPS santé, ses cibles enregistrées échouent aux tests de santé s'ils ne prennent en charge que la TLS version 1.3. Ces cibles doivent prendre en charge une version antérieure deTLS, telle que TLS 1.2.

Pour les HTTP demandes de bilan de HTTPS santé, l'en-tête de l'hôte contient l'adresse IP du nœud d'équilibrage de charge et du port d'écoute, et non l'adresse IP de la cible et du port de contrôle de santé.

Si vous ajoutez un TLS écouteur à votre Network Load Balancer, nous effectuons un test de connectivité du récepteur. Comme TLS la terminaison met également fin à une TCP connexion, une nouvelle TCP connexion est établie entre votre équilibreur de charge et vos cibles. Par conséquent, les TCP connexions pour ce test peuvent être envoyées par votre équilibreur de charge aux cibles enregistrées auprès de votre TLS écouteur. Vous pouvez identifier ces TCP connexions car elles possèdent l'adresse IP source de votre Network Load Balancer et elles ne contiennent pas de paquets de données.

Pour un UDP service, la disponibilité des cibles peut être testée à l'aide de tests autres que des tests de UDP santé sur votre groupe cible. Vous pouvez utiliser n'importe quel bilan de santé disponible (TCPHTTP,, ouHTTPS) et n'importe quel port de votre cible pour vérifier la disponibilité d'un UDP service. Si le service recevant la surveillance de l'état échoue, votre cible est considérée comme indisponible. Pour améliorer la précision des contrôles de santé d'un UDP service, configurez le service qui écoute le port de contrôle de santé pour suivre l'état de votre UDP service et échouer au contrôle de santé si le service n'est pas disponible.

Paramètres de surveillance de l'état

Vous configurez les vérifications de l'état actives pour les cibles d'un groupe cible en utilisant les paramètres suivants. Si les bilans de santé dépassent le nombre de défaillances UnhealthyThresholdCountconsécutives, l'équilibreur de charge met la cible hors service. Lorsque les bilans de santé dépassent le nombre de réussites HealthyThresholdCountconsécutives, l'équilibreur de charge remet la cible en service.

Paramètre Description Par défaut

HealthCheckProtocol

Protocole utilisé par l'équilibreur de charge lors des vérifications de l'état des cibles. Les protocoles possibles sont HTTPHTTPS, etTCP. La valeur par défaut est le TCP protocole. Si le type de cible estalb, les protocoles de contrôle de santé pris en charge sont HTTP etHTTPS.

TCP

HealthCheckPort

Port utilisé par l'équilibreur de charge lors des vérifications de l'état des cibles. La valeur par défaut consiste à utiliser le port sur lequel chaque cible reçoit le trafic depuis l'équilibreur de charge.

Port sur lequel chaque cible reçoit le trafic depuis l'équilibreur de charge.

HealthCheckPath

[HTTP/HTTPSbilans de santé] Le chemin du bilan de santé qui est la destination des cibles pour les bilans de santé. La valeur par défaut est /.

/

HealthCheckTimeoutSeconds

Durée, en secondes, pendant laquelle l'absence de réponse d'une cible indique l'échec de la vérification de l'état. La plage est comprise entre 2 et 120 secondes. Les valeurs par défaut sont de 6 secondes pour les vérifications de santé HTTP et de 10 secondes pour les TCP vérifications HTTPS de santé.

6 secondes pour les bilans de HTTP santé et 10 secondes pour les TCP bilans HTTPS de santé.

HealthCheckIntervalSeconds

Durée approximative, en secondes, entre les vérifications de l'état d'une cible. La plage est comprise entre 5 et 300 secondes. Le durée par défaut est 30 secondes.

Important

Les surveillances de l'état pour un Network Load Balancer sont distribuées et utilisent un mécanisme de consensus pour déterminer l'état des cibles. Par conséquent, des cibles reçoivent plus de vérifications de l'état que le nombre configuré. Pour réduire l'impact sur vos cibles si vous utilisez des bilans de HTTP santé, utilisez une destination plus simple sur les cibles, telle qu'un HTML fichier statique, ou passez aux bilans de TCP santé.

30 secondes

HealthyThresholdCount

Le nombre de réussites consécutives de la vérification de l'état à partir duquel une cible défectueuse est considérée comme saine. La plage est comprise entre 2 et 10. La valeur par défaut est 5.

5

UnhealthyThresholdCount

Le nombre d'échecs consécutifs de la vérification de l'état à partir duquel une cible est considérée comme défectueuse. La plage est comprise entre 2 et 10. La valeur par défaut est 2.

2

Matcher

[HTTP/HTTPSbilans de santé] Les HTTP codes à utiliser lors de la vérification de l'efficacité de la réponse d'une cible. La plage est comprise entre 200 et 599. La valeur par défaut est comprise entre 200 et 399.

200-399

État de santé d'une cible

Avant que l'équilibreur de charge n'envoie une demande de vérification de l'état à une cible, vous devez enregistrer cette cible auprès d'un groupe cible, spécifier son groupe cible dans une règle d'écouteur et vous assurer que la zone de disponibilité de la cible est activée pour l'équilibreur de charge.

Le tableau suivant décrit les valeurs possibles de l'état de santé d'une cible enregistrée.

Valeur Description

initial

L'équilibreur de charge est en train d'enregistrer la cible ou d'exécuter les vérifications de l'état initiales sur la cible.

Codes de motif connexes : Elb.RegistrationInProgress | Elb.InitialHealthChecking

healthy

La cible est saine.

Codes de motif connexes : aucun

unhealthy

La cible n'a pas répondu à un bilan de santé, a échoué au bilan de santé ou est en état d'arrêt.

Code motif connexe : Target.FailedHealthChecks

draining

L'enregistrement de la cible est en cours d'annulation et le drainage de la connexion est en cours.

Code motif connexe : Target.DeregistrationInProgress

unhealthy.draining

La cible n'a pas répondu aux examens de santé ou a échoué aux examens de santé et entre dans une période de grâce. La cible prend en charge les connexions existantes et n'acceptera aucune nouvelle connexion pendant cette période de grâce.

Code motif connexe : Target.FailedHealthChecks

unavailable

L'état cible n'est pas disponible.

Code motif connexe : Elb.InternalError

unused

La cible n'est pas enregistrée auprès d'un groupe cible, le groupe cible n'est pas utilisé dans une règle d'écoute ou la cible se trouve dans une zone de disponibilité non activée.

Codes de motif connexes : Target.NotRegistered | Target.NotInUse | Target.InvalidState | Target.IpUnusable

Codes de motif de vérification de l'état

Si le statut d'une cible est une valeur autre queHealthy, elle API renvoie un code de raison et une description du problème, et la console affiche la même description dans une infobulle. Notez que les codes de motif qui commencent par Elb proviennent de l'équilibreur de charge et que ceux qui commencent par Target proviennent de la cible.

Code de motif Description

Elb.InitialHealthChecking

Vérifications de l'état initiales en cours

Elb.InternalError

Échec des vérifications de l'état initiales en raison d'une erreur interne

Elb.RegistrationInProgress

Enregistrement de la cible en cours

Target.DeregistrationInProgress

Annulation de l'enregistrement de la cible en cours

Target.FailedHealthChecks

Échec des vérifications de l'état

Target.InvalidState

La cible est à l'état arrêté.

La cible est à l'état résilié.

La cible est à l'état résilié ou arrêté.

La cible est à un état non valide.

Target.IpUnusable

L'adresse IP ne peut pas être utilisée en tant que cible, car elle est utilisée par un équilibreur de charge

Target.NotInUse

Le groupe cible n'est pas configuré de façon à recevoir le trafic de l'équilibreur de charge

La cible est dans une zone de disponibilité qui n'est pas activée pour l'équilibreur de charge

Target.NotRegistered

La cible n'est pas enregistrée auprès du groupe cible