Résoudre les problèmes liés aux équilibreurs de charge réseau passthrough internes

Ce guide explique comment résoudre les problèmes de configuration d'un équilibreur de charge réseau interne à stratégie directe Google Cloud. 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

Si vous ne parvenez pas à vous connecter à votre équilibreur de charge réseau interne à stratégie directe, vérifiez les problèmes courants suivants.

Vérifier les règles de pare-feu

  • Assurez-vous que les règles de pare-feu autorisant les entrées sont définies afin de permettre les vérifications de l'état des VM de backend.
  • Assurez-vous que les règles de pare-feu autorisant les entrées autorisent le trafic vers les VM de backend à partir des clients.
  • Assurez-vous que des règles de pare-feu pertinentes permettent au trafic d'atteindre les VM de backend sur les ports utilisés par l'équilibreur de charge.
  • Si vous utilisez des tags cibles pour les règles de pare-feu, assurez-vous que les VM de backend de l'équilibreur de charge sont correctement étiquetés.

Pour apprendre à configurer les règles de pare-feu requises par votre équilibreur de charge réseau interne à stratégie directe, consultez la page Configurer les règles de pare-feu.

Vérifiez que l'environnement invité s'exécute sur la VM de backend.

Si vous pouvez vous connecter à une VM de backend opérationnelle, mais que vous ne pouvez pas vous connecter à l'équilibreur de charge, il se peut que l'environnement invité (anciennement, l'environnement invité Windows ou Linux) sur la VM ne s'exécute pas ou ne puisse pas communiquer avec le serveur de métadonnées (metadata.google.internal, 169.254.169.254).

Effectuez les vérifications suivantes :

  • Vérifiez que l'environnement invité est installé et s'exécute sur la VM de backend.
  • Assurez-vous que les règles de pare-feu du système d'exploitation invité de la VM de backend (iptables ou pare-feu Windows) ne bloquent pas l'accès au serveur de métadonnées.

Vérifier que les VM de backend acceptent les paquets envoyés à l'équilibreur de charge

Chaque VM de backend doit être configurée pour accepter les paquets envoyés à l'équilibreur de charge. En d'autres termes, la destination des paquets distribués aux VM de backend est l'adresse IP de l'équilibreur de charge. Dans la plupart des cas, ceci est mis en œuvre via l'utilisation d'une route locale.

Pour les VM créées à partir d'images Google Cloud, l'agent invité installe la route locale pour l'adresse IP de l'équilibreur de charge. Les instances Google Kubernetes Engine basées sur Container-Optimized OS implémentent ceci en utilisant plutôt iptables.

Sur une VM de backend Linux, vous pouvez vérifier la présence de la route locale en exécutant la commande suivante. Remplacez LOAD_BALANCER_IP par l'adresse IP de l'équilibreur de charge :

sudo ip route list table local | grep LOAD_BALANCER_IP

Vérifiez l'adresse IP du service et la liaison de port sur les VM de backend.

Les paquets envoyés à un équilibreur de charge réseau interne arrivent sur les VM de backend avec l'adresse IP de destination de l'équilibreur de charge lui-même. Ce type d'équilibreur de charge n'est pas un proxy, et ce comportement est normal.

Le logiciel s'exécutant sur la VM de backend doit effectuer les opérations suivantes :

  • Écouter (être associé à) l'adresse IP de l'équilibreur de charge ou toute adresse IP (0.0.0.0 ou ::)
  • Écouter (être associé à) un port inclus dans la règle de transfert de l'équilibreur de charge

Pour tester ce processus, connectez-vous à une VM de backend à l'aide de SSH ou de RDP. Ensuite, effectuez les tests suivants à l'aide de curl, telnet ou d'un outil similaire :

  • Essayez d'accéder au service en le contactant à l'aide de l'adresse IP interne de la VM de backend elle-même, 127.0.0.1, ou localhost.
  • Essayez d'accéder au service en le contactant à l'aide de l'adresse IP de la règle de transfert de l'équilibreur de charge.

Vérifiez si la VM cliente se trouve dans la même région que l'équilibreur de charge.

Si le client se connectant à l'équilibreur de charge se trouve dans une autre région, assurez-vous que l'accès mondial est activé.

Vérifiez que le trafic de vérification de l'état peut atteindre les VM de backend.

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.

Vous pouvez également vérifier que la fonctionnalité d'équilibreur de charge est opérationnelle en affichant l'état "Opérationnel" pour le backend.

Si le backend ne comporte aucune instance opérationnelle, assurez-vous que la vérification d'état appropriée est configurée et que chaque VM du backend écoute les ports de vérification d'état configurés.

À partir d'un client appartenant au même réseau VPC, exécutez la commande suivante pour vérifier que la VM de backend écoute un port TCP spécifique :

telnet SERVER_IP_ADDRESS PORT

Remplacez les éléments suivants :

  • SERVER_IP_ADDRESS : adresse IP de la VM de backend.
  • PORT : port que vous avez configuré pour la vérification d'état. Par défaut, le port de vérification de l'état est 80.

Vous pouvez également utiliser SSH pour connecter la VM de backend et exécuter la commande suivante :

curl localhost:PORT

Encore une fois, remplacez PORT par le port que vous avez configuré pour votre vérification d'état.

Une autre façon d'effectuer ce test consiste à exécuter la commande suivante :

netstat -npal | grep LISTEN

Dans le résultat, recherchez ce qui suit :

  • <var>LB_IP_ADDRESS</var>:<var>PORT</var>
  • 0.0.0.0:<var>PORT</var>
  • :::<var>PORT</var>

Cela ne détermine pas si le routage est correctement configuré pour répondre à l'adresse IP de l'équilibreur de charge. Il s'agit d'un problème distinct avec un symptôme similaire. Pour le routage, exécutez la commande ip route list table local et vérifiez que l'adresse IP de l'équilibreur de charge est répertoriée, comme décrit dans la section Vérifier que les VM de backend acceptent les paquets envoyés à l'équilibreur de charge.

Résoudre les problèmes liés aux performances

Si vous remarquez des problèmes de performances et une latence accrue, vérifiez les problèmes courants suivants.

Vérifier le fonctionnement du serveur

Si tous les serveurs de backend répondent aux vérifications d'état, vérifiez que les requêtes du client fonctionnent correctement lorsqu'elles sont émises directement sur le serveur. Par exemple, si le client envoie des requêtes HTTP au serveur via l'équilibreur de charge et qu'il n'y a pas de réponse, ou que la réponse est nettement plus lente que d'habitude, envoyez la même requête HTTP surChacun des serveurs backend et observez le comportement.

Si l'un des serveurs backend individuels ne se comporte pas correctement lorsque la requête est émise depuis le serveur lui-même, vous pouvez en conclure que la pile des applications du serveur ne fonctionne pas correctement. Vous pouvez vous concentrer sur le dépannage de l'application elle-même. Si tous les serveurs fonctionnent correctement, l'étape suivante consiste à examiner le client et le réseau.

Vérifier la connectivité réseau et la latence

Si tous les serveurs de backend répondent correctement aux requêtes, vérifiez la latence du réseau. À partir d'une VM cliente, exécutez une commande ping constante sur chaque serveur, comme suit :

ping SERVER_IP_ADDRESS

Ce test montre la latence du réseau intégré et si le réseau supprime des paquets. Dans certains cas, des règles de pare-feu peuvent bloquer le trafic ICMP. Si tel est le cas, ce test ne produit aucun résultat. Vérifiez auprès de l'administrateur de vos règles de pare-feu si c'est le cas.

Si la commande ping affiche une latence nettement supérieure à celle d'une perte de paquets normale ou importante, ouvrez une demande d'assistance Google Cloud pour une analyse plus approfondie.

Identifier les combinaisons client-serveur problématiques

Si le test ping du réseau suggère une faible latence et aucune perte de paquets, l'étape suivante consiste à identifier la combinaison client-serveur spécifique, le cas échéant, qui produit des résultats problématiques. Pour ce faire, vous pouvez réduire le nombre de serveurs backend de moitié jusqu'à atteindre 1, tout en reproduisant simultanément le comportement problématique (par exemple, une latence élevée ou aucune réponse).

Si vous identifiez une ou plusieurs combinaisons client/serveur problématiques, effectuez une capture et analyse du trafic.

Si aucune combinaison client-serveur problématique n'est identifiée, passez à la section Tests de performances.

Effectuer une capture et une analyse du trafic

Si vous identifiez une combinaison problématique spécifique serveur-client, vous pouvez utiliser la capture de paquets pour identifier la partie de la communication qui entraîne un retard ou une rupture. La capture de paquets peut être effectuée avec tcpdump comme suit :

  1. Installez tcpdump sur le serveur.
  2. Démarrez la capture tcpdump sur le serveur.

  3. À partir d'un client, émettez un exemple de requête, tel que :

    curl URL

  4. Analysez le résultat de tcpdump pour identifier le problème.

Effectuez des tests de performances

Si vous n'identifiez aucune combinaison client-serveur problématique et que les performances globales de tous les clients et serveurs sont inférieures aux prévisions, envisagez les tests suivants :

  1. Un client et un serveur, sans équilibrage de charge

  2. Un client et un serveur, avec équilibrage de charge

    Résultat : la combinaison des résultats des tests [1] et [2] détermine si l'équilibreur de charge est à l'origine du problème.

  3. Un client et plusieurs serveurs, avec un équilibrage de charge

    Résultat : identifier la limite de performances d'un client.

  4. Plusieurs clients et un seul serveur, avec équilibrage de charge

    Résultat : identifiez la limite de performances d'un serveur.

  5. Plusieurs clients et plusieurs serveurs, sans équilibrage de charge

    Résultat : identifier la limite de performances du réseau.

Lorsque vous exécutez un test de contrainte avec plusieurs clients et serveurs, les ressources client ou serveur (processeur, mémoire, E/S) peuvent entraîner des goulots d'étranglement et réduire les résultats agrégés. Une dégradation des résultats agrégés peut se produire même si chaque client et serveur se comporte correctement.

Résoudre les problèmes liés aux réseaux VPC partagés

Si vous utilisez un VPC partagé et que vous ne pouvez pas créer un équilibreur de charge réseau interne à stratégie directe dans un sous-réseau particulier, cela peut être dû à une règle d'administration. 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 plus d'informations, consultez la documentation sur la contrainte constraints/compute.restrictSharedVpcSubnetworks.

Résoudre les problèmes de basculement

Si vous avez configuré le basculement pour un équilibreur de charge réseau interne à stratégie directe, les sections suivantes décrivent les problèmes qui peuvent survenir.

Connectivité

  • Assurez-vous que vous avez désigné au moins un backend de basculement.
  • Vérifiez les paramètres de votre règle de basculement :
    • Taux de basculement
    • Suppression du trafic lorsqu'aucune VM de backend n'est opérationnelle
    • Désactivation du drainage de connexion lors du basculement

Problèmes liés aux groupes d'instances gérés et au basculement

  • Problème constaté : le pool actif bascule constamment (oscillation) entre le backend principal et le backend de basculement.
  • Motif possible : l'utilisation de groupes d'instances gérés avec autoscaling et basculement peut entraîner le basculement et la restauration automatique répétés du pool actif entre le backend principal et le backend de basculement. Google Cloud ne vous empêche pas de configurer le basculement avec les groupes d'instances gérés, car cette configuration pourrait être bénéfique pour votre déploiement.

Désactiver la restriction sur le drainage de connexion pour les groupes de basculement

La désactivation du drainage de connexion ne fonctionne que si le service de backend est configuré avec le protocole TCP.

Le message d'erreur suivant s'affiche si vous créez un service de backend avec UDP alors que le drainage de connexion est désactivé :

gcloud compute backend-services create my-failover-bs \
    --global-health-checks \
    --load-balancing-scheme=internal \
    --health-checks=my-tcp-health-check \
    --region=us-central1 \
    --no-connection-drain-on-failover \
    --drop-traffic-if-unhealthy \
    --failover-ratio=0.5 \
    --protocol=UDP
ERROR: (gcloud.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

Trafic envoyé à des VM de backend inattendues

Commencez par vérifier le point suivant : si la VM cliente est également une VM de backend de l'équilibreur de charge, le comportement attendu est que les connexions envoyées à l'adresse IP de la règle de transfert de l'équilibreur de charge sont toujours prises en charge par la VM de backend elle-même. Pour plus d'informations, reportez-vous au test des connexions à partir d'un client unique et à l'envoi de requêtes à partir de VM à équilibrage de charge.

Si la VM cliente n'est pas une VM de backend de l'équilibreur de charge :

  • Pour les requêtes émanant d'un seul client, reportez-vous au test des connexions à partir d'un client unique afin de comprendre les limites de cette méthode.

  • Assurez-vous que vous avez configuré les règles de pare-feu autorisant les entrées de façon à autoriser les vérifications de l'état.

  • Pour la configuration du basculement, veillez à comprendre le fonctionnement de l'appartenance au pool actif, et à quel moment Google Cloud effectue un basculement et une restauration automatique. Examinez la configuration de votre équilibreur de charge :

    • Utilisez la console Google Cloud pour vérifier le nombre de VM de backend opérationnelles dans chaque groupe d'instances backend. La console Google Cloud vous indique également quelles VM se trouvent dans le pool actif.

    • Assurez-vous que le taux de basculement de l'équilibreur de charges est correctement défini. Par exemple, si vous avez dix VM principales et un ratio de basculement de 0.2, cela signifie que Google Cloud effectue un basculement lorsque moins de deux (10 × 0.2 = 2) VM principales sont opérationnelles. Un taux de basculement de 0.0 a une signification particulière : Google Cloud effectue un basculement lorsqu'aucune VM principale n'est opérationnelle.

Connexions existantes interrompues pendant le basculement ou la restauration automatique

Modifiez la règle de basculement du service de backend. Assurez-vous que le drainage de connexion lors du basculement est activé.

Résoudre les problèmes liés à l'équilibreur de charge en tant que saut suivant

Lorsque vous définissez un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant d'une route statique personnalisée, les problèmes suivants peuvent se produire :

Problèmes de connectivité

  • Si vous ne pouvez pas pinguer une adresse IP dans la plage de destination d'une route dont le saut suivant est une règle de transfert pour un équilibreur de charge réseau interne à stratégie directe, notez qu'une route utilisant ce type de saut suivant peut ne pas traiter le trafic ICMP selon la date de création de la route. Si la route a été créée avant le 15 mai 2021, elle ne traite que le trafic TCP et UDP jusqu'au 16 août 2021. À compter du 16 août 2021, toutes les routes transfèrent automatiquement tout le trafic des protocoles (TCP, UDP et ICMP), quelle que soit la date de création des routes. Si vous ne souhaitez pas attendre, vous pouvez activer la fonctionnalité de ping dès maintenant en créant des routes et en supprimant les anciennes.

  • Lorsque vous utilisez un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant pour une route statique personnalisée, l'ensemble du trafic est distribué aux VM de backend opérationnelles de l'équilibreur de charge, quel que soit le protocole configuré pour le service de backend interne de l'équilibreur de charge et quel que soit le ou les ports configurés sur la règle de transfert interne de l'équilibreur de charge.

  • Vérifiez que vous avez créé des règles de pare-feu autorisant les entrées qui identifient correctement les sources de trafic à distribuer aux VM de backend via le saut suivant de la route statique personnalisée. Les paquets qui arrivent sur les VM de backend conservent leur adresse IP source, même lorsqu'ils sont transmis via une route statique personnalisée.

Valeur incorrecte pour la plage de destination

La plage de destination d'une route statique personnalisée ne peut pas être plus spécifique que les routes de sous-réseau dans votre réseau VPC. Si vous recevez le message d'erreur suivant lors de la création d'une route statique personnalisée :

Invalid value for field 'resource.destRange': [ROUTE_DESTINATION].
[ROUTE_DESTINATION] hides the address space of the network .... Cannot change
the routing of packets destined for the network.

  • Vous ne pouvez pas créer une route statique personnalisée avec une destination qui correspond exactement à une route de sous-réseau ou est plus spécifique (avec un masque plus long). Pour plus d'informations, reportez-vous à l'applicabilité et à l'ordre de priorité.

  • Si des paquets sont dirigés vers une destination inattendue, supprimez les autres routes de votre réseau VPC avec des destinations plus spécifiques. Examinez l'ordre de routage pour comprendre la sélection de route de Google Cloud.

Résoudre les problèmes de journalisation

Si vous configurez la journalisation pour un équilibreur de charge réseau interne à stratégie directe, les problèmes suivants peuvent se produire :

  • Les mesures de latence DAR, telles que les valeurs de type octet, peuvent ne pas figurer dans certains journaux si le nombre de paquets échantillonnés est insuffisant pour capturer cette valeur. Cette situation est davantage susceptible de se produire pour les connexions à faible volume.
  • Les valeurs de type DAR ne sont disponibles que pour les flux TCP.
  • Certains paquets sont envoyés sans charge utile. Si l'échantillonnage porte sur des paquets ne comportant que des en-têtes, la valeur de type octet est 0.

Étapes suivantes