NCC Cross-Cloud Network avec des NVA et un basculement régional

Last reviewed 2026-08-24 UTC

Ce document fournit une architecture de référence que vous pouvez utiliser pour déployer une topologie de réseau en étoile hybride ou Cross-Cloud Network qui utilise des appliances réseau virtuelles (NVA) pour acheminer le trafic au sein de Google Cloud ou avec des réseaux en dehors deGoogle Cloud.

Ce document s'adresse aux administrateurs réseau qui créent la connectivité réseau et aux architectes cloud qui planifient le déploiement des charges de travail. Ce document part du principe que vous maîtrisez les concepts de base du routage, du protocole BGP, de la connectivité Internet et du logiciel NVA que vous souhaitez déployer.

La conception est compatible avec plusieurs connexions à distance vers des emplacements de fournisseurs de services cloud (CSP) ou sur site, ainsi qu'avec plusieurs réseaux de cloud privé virtuel (VPC) de charge de travail. Il se concentre sur la création d'un déploiement multirégional résilient et hautes performances qui offre une affinité régionale et un basculement multirégional grâce au routage dynamique. Le routage dynamique est optimisé par BGP pour la détection et la récupération entièrement automatisées des perturbations des NVA. La conception place les NVA dans tous les flux de Google Cloud vers les CSP sur site ou autres, et place les NVA entre les réseaux VPC de charge de travail.

Si vous incluez des NVA dans votre réseau, cette architecture convient aux exigences de conception suivantes :

  1. Prise en charge du basculement des NVA interrégionaux : détection automatique des échecs de routage des NVA dans une région et redirection du trafic vers les NVA d'une régionGoogle Cloud voisine si nécessaire.
  2. Maintenir l'affinité régionale : conservez le routage dans les régions Google Cloud pour réduire la latence et les coûts de transfert de données, sauf en cas de défaillance. Le trafic n'est acheminé vers les régions distantes ou les connexions hybrides qu'en cas de défaillance.

Cette conception ne prévoit pas de routage symétrique entre les NVA, sauf si vous le configurez à l'aide des options décrites plus loin dans la section Scalabilité. Si le routage symétrique est plus important pour votre conception que le basculement régional et l'affinité du trafic local, consultez Cross-Cloud Network avec appairage de réseaux VPC, NVA et affinité régionale.

Architecture

Le schéma suivant montre les composants utilisés dans cette architecture. Le diagramme ne montre que deux régions, mais la conception peut être étendue à d'autres régions.

Déploiement CCN montrant les réseaux VPC de routage et de transit connectés par des NVA.

Composants d'architecture

L'exemple d'architecture précédent contient les composants suivants :

Réseau externe (réseau sur site ou d'un autre fournisseur de services cloud)

Le réseau externe peut être sur site ou dans un autre CSP. Il héberge les clients des applications qui s'exécutent dans les réseaux VPC de charge de travail. Le réseau externe peut également héberger des applications, mais les NVA ne traitent que le trafic qui transite vers ou depuis un réseau VPC de charge de travail.

Dans le schéma, Cloud Interconnect connecte le réseau externe au réseau VPC de routage. Cette architecture est également compatible avec l'utilisation de Cloud VPN au lieu de Cloud Interconnect. Le réseau externe utilise des rattachements VLAN Cloud Interconnect ou des tunnels Cloud VPN pour se connecter au hub 1 du Network Connectivity Center (NCC) en tant que spokes hybrides.

Routage du réseau VPC

Le réseau VPC de routage se connecte aux réseaux externes à l'aide de Cloud Interconnect ou Cloud VPN. Il se connecte au réseau VPC de transit via des NVA multi-NIC.

Le trafic qui transite entre le réseau VPC de routage et le réseau VPC de transit doit passer par les NVA. Les routeurs Cloud du réseau VPC de routage échangent des routes avec les routeurs du réseau externe et avec les cartes réseau des NVA connectées au réseau VPC de routage.

Réseau VPC de transit

Le réseau VPC de transit se connecte au réseau VPC de routage via des NVA multi-NIC. Ce réseau transmet le trafic entre le réseau VPC de routage et les réseaux VPC de charge de travail.

Le réseau VPC de transit transmet également le trafic des réseaux VPC de charge de travail aux NVA, puis le renvoie aux réseaux VPC de charge de travail pour le trafic de charge de travail à charge de travail.

Les routeurs Cloud du réseau échangent des routes avec les cartes réseau des NVA connectées au réseau de transit.

NVA

Les NVA multi-NIC sont déployées par paires dans plusieurs régionsGoogle Cloud . Chaque NVA dispose d'une carte d'interface réseau connectée au réseau VPC de routage et d'une autre carte d'interface réseau connectée au réseau VPC de transit. Les NVA font transiter le trafic entre les deux réseaux et peuvent fournir d'autres fonctions, telles que l'inspection du trafic.

Dans l'architecture, le trafic entre les réseaux VPC de charge de travail doit transiter par les NVA. Dans cette architecture, les NVA disposent d'au moins deux cartes d'interface réseau : l'une est associée au réseau VPC de routage et l'autre au réseau VPC de transit. L'architecture peut éventuellement prendre en charge des cartes d'interface réseau supplémentaires pour la gestion ou la connexion à des réseaux supplémentaires.

Hub NCC 1

Ce hub NCC assure la connectivité entre les connexions hybrides de réseau externe et les cartes d'interface réseau des NVA connectées au réseau VPC de routage.

Le hub est configuré dans une topologie maillée qui inclut les types de spokes hybrides suivants : spokes de dispositif de routeur, spokes Cloud VPN et spokes de rattachement de VLAN Cloud Interconnect.

Les cartes d'interface réseau NVA associées au réseau VPC de routage sont ajoutées au hub en tant que spokes d'appliance de routeur. Jusqu'à huit NVA peuvent être ajoutées en tant que rayon unique.

Réseaux VPC de charge de travail

Les réseaux VPC de charge de travail hébergent des applications accessibles depuis des clients du réseau externe ou depuis des clients d'autres réseaux VPC de charge de travail. Les réseaux VPC de charge de travail peuvent également héberger des points de terminaison Private Service Connect accessibles à partir d'autres réseaux.

Les réseaux VPC de charge de travail sont configurés en tant que spokes VPC sur le hub NCC 2. Les réseaux VPC de charge de travail sont connectés aux cartes d'interface réseau NVA dans le réseau VPC de transit via le hub NCC 2. Le trafic quittant un réseau VPC de charge de travail est acheminé vers les NVA, quelle que soit la destination finale du trafic.

Hub NCC 2

Ce hub NCC assure la connectivité entre les réseaux VPC de charge de travail et les interfaces NVA de l'appliance de routeur dans le réseau VPC de transit.

Le hub est configuré dans une topologie en étoile avec les spokes associés comme suit :

  • Les interfaces NVA du réseau VPC de transit sont configurées en tant que spokes de dispositif de routeur dans un groupe hub and spoke.
  • Les réseaux VPC de charge de travail sont configurés en tant que spokes VPC dans un groupe de spokes périphériques.

Le trafic vers et depuis les réseaux VPC de charge de travail doit transiter par les NVA.

Flux de trafic

Les sections suivantes présentent les flux de trafic normaux lorsque toutes les NVA et les connexions aux réseaux externes sont fonctionnelles, ainsi que les flux de trafic de basculement lorsque des connexions ou des NVA d'une région ont échoué.

Flux de trafic normaux

Le schéma suivant illustre les flux de trafic lorsque les NVA et les connexions aux réseaux externes sont opérationnels :

Diagramme illustrant les flux de la région A basculant vers la région B.

Lorsque tout fonctionne correctement, le trafic régional reste dans sa région :

  1. Les métriques BGP maintiennent le trafic local (de la région A à la région A ou à l'emplacement A) dans la région, ce qui élimine la nécessité de taguer les ressources ou les routes.
  2. Cette architecture positionne les NVA pour traiter le trafic entre les réseaux VPC de charge de travail, et entre les réseaux VPC de charge de travail et le réseau externe.

La liste suivante décrit les flux de trafic présentés dans le schéma :

  • Réseau externe vers Réseau VPC de charge de travail
    • Le trafic suit les routes via les connexions Cloud Interconnect vers le réseau VPC de routage. Les routes sont annoncées par Cloud Router à la NVA via le hub Network Connectivity Center.
    • Dans le réseau VPC de routage, le trafic est acheminé vers l'interface réseau de l'ANV active à l'aide de routes dynamiques apprises à partir de l'ANV. Le trafic suit les routes via le NVA vers son autre carte d'interface réseau, qui transmet le trafic au réseau VPC de transit. Le trafic suit des routes via les appairages NCC vers le réseau VPC de la charge de travail de destination.
  • Réseau VPC de charge de travail vers Réseau externe
    • Le trafic suit les routes apprises à partir du hub 2 NCC via l'appairage NCC vers le dispositif virtuel de réseau. Il accède au NVA actif via la carte réseau.
    • Le trafic suit les routes via le NVA vers son autre carte d'interface réseau, qui transmet le trafic au réseau VPC de routage. Le trafic suit les routes programmées dans le réseau VPC de routage vers les rattachements de VLAN et vers le réseau distant.
  • Réseau VPC de charge de travail vers Réseau VPC de charge de travail
    • Le trafic suit les routes apprises à partir du hub 2 NCC via l'appairage NCC vers le dispositif virtuel de réseau. Il entre dans l'appliance virtuelle réseau via la carte réseau du VPC de transit.
    • S'il existe plusieurs NVA actifs, les métriques BGP contrôlent le prochain saut. Le trafic suit les routes apprises du hub NCC 2 et repasse par la même carte d'interface réseau et par l'appairage NCC vers l'autre réseau VPC de charge de travail.

Flux de trafic de basculement

Le diagramme suivant illustre les flux de trafic lorsque toutes les NVA d'une région ont échoué :

Diagramme illustrant les flux de la région A basculant vers la région B.

En cas de défaillance totale de toutes les NVA d'une région, le système redirige automatiquement le trafic vers les NVA opérationnelles de la région distante la plus proche. Cette architecture est également résiliente aux échecs de connexion hybride dans une région.

Produits utilisés

Cette architecture de référence utilise les produits Google Cloud suivants :

  • Cloud privé virtuel (VPC) : système virtuel qui fournit des fonctionnalités de mise en réseau mondiales et évolutives pour vos charges de travail Google Cloud . Le VPC inclut l'appairage de réseaux VPC, Private Service Connect, l'accès aux services privés et le VPC partagé.
  • Network Connectivity Center : framework d'orchestration qui simplifie la connectivité réseau entre les ressources spoke connectées à une ressource de gestion centrale appelée hub.
  • Cloud Interconnect : service qui étend votre réseau externe au réseau Google via une connexion à haute disponibilité et à faible latence.
  • Cloud VPN : service qui étend de manière sécurisée votre réseau de pairs au réseau de Google via un tunnel VPN IPsec.
  • Cloud Router : offre distribuée et entièrement gérée qui fournit des fonctionnalités de speaker et de répondeur BGP (Border Gateway Protocol). Cloud Router fonctionne avec Cloud Interconnect, Cloud VPN et les appliances de routeur pour créer des routes dynamiques dans les réseaux VPC en fonction des routes apprises personnalisées et reçues par BGP.
  • Compute Engine : service de calcul sécurisé et personnalisable qui vous permet de créer et d'exécuter des machines virtuelles au sein de l'infrastructure de Google.

Alternatives de conception

Selon vos besoins, vous pouvez choisir parmi les alternatives de conception suivantes :

  • Cette architecture ne fournit pas d'accès centralisé pour des applications spécifiques. Si vous souhaitez ajouter un accès centralisé, vous pouvez configurer un réseau VPC d'accès aux services, comme décrit dans Cross-Cloud Network pour les applications distribuées.
  • Cette conception suppose que les réseaux VPC sont répartis entre plusieurs projets Google Cloud . Toutefois, en fonction de votre stratégie d'allocation de projets, vous pouvez provisionner vos réseaux VPC dans un seul projet.

Considérations de conception

Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations de conception à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie qui répond à vos exigences spécifiques en termes de sécurité, de fiabilité, d'évolutivité et de performances.

Sécurité et conformité

Voici quelques considérations de conception et recommandations pour concevoir une topologie dans Google Cloud qui répond aux exigences de sécurité et de conformité de votre charge de travail :

Fiabilité

Voici quelques considérations et recommandations de conception pour concevoir une topologie dans Google Cloud qui répond aux exigences de fiabilité de votre charge de travail :

Évolutivité

Cette section décrit les considérations de conception et les recommandations pour concevoir une topologie dans Google Cloud qui répond aux exigences d'évolutivité de votre charge de travail.

Si votre conception ne dépend pas du routage symétrique, vous pouvez effectuer une mise à l'échelle en ajoutant des nœuds NVA.

Si votre conception nécessite un routage symétrique, vous pouvez envisager les options suivantes en fonction des fonctionnalités proposées par votre logiciel NVA :

  • Utilisez les attributs BGP pour maintenir un seul nœud NVA actif par région, mais dimensionnez cette VM pour gérer votre trafic.
  • Utilisez les fonctionnalités du fournisseur pour configurer le NAT de source sur les NVA.
  • Si votre fournisseur le permet, vous pouvez configurer la synchronisation des sessions sur les nœuds.
  • Exploitez les options d'ingénierie du trafic BGP (comme les règles de routage BGP) pour configurer une configuration actif-passif par flux. Par exemple, vous pouvez configurer certains réseaux pour qu'ils préfèrent NVA-A à NVA-B et inverser les préférences pour d'autres réseaux.

Optimisation des performances

Voici des considérations de conception et des recommandations pour concevoir une topologie dans Google Cloud qui répond aux exigences de performances de votre charge de travail :

  • Vous pouvez améliorer les performances du réseau en augmentant l'unité de transmission maximale (MTU) de vos réseaux et connexions. Pour en savoir plus, consultez Unité de transmission maximale.
  • Pour améliorer le temps de convergence, envisagez d'utiliser BGP BFD, le cas échéant, pour accélérer la détection et la correction des interruptions des événements BGP. BFD n'est pas compatible avec les sessions BGP configurées pour les tunnels Cloud VPN ni pour les NVA configurées en tant que spokes d'appliance de routeur.

Déploiement

Pour déployer cette architecture de référence, procédez comme suit :

  1. Identifiez les Google Cloud régions.
  2. Concevez et créez la structure du projet.
  3. Planifiez l'attribution des adresses IP.
  4. Créez le réseau VPC de routage.
  5. Créez des connexions au réseau externe.
  6. Créez les réseaux VPC de transit et de charge de travail.
  7. Créez les NVA.
  8. Créez le hub NCC 1.
  9. Créez un hub NCC 2.
  10. Ajoutez un accès privé aux API Google.
  11. Configurez l'entrée et la sortie Internet centralisées.
  12. Tester la connectivité aux charges de travail

Identifier Google Cloud des régions

En général, placez la connectivité, les sous-réseaux VPC et les charges de travailGoogle Cloud à proximité de vos réseaux sur site ou d'autres clients cloud. Pour en savoir plus sur le placement des charges de travail, consultez Sélecteur de régionGoogle Cloud et Bonnes pratiques pour la sélection des régions Compute Engine.

Nous vous recommandons de sélectionner au moins deux régions pour héberger les NVA afin de bénéficier de la prise en charge du basculement interrégional de cette architecture.

Concevoir et créer la structure du projet

Créez ou identifiez les projets dans lesquels vous allez créer vos réseaux VPC. Vous aurez besoin des projets suivants :

Planifier l'allocation d'adresses IP

Créez un plan d'attribution d'adresses IP pour les réseaux nécessaires. Pour faciliter l'agrégation des adresses de réseau VPC de charge de travail, choisissez leurs plages d'adresses à partir d'une seule plage plus grande. Nous vous recommandons d'allouer une grande plage de supernet (comme /12) à utiliser pour les attributions de réseau VPC de charge de travail.

Votre plan doit inclure les plages d'adresses IP pour les réseaux suivants :

  • Réseaux externes
  • Routage du réseau VPC
  • Réseau VPC de transit
  • Plage agrégée pour tous les réseaux VPC de charge de travail

Créer le réseau VPC de routage

Le réseau VPC de routage héberge les composants suivants :

  • Connexions hybrides à des réseaux externes.
  • Une carte d'interface réseau de chaque NVA. Dans les schémas, cette carte d'interface réseau est identifiée par le libellé "nic 0".
  • Un routeur Cloud Router par région.

Lorsque vous créez le réseau VPC de routage, procédez comme suit :

  1. Dans le projet où vous souhaitez créer votre réseau VPC de routage, créez le réseau de routage en tant que réseau VPC en mode personnalisé mondial avec le routage dynamique mondial activé. Le routage dynamique global est nécessaire pour le routage multirégional.
  2. Dans le réseau de routage, créez un seul sous-réseau par région. Ces sous-réseaux hébergent les interfaces NVA utilisées pour le routage privé vers des réseaux externes et, éventuellement, la communication avec Internet.
  3. Créez un routeur Cloud Router dans chaque région. Le Cloud Router gère le protocole BGP entre le réseau VPC et le réseau externe pour cette région. Nous vous recommandons de créer des NVA et des réseaux VPC de charge de travail dans la même région que la connexion hybride pour activer le routage local entre les connexions hybrides et les charges de travail via les NVA.
    • Si vous créez des NVA et des réseaux de charge de travail dans la même région, vous n'avez besoin que d'un seul routeur Cloud Router déployé dans cette région.
    • Si vous créez des NVA dans une région et des réseaux VPC de charge de travail dans une autre région, vous avez besoin d'Cloud Router dans chacune de ces régions.

Créer des connexions au réseau externe

Cette conception recommande d'utiliser Cloud Interconnect pour connecter votre réseau externe à votre réseau VPC de routage Google Cloud . Toutefois, vous pouvez choisir un autre produit de connectivité. Pour en savoir plus, consultez Choisir un produit de connectivité réseau.

Configurez la connectivité entre les réseaux externes (sur site et autres clouds) et votre réseau VPC de routage. Nous vous recommandons de viser un contrat de niveau de service de 99, 99% pour les charges de travail de production et de suivre les bonnes pratiques de Google lorsque vous établissez la connexion.

Lorsque vous configurez des connexions hybrides au réseau externe, si des réseaux clients supplémentaires doivent être routés depuis et vers des emplacements distants, annoncez leurs sous-réseaux en tant qu'annonces de routage personnalisées.

Créer les réseaux VPC de transit et de charge de travail

Le rôle du réseau VPC de transit est de connecter les NVA aux réseaux VPC de charge de travail.

  1. Dans le projet où vous souhaitez créer votre réseau de transit, créez-le en tant que réseau VPC en mode personnalisé mondial avec le routage dynamique mondial activé. Le routage dynamique global est nécessaire pour le routage multirégional.
  2. Créez un sous-réseau par région pour héberger les interfaces NVA utilisées pour le routage privé vers les réseaux VPC de charge de travail.
  3. Configurez un routeur Cloud Router dans chaque région où vous prévoyez de provisionner des NVA.
  4. Créez des réseaux VPC de charge de travail si nécessaire.

Créer les NVA

Pour savoir comment provisionner une NVA listée sur Google Cloud Marketplace, consultez la documentation du fournisseur de NVA. Lorsque vous configurez vos NVA pour cette conception, suivez ces consignes :

  1. Déployez les NVA par paires dans au moins deux régions pour assurer une résilience multirégionale. Étant donné que les NVA sont ajoutées en tant que spokes d'appareil de routeur Network Connectivity Center, vous n'avez pas besoin de les configurer dans des groupes d'instances.
  2. Les VM NVA ont besoin d'au moins deux cartes d'interface réseau, mais certains fournisseurs exigent une carte d'interface réseau dédiée à la gestion. Ajoutez les cartes d'interface réseau nécessaires pour répondre aux exigences du fournisseur.
  3. Pour assurer un routage symétrique via un seul NVA actif, les NVA doivent définir des métriques BGP, comme les MED, afin de fournir des préférences de route entre les NVA de la région. Nous vous recommandons d'utiliser des valeurs MED faibles, par exemple 10 pour le primaire et 20 pour le secondaire. Étant donné que Google Cloud ajoute une pondération régionale pour les réseaux distants, vous n'avez pas besoin de définir de valeurs MED pour la préférence multirégionale. Pour savoir comment assurer la symétrie du routage, consultez la section "Évolutivité" plus haut dans ce document.
  4. Pour annoncer les plages de sous-réseaux VPC de charge de travail en tant que route de super-réseau agrégée ou récapitulée, configurez BGP sur la carte d'interface réseau de l'appliance virtuelle réseau qui est rattachée au réseau de transit. Cette route est nécessaire pour activer la communication VPC de charge de travail à charge de travail via les NVA. Configurez les NVA pour qu'elles annoncent tous les sous-réseaux visibles par Cloud Router.

Créer le hub NCC 1

Dans cette conception, le rôle du premier hub NCC est d'activer la publicité dynamique des routes entre les connexions hybrides et les NVA. Lorsque vous configurez votre hub NCC, suivez ces consignes :

  1. Configurez le hub NCC dans une topologie maillée afin qu'il permette à tous les spokes de communiquer directement entre eux.
  2. Ajoutez des connexions hybrides (rattachements de VLAN ou VPN) au hub en tant que spokes hybrides.
    • Activez le transfert de données de site à site. Pour connaître les emplacements acceptés, consultez Emplacements compatibles avec le transfert de données.
    • Activez l'option Inclure l'exportation des plages de sous-réseaux IPv4 du spoke vers le hub.
    • Activez l'option Inclure toutes les plages d'adresses IPv4 du hub vers le spoke.
  3. Identifiez les cartes d'interface réseau NVA associées au réseau VPC de routage, puis ajoutez-les au hub NCC 1 en tant que spokes d'appliance de routeur.
    • Activez le transfert de données de site à site.
    • Activez l'option Inclure l'exportation des plages de sous-réseaux IPv4 du spoke vers le hub.
    • Activez l'option Inclure toutes les plages d'adresses IPv4 du hub vers le spoke.
  4. Pour assurer la résilience, lorsque vous configurez des appliances de routeur, créez des sessions BGP pour les deux interfaces de Cloud Router.

Créer un hub NCC 2

Le deuxième hub NCC permet l'annonce de routage dynamique entre les NVA et les réseaux VPC de charge de travail. Pour ce faire, ajoutez les cartes d'interface réseau NVA en tant que spokes d'appliance de routeur et les réseaux VPC de charge de travail en tant que spokes VPC.

  1. Configurez le hub NCC dans une topologie en étoile afin que le trafic entre les spokes du VPC de charge de travail doive transiter par le réseau VPC de transit (le hub).
  2. Ajoutez des NVA en tant que spokes d'appliance de routeur au groupe central du hub.
    1. Activez les transferts de données de site à site.
    2. Activez l'option Inclure l'exportation de toutes les plages IPv4 du spoke vers le hub.
    3. Activez l'option Inclure l'importation des plages d'adresses IPv4 du hub vers le spoke.
  3. Ajoutez des spokes VPC de charge de travail au groupe Edge.
  4. Pour assurer la résilience, lorsque vous configurez des rayons d'appliance de routeur, créez des sessions BGP pour les deux interfaces de Cloud Router.

Ajouter un accès privé aux API et services Google

Si vos applications n'ont pas besoin d'accéder aux Google APIs, vous pouvez ignorer cette section lors de votre déploiement initial et passer à Configurer l'entrée et la sortie Internet centralisées.

Il existe deux options pour activer l'accès privé aux API et services Google en fonction des exigences de journalisation et de visibilité. Pour en savoir plus sur ces services, consultez Types de services Google Cloud.

Routage direct vers les services Private Service Connect (et non via les NVA)

  1. Créez un point de terminaison Private Service Connect pour les API Google dans chaque réseau VPC.
  2. Créez un point de terminaison Private Service Connect pour les services publiés par Google dans chaque réseau VPC de charge de travail nécessitant un accès au service.
  3. Pour activer l'accès depuis le réseau externe, provisionnez des points de terminaison Private Service Connect dans le réseau VPC de routage. Pour savoir comment activer l'accès privé aux API Google depuis un environnement sur site, consultez la documentation Private Service Connect.

Routage indirect via le NVA

  1. Dans le réseau VPC de routage, créez un point de terminaison Private Service Connect pour les API Google.
  2. Dans le réseau VPC de transit, créez un point de terminaison Private Service Connect pour les API Google.

  3. Configurez le DNS comme suit :

    1. Réseaux VPC de charge de travail : configurez le DNS pour résoudre les appels d'API en adresse IP du point de terminaison Private Service Connect dans le VPC de routage.
    2. Réseaux externes : configurez le DNS pour résoudre les appels d'API à l'adresse IP du point de terminaison Private Service Connect que vous avez créé dans le réseau VPC de transit.

    Cette approche permet aux NVA de transférer le trafic des API Google.

  4. Créez un point de terminaison Private Service Connect pour les services publiés par Google uniquement dans le VPC de charge de travail associé au service.

  5. Pour activer l'accès inter-réseaux VPC aux points de terminaison Private Service Connect pour les services publiés par Google, activez la propagation Private Service Connect sur le NCC hub 2.

Configurer l'entrée et la sortie Internet centralisées

Si vos applications n'ont pas besoin d'accéder à Internet via vos NVA, vous pouvez ignorer cette section lors de votre déploiement initial et passer à Tester la connectivité aux charges de travail.

Entrée Internet centralisée

Pour l'entrée depuis Internet, les NVA doivent effectuer une DNAT pour le trafic lorsqu'il est acheminé vers la ressource cible dans le VPC spoke. Pour savoir comment configurer l'entrée, consultez Configurer les équilibreurs de charge Google avec des appliances virtuelles réseau (NVA) dans Google Cloud. Dans cette configuration, vous attribuez l'adresse cible d'origine à l'équilibreur de charge Google placé devant les NVA. Le type d'équilibreur de charge que vous sélectionnez affecte la nature globale du service d'entrée.

Sortie Internet centralisée

Si vous souhaitez centraliser la sortie vers Internet, les NVA doivent effectuer une SNAT pour le trafic lorsqu'il est acheminé vers la ressource cible sur Internet. Pour acheminer le trafic depuis la source Google Cloud , les NVA doivent annoncer une route par défaut aux VPC spokes. Ce routage ne nécessite pas d'équilibreur de charge.

Tester la connectivité aux charges de travail

Pour vous assurer d'avoir de la visibilité sur les flux de trafic, utilisez traceroute. Pour tester la connectivité des différents flux, vous pouvez créer des VM de test dans différents VPC.

Étapes suivantes

Contributeurs

Contributeurs

Auteur : Haider Witwit | Ingénieur client

Autres contributeurs :