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.

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 Contrôles de santé pour les groupes cibles de Network Load Balancer.

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

Les demandes ne sont pas acheminées vers les cibles

Vérifiez les points suivants :

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 :

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.

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 Afficher la 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.

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 :