Dépannage de votre Network Load Balancer

Les informations suivantes peuvent vous aider à résoudre les problèmes liés à votre Network Load Balancer.

Une cible enregistrée n'est pas en service

Si le passage à l'état InService d'une cible est plus long que prévu, les vérifications de l'état risquent d'échouer. Votre cible ne sera pas en service tant que la vérification de l'état correspondante ne sera pas concluante. Pour plus d’informations, consultez Surveillance de l'état de vos groupes cibles.

Vérifiez si les vérifications de l'état de votre instance ont échoué, puis contrôlez les points suivants :

Un groupe de configuration n'autorise pas le trafic

Les groupes de sécurité associés à une instance doivent autoriser le trafic à partir de l'équilibreur de charge à l'aide du port et du protocole de vérification de l'état. Pour plus d’informations, consultez Groupes de sécurité cibles.

Une liste de contrôle d'accès (ACL) réseau n'autorise pas le trafic

La liste ACL réseau associée aux sous-réseaux de vos instances et aux sous-réseaux de votre équilibreur de charge doit autoriser le trafic et les surveillances de l'état depuis l'équilibreur de charge. Pour plus d’informations, consultez Listes ACL réseau.

Les demandes ne sont pas acheminées vers les cibles

Vérifiez les points suivants :

Un groupe de configuration n'autorise pas le trafic

Les groupes de sécurité associés aux instances doivent autoriser le trafic sur le port d'écoute à partir d'adresses IP du client (si les cibles sont spécifiées par ID d'instance) ou de nœuds d'équilibreur de charge (si les cibles sont spécifiées par adresse IP). Pour plus d’informations, consultez Groupes de sécurité cibles.

Une liste de contrôle d'accès (ACL) réseau n'autorise pas le trafic

Les ACL réseau associées aux sous-réseaux pour votre VPC doivent autoriser l'équilibreur de charge et les cibles à communiquer dans les deux sens sur le port d'écoute. Pour plus d’informations, consultez Listes ACL réseau.

Les cibles sont dans une zone de disponibilité qui n'est pas activée

Si vous enregistrez des cibles dans une zone de disponibilité mais que vous n'activez pas la zone de disponibilité, ces cibles enregistrées ne reçoivent pas le trafic de l'équilibreur de charge.

L'instance n'est pas dans un VPC appairé

Si vous disposez d'instances dans un VPC appairé au VPC de l'équilibreur de charge, vous devez les enregistrer à l'aide de votre équilibreur de charge par adresse IP et non par ID d'instance.

Les cibles reçoivent plus de demandes de vérification de l'état que prévu

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é via le paramètre HealthCheckIntervalSeconds.

Les cibles reçoivent moins de demandes de vérification de l'état que prévu

Vérifiez si net.ipv4.tcp_tw_recycle est activé. Ce paramètre est connu pour entraîner des problèmes liés aux équilibreurs de charge. Le paramètre net.ipv4.tcp_tw_reuse est considéré comme un paramètre plus sûr.

Des cibles non saines reçoivent des demandes de l'équilibreur de charge.

Cela se produit lorsque toutes les cibles enregistrées sont défectueuses. S'il existe au moins une cible enregistrée saine, votre Network Load Balancer achemine les demandes uniquement vers ses cibles enregistrées saines.

Lorsqu'il n'existe que des cibles enregistrées défectueuses, le Network Load Balancer achemine les demandes vers toutes les cibles enregistrées : il s'agit du mode fail-open. Le Network Load Balancer procède ainsi au lieu de supprimer toutes les adresses IP du DNS lorsque toutes les cibles sont défectueuses et que les zones de disponibilité respectives n'ont pas de cible saine à laquelle envoyer une demande.

La cible échoue aux vérifications d'intégrité HTTP ou HTTPS en raison d'une incompatibilité d'en-tête d'hôte

L'en-tête d'hôte HTTP dans la demande de vérification de l'intégrité contient l'adresse IP du nœud d'équilibrage et le port de l’écouteur, et non l'adresse IP de la cible et le port de vérification de l'intégrité. Si vous mappez des requêtes entrantes par en-tête d'hôte, vous devez vous assurer que les vérifications d'intégrité correspondent à n'importe quel en-tête d'hôte HTTP. Une autre option consiste à ajouter un service HTTP distinct sur un port différent et à configurer le groupe cible afin qu'il utilise ce port pour les vérifications d'intégrité à la place. Vous pouvez aussi envisager d'utiliser des contrôles d'intégrité TCP.

Impossible d'associer un groupe de sécurité à un équilibreur de charge

Si le Network Load Balancer a été créé sans groupes de sécurité, il ne peut pas prendre en charge les groupes de sécurité après sa création. Vous ne pouvez associer un groupe de sécurité qu'à un équilibreur de charge lors de sa création ou à un équilibreur de charge existant créé à l'origine avec des groupes de sécurité.

Impossible de supprimer tous les groupes de sécurité

Si le Network Load Balancer a été créé avec des groupes de sécurité, au moins un groupe de sécurité doit lui être associé à tout moment. Vous ne pouvez pas supprimer tous les groupes de sécurité de l'équilibreur de charge en même temps.

Augmentation de la métrique TCP_ELB_Reset_Count

Pour chaque demande TCP effectuée par un client via un Network Load Balancer, l'état de cette connexion est suivi. Si aucune donnée n'est envoyée via la connexion par le client ou la cible au cours d'une période plus longue que le délai d'inactivité, la connexion est fermée. Si un client ou une cible envoie des données après que le délai d'inactivité est écoulé, il reçoit un paquet TCP RST pour indiquer que la connexion n'est plus valide. Par ailleurs, si une cible devient défectueuse, l'équilibreur de charge envoie un TCP RST pour les paquets reçus sur les connexions client associées à la cible, sauf si la cible défectueuse déclenche le mode fail-open pour l'équilibreur de charge.

Si vous constatez une hausse de la métrique TCP_ELB_Reset_Count juste avant ou pendant l'augmentation de la métrique UnhealthyHostCount, il est probable que les paquets TCP RST aient été envoyés parce que la cible commençait à échouer, mais n'avait pas été signalée comme étant défectueuse. Si vous constatez des augmentations persistantes de TCP_ELB_Reset_Count sans que les cibles ne soient signalées comme défectueuses, vous pouvez consulter les journaux de flux VPC pour voir si les clients envoient des données sur des flux expirés.

Connexions expirées pour les demandes d'une cible vers son équilibreur de charge

Vérifiez si la préservation des adresses IP client est activée sur votre groupe cible. La boucle NAT, également appelée hairpinning, n'est pas prise en charge lorsque la préservation des adresses IP client est activée. Si une instance est un client d'un équilibreur de charge auprès duquel elle est enregistrée, et si la préservation des adresses IP client est activée, la connexion aboutit uniquement si la demande est acheminée vers une autre instance. Si la demande est acheminée vers la même instance à partir de laquelle elle a été envoyée, la connexion expire, car les adresses IP source et de destination sont identiques.

Si une instance doit envoyer des demandes à un équilibreur de charge auprès duquel elle est enregistrée, effectuez l'une des actions suivantes :

• Désactivez la préservation des adresses IP client.

• Assurez-vous que les conteneurs qui doivent communiquer sont sur des instances de conteneur différentes.

Diminution des performances lorsque des cibles sont déplacées vers un Network Load Balancer

Les Classic Load Balancers et les Application Load Balancers utilisent le multiplexage des connexions, mais pas les Network Load Balancers. Par conséquent, vos cibles peuvent recevoir plus de connexions TCP derrière un Network Load Balancer. Assurez-vous que vos cibles sont prêtes à gérer le volume de demandes de connexion qu'elles sont susceptibles de recevoir.

Erreurs d'allocation de port lors de la connexion AWS PrivateLink

Si votre Network Load Balancer est associé à un service de point de terminaison d'un VPC, il prend en charge 55 000 connexions simultanées ou environ 55 000 connexions par minute sur chaque cible unique (adresse IP et port). Si vous dépassez ce nombre de connexions, il y a plus de risque d'erreurs d'attribution de port. Les erreurs d'attribution de ports peuvent être suivies à l'aide de la métrique PortAllocationErrorCount. Pour résoudre les erreurs d'attribution de port, ajoutez davantage de cibles au groupe cible. Pour plus d’informations, consultez CloudWatch métriques pour votre Network Load Balancer.

Échec de connexion intermittent lorsque la préservation des adresses IP client est activée

Lorsque la préservation des adresses IP client est activée, vous pouvez rencontrer des limitations de connexion TCP/IP liées à la réutilisation observée des sockets sur les cibles. Ces limitations de connexion peuvent survenir lorsqu'un client, ou un périphérique NAT situé devant le client, utilise la même adresse IP source et le même port source pour se connecter simultanément à plusieurs nœuds d'équilibreur de charge. Si l'équilibreur de charge achemine ces connexions vers la même cible, celles-ci apparaissent à la cible comme si elles provenaient du même socket source, ce qui entraîne des erreurs de connexion. Dans ce cas, les clients peuvent réessayer (si la connexion échoue) ou se reconnecter (si la connexion est interrompue). Vous pouvez réduire ce type d'erreur de connexion en augmentant le nombre de ports éphémères sources ou en augmentant le nombre de cibles pour l'équilibreur de charge. Vous pouvez éviter ce type d'erreur de connexion en désactivant la préservation des adresses IP client ou en désactivant l'équilibrage de charge entre zones.

En outre, lorsque la préservation des adresses IP client est activée, la connectivité peut échouer si les clients qui se connectent au Network Load Balancer sont également connectés à des cibles situées derrière l'équilibreur de charge. Pour résoudre ce problème, vous pouvez désactiver la préservation des adresses IP client sur les groupes cibles concernés. Vous pouvez également demander à vos clients de se connecter uniquement au Network Load Balancer, ou uniquement aux cibles, mais pas aux deux.

Retards de connexion TCP

Lorsque l'équilibrage de charge entre zones et la préservation des adresses IP client sont activés, un client se connectant à différentes adresses IP sur le même équilibreur de charge peut être acheminé vers la même cible. Si le client utilise le même port source pour ces deux connexions, la cible recevra ce qui semble être une connexion dupliquée, ce qui peut entraîner des erreurs de connexion et des retards TCP lors de l'établissement de nouvelles connexions. Vous pouvez éviter ce type d'erreur de connexion en désactivant l'équilibrage de charge entre zones. Pour plus d’informations, consultez Equilibrage de charge entre zones.

Défaillance potentielle lors du provisionnement de l'équilibreur de charge

L'une des raisons pour lesquelles un Network Load Balancer peut échouer lors de son provisionnement est que vous utilisez une adresse IP déjà attribuée ou allouée ailleurs (par exemple, attribuée comme adresse IP secondaire d'une instance EC2). Cette adresse IP empêche la configuration de l'équilibreur de charge, et son état est failed. Vous pouvez résoudre ce problème en annulant l'allocation de l'adresse IP associée et en relançant le processus de création.

La résolution de noms DNS contient moins d'adresses IP que les zones de disponibilité activées

Dans l'idéal, votre Network Load Balancer fournit une adresse IP par zone de disponibilité activée, lorsqu'il possède au moins un hôte sain dans la zone de disponibilité. Lorsqu'aucun hôte sain n'est présent dans une zone de disponibilité donnée et que l'équilibrage de charge entre zones est désactivé, l'adresse IP du Network Load Balancer correspondant à cette zone de disponibilité est supprimée du DNS.

Supposons, par exemple, que votre Network Load Balancer dispose de trois zones de disponibilité activées, qui ont toutes au moins une instance cible enregistrée saine.

• Si les instances cibles enregistrées dans la zone de disponibilité A deviennent défectueuses, l'adresse IP correspondante de la zone de disponibilité A pour le Network Load Balancer est supprimée du DNS.

• Si deux des zones de disponibilité activées ne possèdent aucune instance cible enregistrée saine, les deux adresses IP respectives du Network Load Balancer seront supprimées du DNS.

• S'il n'y a aucune instance cible enregistrée saine dans toutes les zones de disponibilité activées, le mode fail-open est activé et le DNS fournira toutes les adresses IP des trois zones de disponibilité activées dans le résultat.

Résoudre les problèmes liés aux cibles défectueuses à l'aide de la carte des ressources

Si les tests de santé de vos cibles Network Load Balancer échouent, vous pouvez utiliser la carte des ressources pour détecter les cibles défectueuses et prendre des mesures en fonction du code de cause de l'échec. Pour plus d’informations, consultez Carte des ressources du Network Load Balancer.

La carte des ressources fournit deux vues : Vue d'ensemble et Carte cible malsaine. L'option Vue d'ensemble est sélectionnée par défaut et affiche toutes les ressources de votre équilibreur de charge. La sélection de la vue Malhealthy Target Map affichera uniquement les cibles malsaines de chaque groupe cible associé au Network Load Balancer.

Note

L'option Afficher les détails des ressources doit être activée pour afficher le résumé du bilan de santé et les messages d'erreur pour toutes les ressources applicables dans la carte des ressources. Lorsque cette option n'est pas activée, vous devez sélectionner chaque ressource pour en afficher les détails.

La colonne Groupes cibles affiche un résumé des cibles saines et malsaines pour chaque groupe cible. Cela peut aider à déterminer si toutes les cibles échouent aux tests de santé ou si seules des cibles spécifiques échouent. Si toutes les cibles d'un groupe cible échouent aux tests de santé, vérifiez les paramètres du bilan de santé du groupe cible. Sélectionnez le nom d'un groupe cible pour ouvrir sa page détaillée dans un nouvel onglet.

La colonne Targets affiche le TargetID et l'état actuel du bilan de santé pour chaque cible. Lorsqu'une cible n'est pas saine, le code de la raison de l'échec du contrôle de santé s'affiche. Lorsqu'une cible échoue à un bilan de santé, vérifiez qu'elle dispose de ressources suffisantes. Sélectionnez l'ID d'une cible pour ouvrir sa page détaillée dans un nouvel onglet.

La sélection d'Exporter vous permet d'exporter la vue actuelle de la carte des ressources de votre Network Load Balancer au format PDF.

Vérifiez que les tests de santé de votre instance échouent, puis, en fonction du code de cause de l'échec, vérifiez les problèmes suivants :

• Malsain : le délai imparti pour la demande a expiré

  • Vérifiez que les groupes de sécurité et les listes de contrôle d'accès réseau (ACL) associés à vos cibles et à Network Load Balancer ne bloquent pas la connectivité.

  • Vérifiez que la cible dispose d'une capacité suffisante pour accepter les connexions depuis le Network Load Balancer.

  • Les réponses au bilan de santé du Network Load Balancer peuvent être consultées dans les journaux des applications de chaque cible. Pour plus d'informations, consultez la section Codes de raison du contrôle de santé.

• Malsain : FailedHealthChecks

  • Vérifiez que la cible écoute le trafic sur le port de contrôle de santé.

    Lors de l'utilisation d'un écouteur TLS

    Vous choisissez la politique de sécurité à utiliser pour les connexions frontales. La politique de sécurité utilisée pour les connexions dorsales est automatiquement sélectionnée en fonction de la stratégie de sécurité frontale utilisée.

    • Si votre écouteur TLS utilise une politique de sécurité TLS 1.3 pour les connexions frontales, la politique de ELBSecurityPolicy-TLS13-1-0-2021-06 sécurité est utilisée pour les connexions dorsales.

    • Si votre écouteur TLS n'utilise pas de stratégie de sécurité TLS 1.3 pour les connexions frontales, la stratégie de ELBSecurityPolicy-2016-08 sécurité est utilisée pour les connexions dorsales.

    Pour plus d'informations, consultez la section Politiques de sécurité.

  • Vérifiez que la cible fournit un certificat de serveur et une clé au format correct spécifié par la politique de sécurité.

  • Vérifiez que la cible prend en charge un ou plusieurs chiffrements correspondants, ainsi qu'un protocole fourni par le Network Load Balancer pour établir des handshakes TLS.