Présentation des groupes de points de terminaison du réseau de connectivité hybride

Cloud Load Balancing prend en charge le trafic d'équilibrage de charge vers des points de terminaison qui vont au-delà de Google Cloud, tels que des centres de données sur site et d'autres clouds publics que vous pouvez atteindre en utilisant la connectivité hybride.

Une stratégie hybride est une solution pragmatique qui vous permet de vous adapter aux exigences changeantes du marché et de moderniser progressivement vos applications. Il peut s'agir d'un déploiement hybride temporaire permettant la migration vers une solution cloud moderne ou d'un dispositif permanent de l'infrastructure informatique de votre organisation.

La configuration de l'équilibrage de charge hybride vous permet également de bénéficier des avantages des fonctionnalités réseau de Cloud Load Balancing pour les services exécutés sur votre infrastructure existante en dehors de Google Cloud.

L'équilibrage de charge hybride est compatible avec les équilibreurs de charge Google Cloud suivants :

Les services sur site ou sur d'autres cloud sont traités comme n'importe quel autre backend du service Cloud Load Balancing. La principale différence est que vous utilisez un NEG de connectivité hybride pour configurer les points de terminaison de ces backends. Les points de terminaison doivent être des combinaisons IP:port valides que votre équilibreur de charge peut atteindre à l'aide de produits de connectivité hybrides, tels que Cloud VPN ou Cloud Interconnect.

Cas d'utilisation : routage du trafic vers un emplacement sur site ou un autre cloud

Le cas d'utilisation le plus simple pour utiliser des NEG hybrides consiste à acheminer le trafic depuis un équilibreur de charge Google Cloud vers un emplacement sur site ou un autre environnement cloud. Les clients peuvent générer du trafic à partir de l'Internet public, de Google Cloud ou d'un client sur site.

Clients publics

Vous pouvez utiliser un équilibreur de charge d'application externe avec un backend de NEG hybride pour acheminer du trafic depuis des clients externes vers un backend sur site ou dans un autre réseau cloud. Vous pouvez également activer les fonctionnalités suivantes de mise en réseau à valeur ajoutée pour vos services sur site ou dans d'autres réseaux cloud :

  • Avec l'équilibreur de charge d'application externe global et l'équilibreur de charge d'application classique, vous pouvez :

    • Utiliser l'infrastructure périphérique mondiale de Google pour interrompre les connexions utilisateur les plus proches de l'utilisateur, ce qui réduit la latence.
    • Protéger votre service avec Google Cloud Armor, un produit de sécurité WAF/défense contre les attaques DDoS de périphérie disponible pour tous les services accessibles via un équilibreur de charge d'application externe.
    • Activer votre service pour optimiser la diffusion à l'aide de Cloud CDN. Grâce à celui-ci, vous pouvez mettre en cache du contenu à proximité de vos utilisateurs. Cloud CDN offre des fonctionnalités telles que l'invalidation de cache et des URL signées Cloud CDN.
    • Utiliser des certificats SSL gérés par Google. Vous pouvez réutiliser des certificats et des clés privées que vous utilisez déjà pour d'autres produits Google Cloud. Cela évite d'avoir à gérer des certificats distincts.

    Le schéma suivant illustre un déploiement hybride avec un équilibreur de charge d'application externe.

    Connectivité hybride avec un équilibreur de charge d'application externe global.
    Connectivité hybride avec un équilibreur de charge d'application externe global (cliquez pour agrandir)

    Dans ce schéma, le trafic des clients situés sur le réseau Internet public entre dans votre réseau privé sur site ou cloud via un équilibreur de charge Google Cloud, tel que l'équilibreur de charge d'application externe. Lorsque le trafic atteint l'équilibreur de charge, vous pouvez appliquer des services de périphérie du réseau tels que la protection DDoS avec Google Cloud Armor ou l'authentification des utilisateurs avec Identity-Aware Proxy (IAP).

  • Avec l'équilibreur de charge d'application externe régional, vous pouvez acheminer le trafic externe vers des points de terminaison situés dans la même région Google Cloud que les ressources de l'équilibreur de charge. Utilisez cet équilibreur de charge si vous devez diffuser du contenu à partir d'une seule géolocalisation (par exemple, pour respecter les réglementations de conformité) ou si vous souhaitez utiliser le niveau de service réseau standard.

Le mode de routage de la requête (vers un backend Google Cloud ou un point de terminaison sur site/cloud) dépend de la configuration de votre mappage d'URL. En fonction de votre mappage d'URL, l'équilibreur de charge sélectionne un service de backend pour la requête. Si le service de backend sélectionné a été configuré avec un NEG de connectivité hybride (utilisé uniquement pour les points de terminaison autres que Google Cloud), l'équilibreur de charge transfère le trafic via Cloud VPN ou Cloud Interconnect vers sa destination externe prévue.

Clients internes (dans Google Cloud ou sur site)

Vous pouvez également configurer un déploiement hybride pour les clients internes à Google Cloud. Dans ce cas, le trafic client provient du réseau VPC Google Cloud, de votre réseau sur site ou d'un autre cloud, et est acheminé vers des points de terminaison sur site ou dans d'autres réseaux cloud.

L'équilibreur de charge d'application interne régional est un équilibreur de charge régional, ce qui signifie qu'il ne peut acheminer le trafic que vers des points de terminaison situés dans la même région Google Cloud que les ressources de l'équilibreur de charge. L'équilibreur de charge d'application interne interrégional est un équilibreur de charge multirégional qui peut équilibrer la charge du trafic vers les services de backend distribués à l'échelle mondiale.

Le schéma suivant illustre un déploiement hybride avec un équilibreur de charge d'application interne régional.

Connectivité hybride avec des équilibreurs de charge d'application internes régionaux.
Connectivité hybride avec des équilibreurs de charge d'application internes régionaux (cliquez pour agrandir)

Cas d'utilisation : migrer vers le cloud

La migration d'un service existant vers le cloud vous permet de libérer la capacité sur site et de réduire la charge de travail et les coûts liés à la maintenance d'une infrastructure sur site. Vous pouvez configurer temporairement un déploiement hybride qui vous permet d'acheminer le trafic vers votre service sur site actuel et vers un point de terminaison de service Google Cloud correspondant.

Le schéma suivant illustre cette configuration avec un équilibreur de charge d'application interne.

Migrer vers Google Cloud
Migrer vers Google Cloud (cliquez pour agrandir)

Si vous utilisez un équilibreur de charge d'application interne pour gérer des clients internes, vous pouvez le configurer pour répartir le trafic en fonction du poids entre les deux services. La répartition du trafic vous permet de commencer par envoyer 0 % du trafic au service Google Cloud et 100 % au service sur site. Vous pouvez ensuite augmenter progressivement la proportion du trafic envoyée au service Google Cloud. Une fois que l'intégralité du trafic est envoyée vers le service Google Cloud, vous pouvez supprimer le service sur site.

Architecture hybride

Cette section décrit l'architecture d'équilibrage de charge et les ressources nécessaires pour configurer un déploiement d'équilibrage de charge hybride.

Les services sur site ou sur d'autres cloud sont traités comme n'importe quel autre backend du service Cloud Load Balancing. La principale différence est que vous utilisez un NEG de connectivité hybride pour configurer les points de terminaison de ces backends. Les points de terminaison doivent être des combinaisons IP:port valides que vos clients peuvent atteindre via une connectivité hybride (Cloud VPN ou Cloud Interconnect par exemple).

Les schémas suivants illustrent les ressources Google Cloud requises pour activer l'équilibrage de charge hybride pour les équilibreurs de charge d'application externes et les équilibreurs de charge d'application internes régionaux.

HTTP(S) externe global

Ressources de l'équilibreur de charge d'application externe global pour la connectivité hybride
Ressources de l'équilibreur de charge d'application externe global pour la connectivité hybride (cliquez pour agrandir)

HTTP(S) externe régional

Ressources de l'équilibreur de charge d'application externe régional pour la connectivité hybride.
Ressources de l'équilibreur de charge d'application externe régional pour la connectivité hybride (cliquez pour agrandir)

HTTP(S) interne régional

Ressources de l'équilibreur de charge d'application interne régional pour la connectivité hybride.
Ressources de l'équilibreur de charge d'application interne régional pour la connectivité hybride (cliquez pour agrandir)

Proxy interne régional

Ressources de l'équilibreur de charge réseau proxy interne régional pour la connectivité hybride
Ressources de l'équilibreur de charge réseau proxy interne régional pour la connectivité hybride (cliquez pour agrandir)

Routage régional ou global

Le routage Cloud Load Balancing dépend du champ d'application de l'équilibreur de charge configuré :

Équilibreur de charge d'application externe et équilibreur de charge réseau proxy externe. Ces équilibreurs de charge peuvent être configurés pour un routage global ou régional en fonction du niveau de réseau utilisé. Vous créez le backend de NEG hybride de l'équilibreur de charge dans le même réseau et la même région que ceux où la connectivité hybride a été configurée. Les points de terminaison autres que Google Cloud doivent également être configurés en conséquence pour tirer parti de l'équilibrage de charge basé sur la proximité.

Équilibreur de charge d'application interne interrégional et équilibreur de charge réseau proxy interne interrégional. Il s'agit d'un équilibreur de charge multirégional qui peut équilibrer la charge du trafic vers les services de backend distribués à l'échelle mondiale. Vous créez le backend de NEG hybride de l'équilibreur de charge dans le même réseau et la même région que ceux où la connectivité hybride a été configurée. Les points de terminaison autres que Google Cloud doivent également être configurés en conséquence pour tirer parti de l'équilibrage de charge basé sur la proximité.

Équilibreur de charge d'application interne régional et équilibreur de charge réseau proxy interne régional. Il s'agit d'équilibreurs de charge régionaux. Autrement dit, ils ne peuvent acheminer le trafic que vers des points de terminaison situés dans la même région que l'équilibreur de charge. Les composants de l'équilibreur de charge doivent être configurés dans la même région que celle où la connectivité hybride a été configurée. Par défaut, les clients accédant à l'équilibreur de charge doivent également se trouver dans la même région. Toutefois, si vous activez l'accès mondial, les clients de n'importe quelle région peuvent accéder à l'équilibreur de charge.

Par exemple, si la passerelle Cloud VPN ou le rattachement de VLAN Cloud Interconnect est configuré dans us-central1, les ressources requises par l'équilibreur de charge (telles qu'un service de backend, un NEG hybride ou une règle de transfert) doivent être créés dans la région us-central1. Par défaut, les clients accédant à l'équilibreur de charge doivent également se trouver dans la région us-central1. Toutefois, si vous activez l'accès mondial, les clients de n'importe quelle région peuvent accéder à l'équilibreur de charge.

Connectivité réseau requise

Avant de configurer un déploiement d'équilibrage de charge hybride, vous devez disposer des ressources suivantes :

  • Réseau VPC Google Cloud. Un réseau VPC configuré dans Google Cloud. Il s'agit du réseau VPC utilisé pour configurer Cloud Interconnect/Cloud VPN et Cloud Router. Il s'agit également du réseau dans lequel vous allez créer les ressources d'équilibrage de charge (règle de transfert, proxy cible, service de backend, etc.). Les adresses IP de sous-réseau Google Cloud et les plages d'adresses IP sur site et d'autres clouds ne doivent pas se chevaucher. Lorsque les adresses IP se chevauchent, les routes de sous-réseau sont prioritaires sur la connectivité à distance.
  • Connectivité hybride. Votre environnement Google Cloud, ainsi que votre environnement sur site ou d'autres environnements cloud, doivent être connectés via une connectivité hybride, en utilisant des rattachements de VLAN Cloud Interconnect ou des tunnels Cloud VPN avec Cloud Router. Nous vous recommandons d'utiliser une connexion à haute disponibilité. Lorsque le routage dynamique global est activé, le routeur Cloud Router apprend le point de terminaison spécifique par l'intermédiaire du protocole BGP et le programme dans votre réseau VPC Google Cloud. Le routage dynamique régional n'est pas pris en charge. De même, les routes statiques ne sont pas prises en charge.

    Cloud Interconnect/Cloud VPN et Cloud Router doivent être configurés dans le même réseau VPC que celui que vous prévoyez d'utiliser pour le déploiement de l'équilibrage de charge hybride. Cloud Router doit également annoncer les routes suivantes vers votre environnement sur site :

    • Plages utilisées par les vérifications d'état de Google : 35.191.0.0/16 et 130.211.0.0/22. Cela n'est pas obligatoire si vous n'utilisez que des vérifications d'état Envoy distribuées.
    • Plage du sous-réseau proxy réservé de la région : pour les équilibreurs de charge basés sur Envoy (équilibreurs de charge d'application externes régionaux, équilibreurs de charge réseau proxy externes régionaux, équilibreurs de charge réseau proxy internes régionaux et équilibreurs de charge d'application internes).
  • Points de terminaison du réseau (IP:Port) sur site ou dans d'autres clouds. Un ou plusieurs points de terminaison du réseau IP:Port configurés dans votre environnement sur site ou dans d'autres environnements cloud et qui peuvent être routés via Cloud Interconnect ou Cloud VPN. S'il existe plusieurs chemins d'accès au point de terminaison IP, le routage suit le comportement décrit dans la présentation des routes VPC et la présentation de Cloud Router.

  • Règles de pare-feu de vos environnements situés sur site ou sur d'autres cloud. Les règles de pare-feu suivantes doivent être créées dans votre environnement sur site ou dans un autre environnement cloud :

    • Règles de pare-feu d'entrée autorisant le trafic en provenance des vérifications d'état de Google et à destination de vos points de terminaison. Les plages à autoriser sont : 35.191.0.0/16 et 130.211.0.0/22. Notez que ces plages doivent également être annoncées par Cloud Router sur votre réseau sur site. Pour plus de détails, consultez la section plages d'adresses IP de vérification et règles de pare-feu.
    • Règles d'autorisation du pare-feu d'entrée permettant au trafic qui fait l'objet d'un équilibrage de charge d'atteindre les points de terminaison.
    • Pour les équilibreurs de charge basés sur Envoy, équilibreurs de charge d'application externes régionaux, équilibreurs de charge réseau proxy externes régionaux, équilibreurs de charge réseau proxy internes régionaux, équilibreurs de charge réseau proxy internes interrégionaux et équilibreurs de charge d'application internes, vous devez également créer une règle de pare-feu pour autoriser le trafic provenant du sous-réseau proxy réservé de la région pour atteindre les points de terminaison situés sur site ou dans d'autres environnements cloud.

Composants de l'équilibreur de charge

Selon le type d'équilibreur de charge, vous pouvez configurer un déploiement d'équilibrage de charge hybride à l'aide des niveaux de service réseau Standard ou Premium.

Un équilibreur de charge hybride nécessite une configuration spéciale uniquement pour le service de backend. La configuration de frontend est identique à celle de n'importe quel autre équilibreur de charge. Équilibreurs de charge basés sur Envoy : équilibreurs de charge d'application externes régionaux, équilibreurs de charge réseau proxy externes régionaux, équilibreurs de charge réseau proxy internes régionaux, équilibreurs de charge réseau proxy internes interrégionaux et équilibreurs de charge d'application internes, nécessitent un sous-réseau proxy réservé supplémentaire pour exécuter des proxys Envoy en votre nom.

Configuration de l'interface

Aucune configuration de frontend spéciale n'est requise pour l'équilibrage de charge hybride. Les règles de transfert permettent d'acheminer le trafic vers un proxy cible sur la base de l'adresse IP, du port et du protocole. Le proxy cible met ensuite fin aux connexions des clients.

Les mappages d'URL sont utilisés par les équilibreurs de charge HTTP(S) pour configurer le routage basé sur l'URL des requêtes vers les services de backend appropriés.

Pour en savoir plus sur chacun de ces composants, consultez les sections d'architecture des présentations spécifiques de l'équilibreur de charge :

Service de backend

Les services de backend fournissent des informations de configuration à l'équilibreur de charge. Les équilibreurs de charge utilisent les informations d'un service de backend pour rediriger le trafic entrant vers un ou plusieurs backends associés.

Pour configurer un déploiement d'équilibrage de charge hybride, vous devez configurer l'équilibreur de charge avec des backends situés à la fois dans Google Cloud et en dehors de Google Cloud.

  • Backends autres que Google Cloud (sur site ou sur d'autres cloud)

    Toute destination accessible à l'aide des produits de connectivité hybride de Google (Cloud VPN ou Cloud Interconnect) et accessible via une combinaison IP:Port valide peut être configurée en tant que point de terminaison pour l'équilibreur de charge.

    Configurez vos backends autres que Google Cloud comme suit :

    1. Ajoutez la combinaison IP:Port de chaque point de terminaison du réseau situé en dehors de Google Cloud à un groupe de points de terminaison du réseau (NEG) de connectivité hybride. Assurez-vous que cette adresse IP et ce port sont accessibles depuis Google Cloud par l'intermédiaire d'une connectivité hybride (Cloud VPN ou Cloud Interconnect). Pour les NEG de connectivité hybride, définissez le type de point de terminaison du réseau sur NON_GCP_PRIVATE_IP_PORT.
    2. Lors de la création du NEG, spécifiez une zone Google Cloud qui réduit la distance géographique entre Google Cloud et votre environnement sur site ou un autre environnement cloud. Par exemple, si vous hébergez un service dans un environnement sur site à Francfort, en Allemagne, vous pouvez spécifier la zone Google Cloud europe-west3-a lorsque vous créez le NEG.
    3. Ajoutez ce NEG de connectivité hybride en tant que backend pour le service de backend.

      Un NEG de connectivité hybride ne doit inclure que des points de terminaison autres que Google Cloud. Le trafic peut être interrompu si un NEG hybride inclut des points de terminaison pour les ressources d'un réseau VPC Google Cloud, tels que les adresses IP des règles de transfert pour les équilibreurs de charge réseau passthrough internes. Configurez les points de terminaison Google Cloud comme indiqué dans la section suivante.

  • Backends Google Cloud

    Configurez vos points de terminaison Google Cloud comme suit :

    1. Créez un service de backend distinct pour les backends Google Cloud.
    2. Configurez plusieurs backends (NEG zonaux GCE_VM_IP_PORT ou groupes d'instances) dans la même région que celle où vous avez configuré la connectivité hybride.

Autres points à prendre en compte :

  • Chaque NEG de connectivité hybride ne peut contenir que des points de terminaison réseau du même type (NON_GCP_PRIVATE_IP_PORT).

  • Vous pouvez utiliser un seul service de backend pour référencer à la fois des backends basés sur Google Cloud (à l'aide de NEG zonaux avec des points de terminaison GCE_VM_IP_PORT) et des backends sur site ou d'autres backends cloud (à l'aide de NEG de connectivité hybride avec des points de terminaisonNON_GCP_PRIVATE_IP_PORT). Aucune autre combinaison de types de backends mixtes n'est autorisée. Traffic Director n'est pas compatible avec les types de backends mixtes dans un seul service de backend.

  • Le schéma d'équilibrage de charge du service de backend doit être l'un des suivants :

    • EXTERNAL_MANAGED pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application externes régionaux, les équilibreurs de charge réseau proxy externes globaux et les équilibreurs de charge réseau proxy externes régionaux
    • EXTERNAL pour les équilibreurs de charge d'application classiques et les équilibreurs de charge réseau proxy classiques
    • INTERNAL_MANAGED pour les équilibreurs de charge d'application internes, équilibreurs de charge réseau proxy internes interrégionaux, équilibreurs de charge réseau proxy internes interrégionaux et équilibreurs de charge réseau proxy internes régionaux.

    INTERNAL_SELF_MANAGED est compatible avec les déploiements multi-environnements de Traffic Director incluant des NEG de connectivité hybride.

  • Le protocole du service de backend doit être l'un des protocoles suivants : HTTP, HTTPS ou HTTP2 pour les équilibreurs de charge d'application, et TCP ou SSL pour les équilibreurs de charge réseau proxy externes et les équilibreurs de charge réseau proxy internes régionaux. Pour obtenir la liste des protocoles de service de backend compatibles avec chaque équilibreur de charge, consultez la section Protocoles de communication de l'équilibreur de charge vers le backend.

  • Le mode d'équilibrage du backend de NEG hybride doit être RATE pour les équilibreurs de charge d'application externes et internes, et CONNECTION pour l'équilibreur de charge réseau proxy interne régional et les équilibreurs de charge réseau proxy externes. Pour en savoir plus sur les modes d'équilibrage, consultez la Présentation des services de backend.

  • Pour ajouter d'autres points de terminaison du réseau, mettez à jour les backends associés à votre service de backend.

  • Si vous utilisez les vérifications d'état Envoy distribuées avec des NEG de connectivité hybride zonaux (par exemple, NON_GCP_PRIVATE_IP_PORT), ne configurez pas le même point de terminaison du réseau dans plusieurs NEG associés à un service de backend. Cela entraînerait un comportement indéfini.

Vérifications d'état centralisées

Des vérifications d'état centralisées sont nécessaires pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge réseau proxy externes globaux. D'autres équilibreurs de charge basés sur Envoy utilisent des vérifications d'état Envoy distribuées, comme décrit dans la section suivante.

Chaque service de backend doit être associé à une vérification d'état qui vérifie l'état des backends. Pour que les tests de vérification d'état fonctionnent correctement, vous devez créer des règles de pare-feu autorisant le trafic provenant des plages d'adresses IP de vérification de Google (130.211.0.0/22 et 35.191.0.0/16) pour atteindre vos points de terminaison.

Pour les points de terminaison NON_GCP_PRIVATE_IP_PORT extérieurs à Google Cloud, créez des règles de pare-feu sur vos réseaux situés sur site ou sur d'autres cloud. Pour cela, contactez votre administrateur réseau. Le routeur Cloud Router utilisé pour la connectivité hybride doit également annoncer les plages utilisées par les vérifications d'état de Google. Les plages à annoncer sont 35.191.0.0/16 et 130.211.0.0/22.

Pour les autres types de backends hébergés dans Google Cloud, créez des règles de pare-feu sur Google Cloud, comme illustré dans cet exemple.

Documentation associée :

Vérifications d'état Envoy distribuées

La configuration de votre vérification d'état varie en fonction du type d'équilibreur de charge :

  • Équilibreur de charge d'application externe global, équilibreur de charge d'application classique, équilibreur de charge réseau proxy externe global et équilibreur de charge réseau proxy classique. Ces équilibreurs de charge ne sont pas compatibles avec les vérifications d'état Envoy distribuées. Ils utilisent le mécanisme de vérification d'état centralisé de Google, comme décrit dans la section Vérifications d'état centralisées.
  • Équilibreur de charge d'application externe régional, équilibreur de charge d'application interne (interrégional et régional), équilibreur de charge réseau proxy externe régional, équilibreur de charge réseau proxy interne interrégional et équilibreur de charge réseau proxy interne régional Ces équilibreurs de charge utilisent des vérifications d'état Envoy distribuées qui proviennent du logiciel du proxy Envoy lui-même. Chaque service de backend doit être associé à une vérification d'état qui vérifie l'état des backends. Les vérifications d'état proviennent des proxys Envoy du sous-réseau proxy réservé de la région. Pour que ces vérifications d'état fonctionnent correctement, vous devez créer des règles de pare-feu dans l'environnement externe qui autorisent le trafic provenant du sous-réseau proxy réservé à accéder à vos backends externes.

    Pour les points de terminaison NON_GCP_PRIVATE_IP_PORT extérieurs à Google Cloud, vous devez créer ces règles de pare-feu sur vos réseaux situés sur site ou sur d'autres cloud. Pour cela, contactez votre administrateur réseau. Le routeur Cloud Router que vous utilisez pour la connectivité hybride doit également annoncer la plage de sous-réseau proxy réservé de la région.

Les vérifications d'état Envoy distribuées sont créées en utilisant les mêmes processus de console Google Cloud, gcloud CLI et d'API que les vérifications d'état centralisées. Aucune autre configuration n'est requise.

Remarques :

  • Les vérifications d'état gRPC ne sont pas acceptées.
  • Les vérifications d'état avec le protocole PROXY v1 activé ne sont pas compatibles.
  • Si vous utilisez des NEG mixtes dans lesquels un seul service de backend possède une combinaison de NEG zonaux (les points de terminaison GCE_VM_IP_PORT dans Google Cloud) et les NEG hybrides (les points de terminaison NON_GCP_PRIVATE_IP_PORT en dehors de Google Cloud), vous devez configurer des règles de pare-feu pour autoriser le trafic provenant des plages d'adresses IP des vérifications d'état Google (130.211.0.0/22 et 35.191.0.0/16) vers les points de terminaison NEG zonaux sur Google Cloud. En effet, les NEG zonaux utilisent le système de vérification d'état centralisé de Google.
  • Étant donné que le plan de données Envoy gère les vérifications d'état, vous ne pouvez pas utiliser la console Google Cloud, l'API ou la gcloud CLI pour vérifier l'état de ces points de terminaison externes.
  • Chaque proxy Envoy attribué au sous-réseau proxy réservé de la région du réseau VPC lance des vérifications d'état indépendamment. Par conséquent, vous pouvez constater une augmentation du trafic réseau en raison de la vérification de l'état. L'augmentation dépend du nombre de proxys Envoy attribués à votre réseau VPC dans une région, de la quantité de trafic reçue par ces proxys et du nombre de points de terminaison dont chaque proxy Envoy a besoin pour effectuer la vérification de l'état. Dans le pire des cas, le trafic réseau augmente à un taux (O(n^2)) quadratique en raison de vérifications de l'état.
  • Les journaux des vérifications d'état Envoy distribuées n'incluent pas d'états détaillés. Pour en savoir plus sur les éléments consignés, consultez la section Journalisation des vérifications d'état. Pour résoudre les problèmes de connectivité des proxys Envoy vers vos points de terminaison NEG, vous devez également vérifier les journaux des équilibreurs de charge respectifs.

Documentation associée :

Limites

  • Le routage dynamique global doit être activé sur le routeur Cloud Router utilisé pour la connectivité hybride. Le routage dynamique régional et les routes statiques ne sont pas pris en charge.
  • Pour les équilibreurs de charge régionaux basés sur Envoy (équilibreurs de charge d'application externes régionaux, équilibreurs de charge réseau proxy externes régionaux, équilibreurs de charge réseau proxy internes régionaux et équilibreurs de charge d'application internes régionaux), la connectivité hybride doit être configurée dans la même région que l'équilibreur de charge. S'ils sont configurés dans différentes régions, les backends sembleront opérationnels mais les requêtes des clients ne leurs seront pas transférées.
  • Les considérations concernant les connexions chiffrées de l'équilibreur de charge vers les backends faites ici s'appliquent également aux points de terminaison de backend autres que Google Cloud, configurés dans le NEG de connectivité hybride.

    Veillez également à vérifier les paramètres de sécurité de votre configuration de connectivité hybride. Actuellement, les connexions Cloud VPN haute disponibilité sont chiffrées par défaut (IPsec). Les connexions Cloud Interconnect ne sont pas chiffrées par défaut. Pour en savoir plus, consultez le livre blanc sur le chiffrement en transit.

Journalisation

Les requêtes envoyées par proxy à un point de terminaison d'un NEG hybride sont consignées dans Cloud Logging de la même manière que celles concernant d'autres backends. Si vous activez Cloud CDN pour votre équilibreur de charge d'application externe global, les succès de cache (hits) sont également consignés.

Pour en savoir plus, consultez les pages suivantes :

Quotas

Vous pouvez configurer autant de NEG hybrides avec points de terminaison de réseau que votre quota de groupes de points de terminaison de réseau existant le permet. Pour plus d'informations, consultez les sections Backends et Points de terminaison par NEG.

Étapes suivantes