Dépanner l'équilibrage de charge interne TCP/UDP

Ce guide explique comment résoudre les problèmes de configuration d'un équilibreur de charge TCP/UDP interne Google Cloud Platform.

Aperçu

Les types de problèmes abordés dans ce guide sont les suivants :

  • Problèmes de connectivité générale
  • Problèmes liés au basculement de backend (version bêta)
  • Problèmes d'équilibreur de charge défini en tant que saut suivant (version bêta)

Avant de commencer

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

Pour la connectivité générale :

Pour le basculement :

Pour le saut suivant :

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

  • Problème constaté : je ne parviens pas à me connecter à mon équilibreur de charge TCP/UDP interne à partir d'un client de VM situé dans une autre région.
  • Motif : les équilibreurs de charge TCP/UDP internes sont régionaux. Ils ne sont accessibles que depuis leur région.

Si vous ne parvenez pas à vous connecter à un équilibreur de charge TCP/UDP interne, vérifiez les points suivants :

  • 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 le client se connectant à l'équilibreur de charge se trouve dans la même région que celui-ci.

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 TCP/UDP interne 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, reportez-vous à la contrainte constraints/compute.restrictSharedVpcSubnetworks.

Résoudre les problèmes de basculement

Si vous avez configuré le basculement pour un équilibreur de charge TCP/UDP interne, 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. GCP 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 beta compute backend-services create my-failover-bs
  --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.beta.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

Version de l'API pour les backends de basculement

Actuellement, les options de basculement ne sont disponibles que dans l'API bêta. Si la création d'un service de backend échoue avec une erreur indiquant que failover options n'est pas un champ valide, assurez-vous que vous avez créé le service de backend en utilisant l'API correcte (gcloud beta compute backend-services...).

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 GCP effectue un basculement et une restauration automatique. Examinez la configuration de votre équilibreur de charge :

    • Utilisez la console GCP pour vérifier le nombre de VM de backend opérationnelles dans chaque groupe d'instances backend. La console GCP 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 GCP 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 : GCP 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 TCP/UDP interne en tant que saut suivant d'une route statique personnalisée, les problèmes suivants peuvent se produire :

Connectivité

  • Si vous ne pouvez pas pinguer le backend, gardez à l'esprit qu'une route avec l'équilibreur de charge TCP/UDP interne défini comme saut suivant n'est compatible qu'avec le trafic TCP et UDP. Les paquets des autres protocoles, tels qu'ICMP, sont supprimés.

  • En cas d'utilisation d'un équilibreur de charge TCP/UDP interne en tant que saut suivant pour une route statique personnalisée, l'ensemble du trafic TCP et UDP 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 indépendamment des 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 GCP.

Version de l'API pour le saut suivant

Actuellement, l'équilibreur de charge TCP/UDP interne en tant que saut suivant (--next-hop-ilb) n'est disponible que dans l'API bêta. Si la création d'une route statique échoue, assurez-vous que vous avez créé la route à l'aide de l'API appropriée (gcloud beta compute routes create...).

Tags réseau non acceptés

Vous ne pouvez pas attribuer un tag réseau à une route statique personnalisée lorsque le saut suivant est un équilibreur de charge TCP/UDP interne. Par exemple, la commande gcloud suivante génère le message d'erreur indiqué ci-dessous :

$ gcloud beta compute routes create example-route \
--destination-range=0.0.0.0/0 \
--next-hop-ilb=internal-lb-forwarding-rule \
--tags='my_tag'

ERROR: (gcloud.beta.compute.routes.create) Could not fetch resource:
 - Invalid value for field 'resource.tags': ''. Tag is not supported for routes
 with next hop ilb.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…