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

Ce guide explique comment résoudre les problèmes de configuration d'un équilibreur de charge d'application interne Google Cloud. Avant de suivre ce guide, familiarisez-vous avec les points suivants :

• Présentation de l'équilibreur de charge d'application interne
• Sous-réseaux proxy réservés
• Journalisation et surveillance de l'équilibreur de charge d'application interne

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 :

• Restrictions et conseils concernant les groupes d'instances
• Modifier le mode d'équilibrage d'un équilibreur de charge

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

Ce comportement est normal. Un équilibreur de charge d'application interne fonctionne comme un proxy inverse (passerelle) HTTP (S). Lorsqu'un programme client ouvre une connexion à l'adresse IP d'une règle de transfert INTERNAL_MANAGED, la connexion se termine au niveau d'un proxy. Le proxy traite les requêtes qui arrivent sur cette connexion. Pour chaque requête, le proxy sélectionne un backend pour recevoir la requête en fonction du mappage d'URL et d'autres facteurs. Le proxy envoie ensuite la requête au backend sélectionné. Par conséquent, du point de vue du backend, la source d'un paquet entrant est une adresse IP issue du sous-réseau proxy réservé de la région.

Les requêtes sont rejetées par l'équilibreur de charge

Pour chaque requête, le proxy sélectionne un backend pour recevoir la requête en fonction d'un outil de mise en correspondance des chemins d'accès dans le mappage d'URL de l'équilibreur de charge. Si le mappage d'URL ne comporte pas d'outil de mise en correspondance des chemins d'accès défini pour une requête, il ne peut pas sélectionner de service de backend. Il renvoie donc un code de réponse HTTP 404 (Introuvable).

L'équilibreur de charge ne se connecte pas aux backends

Les pare-feu protégeant vos serveurs backend doivent être configurés pour autoriser le trafic entrant provenant des proxys de la plage de sous-réseaux proxy réservés alloués à la région de votre équilibreur de charge HTTP(S) interne.

Les proxys se connectent aux backends à l'aide des paramètres de connexion spécifiés par la configuration de votre service de backend. Si ces valeurs ne correspondent pas à la configuration des serveurs exécutés sur vos backends, le proxy ne peut pas transférer les requêtes aux backends.

Les vérifications d'état ne peuvent pas atteindre les backends

Pour vérifier que le trafic associé aux vérifications d'état atteint vos VM de backend, activez la journalisation des vérifications d'état et recherchez les entrées de journal ayant réussi.

Les clients ne peuvent pas se connecter à l'équilibreur de charge

Les proxys écoutent les connexions à l'adresse IP et au port configurés dans la règle de transfert (par exemple, 10.1.2.3:80) pour l'équilibreur de charge, avec le protocole spécifié dans la règle de transfert (HTTP ou HTTPS). Si vos clients ne parviennent pas à se connecter, vérifiez qu'ils utilisent la bonne adresse, le bon port et le bon protocole.

Assurez-vous qu'aucun pare-feu ne bloque le trafic entre vos instances clientes et l'adresse IP à équilibrage de charge.

Vérifiez que les clients se trouvent dans la même région que l'équilibreur de charge. L'équilibrage de charge HTTP(S) interne est un produit régional. Par conséquent, tous les clients (et backends) doivent se trouver dans la même région que la ressource d'équilibreur de charge.

Restriction relative aux règles d'administration pour les VPC partagés

Si vous utilisez un VPC partagé et que vous ne pouvez pas créer un équilibreur de charge d'application interne dans un sous-réseau particulier, une règle d'administration en est peut-être la cause. Dans la règle d'administration, ajoutez le sous-réseau à la liste des sous-réseaux autorisés ou contactez l'administrateur de votre organisation. Pour en savoir plus, consultez les sections sur constraints/compute.restrictSharedVpcSubnetworks

L'équilibreur de charge ne répartit pas le trafic uniformément entre les zones

Vous pouvez constater un déséquilibre dans le trafic de votre équilibreur de charge d'application interne entre les zones. Cela peut se produire en particulier lorsque vous utilisez peu votre backend (< 10 % de sa capacité).

Ce comportement peut affecter la latence globale, car le trafic est envoyé à seulement quelques serveurs d'une même zone.

Pour équilibrer la répartition du trafic entre les zones, vous pouvez apporter les modifications de configuration suivantes :

• Utilisez le mode d'équilibrage RATE avec une faible capacité cible (max-rate-per-instance).
• Utilisez la règle de trafic du backend LocalityLbPolicy avec un algorithme d'équilibrage de charge LEAST_REQUEST.

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 d'état HTTP (5xx) et renvoie ce code d'état 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 proxyStatus des journaux de l'équilibreur de charge.

Les modifications de configuration de l'équilibreur de charge d'application interne, 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'état HTTP 503. Pendant que ces modifications de configuration sont appliquées aux Envoy dans le monde entier, des entrées de journal dont le champ proxyStatus correspond à la chaîne de journal connection_refused s'affichent.

Si les codes d'état 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 proxyStatus renvoyant destination_unavailable, ce qui indique que l'équilibreur de charge considère le backend comme indisponible.

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 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 d'état 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).

Limites

Si vous rencontrez des difficultés pour utiliser un équilibreur de charge d'application interne avec d'autres fonctionnalités de mise en réseau Google Cloud, notez les limites de compatibilité actuelles.