Résoudre les problèmes liés aux équilibreurs de charge réseau externes à stratégie directe

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

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 externe à stratégie directe, 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 externe à stratégie directe, 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 externe à stratégie directe 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 externe à 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 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 externe à stratégie directe, procédez comme suit pour vérifier votre configuration:

  • Assurez-vous que vous avez désigné au moins un backend de basculement.
  • Vérifiez les paramètres de votre règle de basculement.

  • Assurez-vous de bien comprendre le fonctionnement de l'appartenance au pool actif, et le moment où Google Cloud effectue le basculement et la restauration automatique. Inspectez la configuration de votre équilibreur de charge en procédant comme suit:

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

D'autres problèmes peuvent survenir:

  • Le pool actif bascule constamment (oscillation) entre le backend principal et le backend de basculement.

    L'utilisation de groupes d'instances gérés avec l'autoscaling et le basculement peut entraîner une répétition des opérations de basculement et de restauration du pool actif entre les backends principaux et 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.

  • La désactivation du drainage de connexion ne fonctionne pas.

    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
  --load-balancing-scheme external \
  --health-checks-region us-central1 \
  --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.

  • 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 de journalisation

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