Résoudre les problèmes liés aux équilibreurs de charge d'application externes

Ce guide explique comment résoudre les problèmes de configuration des équilibreurs de charge d'application externes. Avant de vous pencher sur les problèmes, familiarisez-vous avec les pages suivantes.

Résoudre les problèmes courants liés à Network Analyzer

Network Analyzer surveille automatiquement la configuration de votre réseau VPC et détecte les configurations non optimales ainsi que les erreurs de configuration. Il identifie les défaillances du réseau, fournit des informations sur l'origine des problèmes et suggère des solutions possibles. Pour en savoir plus sur les différents scénarios de configuration erronée qui sont automatiquement détectés par Network Analyzer, consultez la section Insights sur l'équilibreur de charge dans la documentation de Network Analyzer.

Network Analyzer est disponible dans la console Google Cloud dans le cadre de Network Intelligence Center.

Accéder à l'Analyse du réseau

Incompatibilité des modes d'équilibrage des backends

Lors de la création d'un équilibreur de charge, le message d'erreur suivant peut s'afficher :

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Cette erreur se produit lorsque vous essayez d'utiliser le même backend dans deux équilibreurs de charge différents et que les backends ne disposent pas de modes d'équilibrage compatibles.

Pour en savoir plus, consultez les ressources suivantes :

Résoudre les problèmes de connectivité générale

Erreurs 5XX inexpliquées

Pour les conditions d'erreur causées par un problème de communication entre le proxy de l'équilibreur de charge et ses backends, l'équilibreur de charge génère un code de réponse d'erreur HTTP (5XX) et renvoie ce code de réponse d'erreur au client. Les erreurs HTTP 5XX ne sont pas toutes générées par l'équilibreur de charge. Par exemple, si un backend envoie une réponse HTTP 5XX à l'équilibreur de charge, celui-ci va simplement retransmettre cette réponse à son client. Pour déterminer si une réponse HTTP 5XX a été relayée depuis un backend ou si elle a été générée par le proxy de l'équilibreur de charge, reportez-vous au champ statusDetails des journaux de l'équilibreur de charge.

Si statusDetails renvoie une chaîne de journal response_sent_by_backend, l'équilibreur de charge relaie simplement le code de réponse que le backend lui a envoyé, auquel cas vous devez résoudre les problèmes liés aux réponses d'erreur HTTP sur vos backends.

Pour les réponses d'erreur HTTP pour lesquelles le champ statusDetails ne correspond pas à la chaîne de journal response_sent_by_backend:

  • L'équilibreur de charge d'application externe global et l'équilibreur de charge d'application externe régional génèrent des codes d'erreur de réponse HTTP significatifs tels que 503 (Service indisponible) et 504 (Expiration du délai de la passerelle).

  • L'équilibreur de charge d'application classique utilise toujours le code d'erreur HTTP 502.

Les modifications de configuration de l'équilibreur de charge d'application externe global, telles que l'ajout ou la suppression d'un service de backend, peuvent entraîner une brève période pendant laquelle les utilisateurs sont confrontés à un code d'erreur de réponse HTTP 502. Pendant que ces modifications de configuration sont appliquées aux GFE dans le monde entier, des entrées de journal dont le champ statusDetails correspond à la chaîne de journal failed_to_pick_backend s'affichent.

Si les erreurs HTTP 5XX persistent plus de quelques minutes après avoir terminé la configuration de l'équilibreur de charge, procédez comme suit pour résoudre les problèmes liés aux réponses HTTP 5XX :

  1. Vérifiez qu'une règle de pare-feu est configurée pour autoriser les vérifications d'état. En l'absence d'une telle règle de pare-feu, les journaux de l'équilibreur de charge ont généralement un champ statusDetails renvoyant failed_to_pick_backend, ce qui indique que l'équilibreur de charge n'a pas pu sélectionner de backend opérationnel pour traiter la requête.

  2. Vérifier que le trafic de vérification de l'état atteint vos VM de backend. Pour ce faire, activez la journalisation des vérifications d'état et recherchez les entrées de journal ayant réussi.

    Pour les nouveaux équilibreurs de charge, le manque d'entrées de journal de vérifications d'état réussies ne signifie pas que le trafic de vérification d'état n'atteint pas les backends. Cela peut signifier que l'état initial du backend n'est pas encore passé de UNHEALTHY à un autre état. Les entrées de journal de vérification d'état réussies ne s'affichent qu'une fois que le vérificateur d'état a reçu une réponse HTTP 200 OK du backend.

  3. Vérifiez que la pile logicielle sur les backends est en cours d'exécution. Pour ce faire, vérifiez si la réponse 5xx est diffusée par l'équilibreur de charge ou si elle est générée au niveau des backends. Procédez comme suit :

    1. Utilisez Cloud Logging pour afficher les journaux de l'équilibreur de charge. Vous pouvez créer une requête pour ne rechercher que les codes de réponse 5xx.

    2. Vérifiez la valeur du champ statusDetails :

      • Si statusDetails renvoie un message de réussite, tel que response_sent_by_backend, cela signifie que c'est le backend qui diffuse les réponses HTTP 502. Vérifiez les journaux sur le backend et continuez le dépannage en fonction du service exécuté sur le backend.
      • Si statusDetails renvoie un message d'échec, reportez-vous à la liste des solutions suivantes pour connaître les échecs courants liés aux réponses 5xx :
      Message d'échec statusDetail Causes et solutions possibles
      failed_to_connect_to_backend

      L'équilibreur de charge n'a pas pu établir de connexion avec le backend. Cela peut signifier que le service exécuté sur le backend n'écoute pas le port défini dans le service de backend.

      Recommandations :

      • Définissez le port de la vérification d'état pour qu'il utilise le port en service. Cela signifie que le backend sera considéré comme non opérationnel avant de pouvoir diffuser le trafic réel.
      • Utilisez la commande suivante pour vérifier qu'un service s'exécute sur le port nommé du service de backend : 
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

      L'équilibreur de charge n'a pas pu sélectionner de backend. Cela peut signifier que tous les backends sont non opérationnels. Assurez-vous d'avoir configuré les règles de pare-feu correctes pour les vérifications d'état.

      backend_connection_closed_before_data_sent_to_client Le backend a fermé de manière inattendue sa connexion à l'équilibreur de charge avant que la réponse ne soit envoyée par proxy au client. Cela peut se produire si l'équilibreur de charge envoie le trafic vers une autre entité. L'autre entité peut être un équilibreur de charge tiers dont le délai avant expiration TCP est inférieur à celui de l'équilibreur de charge. Pour en savoir plus, consultez la page Délais d'expiration et nouvelles tentatives.
      backend_timeout Le backend a mis trop de temps à répondre. Le délai avant expiration du service de backend est peut-être défini sur une valeur trop faible pour que le service donné puisse répondre. Envisagez d'augmenter le délai avant expiration du service de backend ou examinez pourquoi votre service met autant de temps à répondre.

  4. Vérifiez que le paramètre de configuration keepalive du logiciel serveur HTTP exécuté sur l'instance backend n'est pas inférieur au délai d'expiration keepalive de l'équilibreur de charge, dont la valeur est fixée à 10 minutes (600 secondes) et qui n'est pas configurable.

    L'équilibreur de charge génère un code de réponse HTTP 5XX lorsque la connexion au backend est fermée de manière inattendue lors de l'envoi de la requête HTTP, ou avant réception de la réponse HTTP complète. Cela peut se produire car le paramètre de configuration keepalive du logiciel serveur Web exécuté sur l'instance backend est inférieur au délai d'expiration keepalive fixe de l'équilibreur de charge. Assurez-vous que la configuration du délai d'expiration keepalive pour le logiciel serveur HTTP sur chaque backend est légèrement supérieure à 10 minutes (la valeur recommandée est de 620 secondes).

Résoudre les erreurs HTTP 408

Avec le trafic HTTP, la durée maximale pour que le client termine d'envoyer sa requête est égale au délai avant expiration du service de backend. Si des réponses HTTP 408 avec jsonPayload.statusDetail client_timed_out apparaissent, cela signifie que la progression était insuffisante lors de l'envoi par proxy de la requête du client ou de la réponse du backend. Si le problème est dû à des clients rencontrant des problèmes de performances, vous pouvez résoudre ce problème en augmentant le délai avant expiration du service de backend.

Le trafic à équilibrage de charge n'a pas l'adresse source du client d'origine

Les adresses IP sources des paquets, telles qu'elles sont perçues par les backends, ne correspondent pas à l'adresse IP externe de l'équilibreur de charge. Les équilibreurs de charge basés sur un proxy, tels que les équilibreurs de charge d'application externes, utilisent deux connexions TCP pour transmettre le trafic du client aux backends :

  • Connexion 1, du client d'origine vers l'équilibreur de charge (GFE ou sous-réseau proxy réservé)
  • Connexion 2, de l'équilibreur de charge (GFE ou sous-réseau proxy réservé) vers la VM de backend ou le point de terminaison

Les adresses IP source et de destination de chaque connexion diffèrent en fonction du type d'équilibreur de charge d'application externe que vous utilisez. Pour plus d'informations, consultez la section Adresses IP sources pour les paquets clients.

Obtention d'une erreur d'autorisation lors de la tentative d'affichage d'un objet dans votre bucket Cloud Storage

Pour que des objets Cloud Storage puissent être diffusés via l'équilibrage de charge, ils doivent être accessibles publiquement. Veillez à mettre à jour les autorisations des objets diffusés pour les rendre lisibles publiquement.

L'URL ne diffuse pas l'objet Cloud Storage attendu

L'objet Cloud Storage à diffuser est déterminé en fonction de votre mappage d'URL et de l'URL demandée. Si le chemin de la requête correspond à un bucket backend dans votre mappage d'URL, l'objet Cloud Storage est déterminé en ajoutant le chemin de requête complet au bucket Cloud Storage spécifié par le mappage d'URL.

Par exemple, si vous mappez /static/* avec gs://[EXAMPLE_BUCKET], la requête envoyée à https://<GCLB IP or Host>/static/path/to/content.jpg essaie de diffuser gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Si cet objet n'existe pas, vous obtenez le message d'erreur suivant à la place de l'objet :


NoSuchKey
The specified key does not exist.

La compression ne fonctionne pas

L'équilibreur de charge d'application externe n'effectue pas lui-même la compression et la décompression des réponses, mais il peut diffuser des réponses générées par votre service de backend qui ont été compressées à l'aide d'outils tels que gzip ou DEFLATE.

Si les réponses diffusées par l'équilibreur de charge ne sont pas compressées alors qu'elles doivent l'être, vérifiez que le logiciel serveur Web exécuté sur les instances est configuré pour compresser les réponses. Par défaut, certains logiciels de serveur Web désactivent automatiquement la compression pour les requêtes comportant l'en-tête Via, qui indique que la requête a été transmise par un proxy. Étant donné qu'il s'agit d'un proxy, l'équilibreur de charge d'application externe ajoute un en-tête Via à chaque requête, comme requis par la spécification HTTP. Pour activer la compression, vous devrez peut-être remplacer la configuration par défaut de votre serveur Web pour lui indiquer de compresser les réponses même si la requête comporte un en-tête Via.

Pour configurer les backends nginx afin de diffuser des réponses compressées mises en proxy via un équilibreur de charge d'application externe:

Pour configurer les backends Apache afin de diffuser des réponses compressées mises en proxy via un équilibreur de charge d'application externe:

Résoudre les problèmes de backends non opérationnels

Résoudre les problèmes liés à l'utilisation de HTTP/2 avec les backends

Assurez-vous que votre instance backend est opérationnelle et accepte le protocole HTTP/2. Pour ce faire, testez la connectivité à cette instance à l'aide de HTTP/2. Assurez-vous que la VM utilise des suites de chiffrement conformes à la spécification HTTP/2. Par exemple, certaines suites de chiffrement TLS 1.2 ne sont pas autorisées par HTTP/2. Consultez la liste noire des suites de chiffrement TLS 1.2.

Une fois que vous avez vérifié que la VM utilise le protocole HTTP/2, assurez-vous que la configuration de votre pare-feu autorise la passage par le vérificateur d'état et l'équilibreur de charge.

Si la configuration du pare-feu ne présente aucun problème, assurez-vous que l'équilibreur de charge est configuré pour communiquer avec le bon port sur la VM.

Résoudre les problèmes liés aux NEG Internet et aux backends externes

Avant de vous pencher sur les problèmes, familiarisez-vous avec les pages suivantes :

Le trafic n'atteint pas les points de terminaison

Après que vous avez configuré un service, le nouveau point de terminaison devient accessible via l'équilibreur de charge d'application externe lorsque les conditions suivantes sont remplies :

  • Le point de terminaison est associé au NEG Internet.
  • Le nom de domaine complet associé peut être correctement résolu par DNS (si vous utilisez le type de point de terminaison FQDN).
  • Le point de terminaison est accessible sur Internet.

Si le trafic ne peut pas atteindre le point de terminaison, ce qui génère un code d'erreur 502, interrogez l'enregistrement TXT DNS _cloud-eoips.googleusercontent.com à l'aide d'un outil tel que dig ou nslookup. Notez les valeurs CIDR (après ip4:) et vérifiez que ces plages sont autorisées par votre pare-feu ou votre liste de contrôle d'accès (LCA) au cloud.

Après la configuration d'un backend externe, les requêtes adressées au backend externe ont échoué avec une erreur 5xx

  • Vérifiez Logging.
  • Vérifiez que le groupe de points de terminaison du réseau est configuré avec la valeur IP:Port ou FQDN:Port correcte pour votre backend externe.
  • Si vous utilisez le nom de domaine complet, assurez-vous qu'il peut être résolu via le DNS public de Google. Pour ce faire, suivez ces étapes ou utilisez l'interface Web directement.
  • Si vous n'accédez à l'équilibreur de charge que via son adresse IP externe et que le serveur Web d'origine attend un nom d'hôte, assurez-vous que vous envoyez un en-tête HTTP Host valide à votre backend. Pour ce faire, configurez un en-tête de requête personnalisé.
  • Si vous communiquez avec un backend via HTTPS ou HTTP2 (tel que défini dans le champ protocol du service de backend) configuré en tant que point de terminaison de backend personnalisé INTERNET_FQDN_PORT, vérifiez que votre origine présente un certificat TLS (SSL) valide et que le nom de domaine complet configuré correspond à un autre nom de l'objet (SAN) dans la liste des SAN des certificats. Un certificat valide est défini comme un certificat signé par une autorité de certification publique et qui n'a pas expiré.
  • Lorsque vous utilisez des points de terminaison de backend externes INTERNET_FQDN_PORT, les certificats autosignés ne sont pas acceptés par l'équilibreur de charges et sont refusés.
  • Lorsque vous utilisez HTTPS ou HTTP/2 avec des points de terminaison de type INTERNET_IP_PORT, aucune validation de certificat SSL ni aucune vérification SAN n'est effectuée. Cela signifie que vous pouvez utiliser des certificats autosignés. Lorsque vous utilisez SSL, nous vous recommandons d'utiliser des points de terminaison INTERNET_FQDN_PORT pour vous assurer que les SAN et les certificats de serveur peuvent être validés.

Les réponses de mon backend externe ne sont pas mises en cache par Cloud CDN

Vérifiez les points suivants :

  • Vous avez défini enableCDN sur "true" afin d'activer Cloud CDN pour le service de backend contenant le NEG qui pointe vers votre backend externe.
  • Les réponses diffusées par votre backend externe respectent les exigences de mise en cache de Cloud CDN. Par exemple, vous envoyez des en-têtes de réponse Cache-Control: public, max-age=3600 depuis l'origine.

Résoudre les problèmes liés aux NEG sans serveur

Avant de vous pencher sur les problèmes, familiarisez-vous avec les pages suivantes :

Les requêtes échouent et renvoient une erreur 404

Vérifiez que la ressource sans serveur sous-jacente (telle qu'un service App Engine, un service Cloud Run Functions ou un service Cloud Run) est toujours en cours d'exécution. Si la ressource sans serveur est supprimée, mais que le NEG sans serveur existe toujours, l'équilibreur de charge d'application externe continue à tenter d'acheminer les requêtes vers le service inexistant. Cela génère une réponse 404.

En général, un équilibreur de charge d'application externe ne peut pas détecter si la ressource sans serveur sous-jacente fonctionne comme prévu. Cela signifie que si votre service dans une région renvoie des erreurs, mais que l'infrastructure Cloud Run, fonctions Cloud Run ou App Engine fonctionne normalement dans votre région, votre équilibreur de charge d'application externe ne redirigera pas automatiquement le trafic dans d'autres régions. Veillez à tester soigneusement les nouvelles versions de vos services avant d'y acheminer le trafic de vos utilisateurs.

Gérer les incohérences entre les masques d'URL

Si l'application du masque d'URL configuré à une URL de requête utilisateur ne renvoie pas de nom de service ou si celui-ci n'existe pas, l'équilibreur de charge peut gérer ces incohérences différemment selon la plate-forme informatique sans serveur utilisée.

Cloud Run : en cas d'incohérence de masque d'URL, l'équilibreur de charge renvoie une erreur HTTP 404 (page introuvable).

Fonctions Cloud Run : en cas d'incohérence de masque d'URL, l'équilibreur de charge renvoie une erreur HTTP 404 (page introuvable).

App Engine : en cas d'incohérence de masque d'URL, App Engine utilise le fichier de distribution dispatch.yaml et la logique de routage par défaut d'App Engine pour déterminer le service auquel envoyer la requête.