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

Ce guide explique comment résoudre les problèmes de configuration d'un équilibreur de charge réseau passthrough externeGoogle 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

Résoudre les problèmes de configuration

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 passthrough externe, vérifiez les problèmes courants suivants:

  • Vérifiez 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 passthrough externe, consultez la page Configurer les règles de pare-feu.

  • Vérifiez que l'agent invité Google est en cours d'exécution 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'agent invité Google (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'agent invité Google 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érifiez 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 passthrough externe 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.

    Pour afficher les services d'écoute sur un port, exécutez la commande suivante:

    netstat -nl | grep ':PORT'

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

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 passthrough externe 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 en savoir plus, consultez 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 passthrough externe, procédez comme suit pour vérifier votre configuration:

  • Assurez-vous de bien comprendre les concepts de sélection du backend et de suivi des connexions et de bascule.
  • Assurez-vous que vous avez désigné au moins un backend de basculement.
  • Vérifiez quels backends sont opérationnels à l'aide de la console Google Cloud ou de gcloud compute backend-services get-health pour déterminer quelles VM sont des backends éligibles.
  • Assurez-vous que le taux de basculement est correctement défini.
  • Nous vous déconseillons d'utiliser des groupes d'instances gérés avec l'autoscaling activé en même temps que le basculement, car l'autoscaling modifie le nombre de backends principaux, de backends de basculement ou des deux. Cela peut entraîner une modification inattendue de l'ensemble des backends éligibles, car le ratio de basculement est fixe.
  • Si une VM cliente est également une VM de backend à équilibrage de charge, les connexions à l'adresse IP de la règle de transfert de l'équilibreur de charge sont envoyées à la VM de backend elle-même. Pour en savoir plus, consultez Tester à partir d'un seul client.

Résoudre les problèmes de journalisation

Si vous configurez la journalisation pour un équilibreur de charge réseau passthrough externe, 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.