Segmentation et connectivité réseau pour les applications distribuées dans Cross-Cloud Network

Last reviewed 2025-01-30 UTC

Ce document fait partie d'une série de guides de conception pour Cross-Cloud Network.

Cette série comprend les parties suivantes :

Cette partie explore la structure de segmentation et la connectivité du réseau, qui constituent la base de la conception. Ce document décrit les phases au cours desquelles vous effectuez les choix suivants :

  • La segmentation globale du réseau et la structure du projet.
  • Emplacement de votre charge de travail.
  • La manière dont vos projets sont connectés à des réseaux externes sur site et à d'autres fournisseurs cloud, y compris la conception de la connectivité, du routage et du chiffrement.
  • La manière dont vos réseaux VPC sont connectés en interne les uns aux autres.
  • Comment vos sous-réseaux VPC Google Cloud sont connectés entre eux et aux autres réseaux, y compris la configuration de la joignabilité des services et du DNS.

Segmentation du réseau et structure du projet

Au cours de la phase de planification, vous devez choisir entre l'une des deux structures de projet :

  • Un projet hôte d'infrastructure consolidée, dans lequel vous utilisez un seul projet hôte d'infrastructure pour gérer l'ensemble des ressources réseau de toutes les applications
  • Projets hôtes segmentés, dans lesquels vous utilisez un projet hôte d'infrastructure en combinaison avec un projet hôte différent pour chaque application

Au cours de la phase de planification, nous vous recommandons également de définir les domaines administratifs pour vos environnements de charge de travail. Définissez les autorisations pour vos administrateurs et développeurs d'infrastructure, selon le principe du moindre privilège, et étendez les ressources d'application à différents projets d'application. Étant donné que les administrateurs d'infrastructure doivent configurer la connectivité pour partager des ressources, les ressources d'infrastructure peuvent être gérées dans un projet d'infrastructure. Par exemple, pour configurer la connectivité aux ressources d'infrastructure partagées, les administrateurs d'infrastructure peuvent utiliser un projet d'infrastructure pour gérer ces ressources partagées. Dans le même temps, l'équipe de développement peut gérer ses charges de travail dans un projet, tandis que l'équipe de production peut gérer les siennes dans un autre projet. Les développeurs utiliseraient ensuite les ressources d'infrastructure du projet d'infrastructure pour créer et gérer les ressources, les services, l'équilibrage de charge et les règles de routage DNS pour leurs charges de travail.

De plus, vous devez déterminer le nombre de réseaux VPC à implémenter initialement et comment ils seront organisés dans votre hiérarchie de ressources. Pour savoir comment choisir une hiérarchie de ressources, consultez Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud . Pour en savoir plus sur la manière de choisir le nombre de réseaux VPC, consultez Choisir de créer ou non plusieurs réseaux VPC.

Pour Cross-Cloud Network, nous vous recommandons d'utiliser les VPC suivants :

  • Un ou plusieurs VPC d'application pour héberger les ressources des différentes applications.
  • Un ou plusieurs VPC de transit, où toute la connectivité externe est gérée.
  • Un ou plusieurs VPC d'accès aux services, qui peuvent être utilisés pour consolider le déploiement de l'accès privé aux services publiés.

Le schéma suivant présente une représentation visuelle de la structure VPC recommandée que nous venons de décrire. Vous pouvez utiliser la structure VPC telle qu'illustrée dans le schéma, avec une structure de projet consolidée ou segmentée, comme décrit dans les sections suivantes. Le schéma ci-dessous ne montre pas la connectivité entre les réseaux VPC.

Structure VPC recommandée

Projet hôte d'infrastructure consolidée

Vous pouvez utiliser un projet hôte d'infrastructure consolidée pour gérer toutes les ressources réseau telles que les réseaux et sous-réseaux VPC, les hubs Network Connectivity Center, l'appairage de réseaux VPC et les équilibreurs de charge.

Plusieurs VPC partagés d'application avec leurs projets de service d'application peuvent être créés dans le projet hôte de l'infrastructure pour correspondre à la structure organisationnelle. Utilisez plusieurs projets de service d'application pour déléguer l'administration des ressources. La mise en réseau de tous les VPC d'applications est entièrement facturée au projet hôte de l'infrastructure consolidée.

Pour cette structure de projet, de nombreux projets de service d'application peuvent partager un nombre plus restreint de VPC d'application.

Le schéma suivant fournit une représentation visuelle du projet hôte d'infrastructure consolidée et des multiples projets de service d'application que vous venez de décrire. Le diagramme ne montre pas la connectivité entre tous les projets.

Projet hôte d'infrastructure consolidée et projets de service d'application multiples

Projets hôtes segmentés

Dans ce modèle, chaque groupe d'applications possède son propre projet hôte d'application et ses propres réseaux VPC. Plusieurs projets de service d'application peuvent être associés au projet hôte. La facturation des services réseau est répartie entre le projet hôte d'infrastructure et les projets hôtes d'application. Les frais d'infrastructure sont facturés au projet hôte d'infrastructure, et les frais de réseau, tels que ceux liés au transfert de données pour les applications, sont facturés à chaque projet hôte d'application.

Le schéma suivant fournit une représentation visuelle des multiples projets hôtes et projets de service d'application que vous venez de décrire. Le diagramme ne montre pas la connectivité entre tous les projets.

Projets hôtes multiples et projets de service d'application multiples

Emplacement de la charge de travail

De nombreux choix de connectivité dépendent des emplacements régionaux de vos charges de travail. Pour obtenir des conseils sur le placement des charges de travail, consultez Bonnes pratiques pour la sélection des régions Compute Engine. Vous devez décider où vos charges de travail seront exécutées avant de choisir les emplacements de connectivité.

Connectivité externe et hybride

Cette section décrit la configuration requise et les recommandations pour les chemins de connectivité suivants :

  • Connexions privées à d'autres fournisseurs de services cloud
  • Connexions privées aux centres de données sur site
  • Connectivité Internet pour les charges de travail, en particulier la connectivité sortante

Cross-Cloud Network implique l'interconnexion de plusieurs réseaux cloud ou réseaux sur site. Les réseaux externes peuvent appartenir à différentes organisations et être gérés par celles-ci. Ces réseaux sont physiquement connectés les uns aux autres au niveau d'une ou de plusieurs interfaces réseau à réseau (NNI). La combinaison des NNI doit être conçue, provisionnée et configurée pour garantir les performances, la résilience, la confidentialité et la sécurité.

Pour la modularité, la réutilisabilité et la possibilité d'insérer des NVA de sécurité, placez les connexions externes et le routage dans un VPC de transit, qui sert ensuite de service de connectivité partagé pour les autres VPC. Les règles de routage pour la résilience, le basculement et la préférence de chemin d'accès entre les domaines peuvent être configurées une seule fois dans le VPC de transit et utilisées par de nombreux autres réseaux VPC.

La conception des NNI et de la connectivité externe sera utilisée ultérieurement pour la connectivité interne et la mise en réseau VPC.

Le schéma suivant montre un VPC de transit servant de service de connectivité partagé pour les autres VPC, qui sont connectés à l'aide de l'appairage de réseaux VPC, de Network Connectivity Center ou d'un VPN haute disponibilité. Pour plus de simplicité, le schéma montre un seul VPC de transit, mais vous pouvez utiliser plusieurs VPC de transit pour la connectivité dans différentes régions.

VPC de transit utilisé comme service de connectivité partagé pour d'autres VPC

Connexions privées à d'autres fournisseurs de services cloud

Si vous avez des services exécutés dans d'autres réseaux de fournisseurs de services cloud (CSP) auxquels vous souhaitez vous connecter à votre réseau Google Cloud , vous pouvez vous y connecter via Internet ou via des connexions privées. Nous recommandons des connexions privées.

Lorsque vous choisissez des options, tenez compte du débit, de la confidentialité, du coût et de la viabilité opérationnelle.

Pour maximiser le débit tout en améliorant la confidentialité, utilisez une connexion directe haut débit entre les réseaux cloud. Les connexions directes éliminent la nécessité de disposer d'équipements de mise en réseau physiques intermédiaires. Nous vous recommandons d'utiliser Cross-Cloud Interconnect, qui fournit ces connexions directes, ainsi que le chiffrement MACsec et un débit maximal de 100 Gbit/s par liaison.

Si vous ne pouvez pas utiliser interconnexion cross-cloud, vous pouvez utiliser interconnexion dédiée ou interconnexion partenaire via une installation hébergée en colocation.

Sélectionnez les emplacements où vous vous connectez aux autres fournisseurs de services cloud en fonction de leur proximité avec les régions cibles. Pour la sélection de l'emplacement, tenez compte des points suivants :

  • Consultez la liste des emplacements :
    • Pour interconnexion cross-cloud, consultez la liste des emplacements disponibles pour Google Cloud et les CSP (la disponibilité varie selon le fournisseur de services cloud).
    • Pour une interconnexion dédiée ou partenaire, choisissez un emplacement à faible latence pour l'installation hébergée en colocation.
  • Évaluez la latence entre le point de présence (POP) périphérique donné et la région concernée dans chaque CSP.

Pour maximiser la fiabilité de vos connexions cross-cloud, nous vous recommandons une configuration qui prend en charge un contrat de niveau de service garantissant une disponibilité de 99,99 % pour les charges de travail de production. Pour obtenir des détails, consultez les sections Haute disponibilité Cross-Cloud Interconnect, Établir une disponibilité de 99,99% pour Dedicated Interconnect, et Établir une disponibilité de 99,99 % pour Partner Interconnect.

Si vous n'avez pas besoin d'une bande passante élevée entre différents CSP, vous pouvez utiliser des tunnels VPN. Cette approche peut vous aider à vous lancer. Vous pourrez passer à interconnexion cross-cloud lorsque vos applications distribuées utiliseront plus de bande passante. Les tunnels VPN peuvent également atteindre un contrat de niveau de service de 99,99 %. Pour en savoir plus, consultez Topologies des VPN haute disponibilité.

Connexions privées aux centres de données sur site

Pour la connectivité aux centres de données privés, vous pouvez utiliser l'une des options de connectivité hybride suivantes :

  • Dedicated Interconnect
  • Partner Interconnect
  • VPN haute disponibilité

Les considérations de routage pour ces connexions sont semblables à celles des connexions privées à d'autres fournisseurs de cloud.

Le schéma suivant montre les connexions aux réseaux sur site et explique comment les routeurs sur site peuvent se connecter à Cloud Router via une règle d'appairage :

Connexions aux réseaux sur site

Routage interdomaines avec des réseaux externes

Pour augmenter la résilience et le débit entre les réseaux, utilisez plusieurs chemins d'accès pour les connecter.

Lorsque le trafic est transféré entre des domaines réseau, il doit être inspecté par des dispositifs de sécurité avec état. Par conséquent, la symétrie du flux à la limite entre les domaines est requise.

Pour les réseaux qui transfèrent des données dans plusieurs régions, le coût et le niveau de qualité de service de chaque réseau peuvent varier considérablement. Vous pouvez décider d'utiliser certains réseaux plutôt que d'autres en fonction de ces différences.

Configurez votre règle de routage interdomaines pour répondre à vos exigences en termes de transit interrégional, de symétrie du trafic, de débit et de résilience.

La configuration des règles de routage inter-domaines dépend des fonctions disponibles à la périphérie de chaque domaine. La configuration dépend également de la structure des domaines voisins, du point de vue du système autonome et de l'adressage IP (sous-réseau) entre différentes régions. Pour améliorer l'évolutivité sans dépasser les limites de préfixes sur les appareils périphériques, nous vous recommandons de concevoir un plan d'adressage IP qui génère moins de préfixes agrégés pour chaque combinaison de région et de domaine.

Lorsque vous concevez un routage interrégional, tenez compte des points suivants :

  • Les réseaux VPCGoogle Cloud et Cloud Router sont compatibles avec le routage mondial multirégion. D'autres fournisseurs cloud peuvent disposer de VPC et de champs d'application BGP (Border Gateway Protocol) régionaux. Pour en savoir plus, consultez la documentation de votre autre CSP.
  • Cloud Router annonce automatiquement les routes avec des préférences de chemin prédéterminées en fonction de la proximité régionale. Ce comportement de routage dépend du mode de routage dynamique configuré pour le VPC. Vous devrez peut-être remplacer ces préférences, pour le comportement de routage souhaité.
  • Différents CSP sont compatibles avec différentes fonctions BFD (BGP and Bidirectional Forwarding Detection). De plus, Cloud Router de Google dispose de fonctionnalités de stratégie de routage spécifiques, comme décrit dans Établir des sessions BGP.
  • Différents CSP peuvent utiliser différents attributs de départage BGP pour définir la préférence des routes. Pour en savoir plus, consultez la documentation de votre fournisseur de services cloud.

Routage interdomaines dans une seule région

Nous vous suggérons de commencer par le routage inter-domaines à une seule région, sur lequel vous vous appuierez pour créer des connexions multirégionales avec le routage inter-domaines.

Les conceptions qui utilisent Cloud Interconnect doivent comporter au moins deux emplacements de connexion situés dans la même région, mais dans des domaines de disponibilité de périphérie différents.

Décidez si vous souhaitez configurer ces connexions en double dans une conception active/active ou active/passive :

  • Les valeurs actives/actives utilisent le routage ECMP (Equal Cost Multi-Path) pour regrouper la bande passante des deux chemins et les utiliser simultanément pour le trafic inter-domaine. Cloud Interconnect permet également d'utiliser des liaisons agrégées LACP pour atteindre jusqu'à 200 Gbit/s de bande passante globale par chemin.
  • Le mode actif/passif force une liaison à être en veille, et à ne prendre le relais que si la liaison active est interrompue.

Nous recommandons une conception en mode actif/actif pour les liaisons intrarégionales. Toutefois, certaines topologies réseau sur site combinées à l'utilisation de fonctions de sécurité avec état peuvent nécessiter une conception active/passive.

Cloud Router est instancié sur plusieurs zones, ce qui offre une plus grande résilience que ne le ferait un élément unique. Le schéma suivant montre comment toutes les connexions résilientes convergent vers un seul routeur Cloud Router dans une région. Cette conception offre une garantie de disponibilité de 99,9% dans une seule zone métropolitaine si vous respectez les directives pour Établir une disponibilité de 99,9% pour Dedicated Interconnect.

Le schéma suivant montre deux routeurs sur site connectés de manière redondante au service Cloud Router géré dans une seule région :

Les connexions résilientes peuvent utiliser un seul routeur Cloud Router

Routage interdomaines multirégional

Pour fournir une connectivité de secours, les réseaux peuvent être appairés à plusieurs zones géographiques. En connectant les réseaux dans plusieurs régions, le contrat de niveau de service peut atteindre 99,99%.

Le schéma suivant illustre les architectures avec un SLA de 99,99 %. Il montre des routeurs sur site dans deux emplacements différents connectés de manière redondante aux services Cloud Router gérés dans deux régions différentes.

Connexions Cloud Interconnect dans plusieurs régions

Au-delà de la résilience, la conception du routage multirégional doit permettre de satisfaire la symétrie de flux. La conception doit également indiquer le réseau préféré pour les communications interrégionales, ce que vous pouvez faire avec le routage hot-potato et cold-potato. Associez le routage de type "cold-potato" dans un domaine avec le routage de type "hot-potato" dans le domaine pair. Pour le domaine de type "patate froide", nous vous recommandons d'utiliser le domaine réseauGoogle Cloud , qui fournit une fonctionnalité de routage VPC global.

La symétrie des flux n'est pas toujours obligatoire, mais l'asymétrie des flux peut entraîner des problèmes avec les fonctions de sécurité avec état.

Le schéma suivant montre comment utiliser le routage hot-potato et cold-potato pour spécifier votre réseau de transit interrégional préféré. Dans ce cas, le trafic provenant des préfixes X et Y reste sur le réseau d'origine jusqu'à ce qu'il atteigne la région la plus proche de la destination (routage de type "patate froide"). Le trafic provenant des préfixes A et B bascule vers l'autre réseau dans la région d'origine, puis transite par l'autre réseau jusqu'à la destination (routage de type "patate chaude").

Utiliser le routage de type "hot-potato" et "cold-potato" pour spécifier votre réseau de transit interrégional préféré

Chiffrement du trafic entre domaines

Sauf indication contraire, le trafic n'est pas chiffré sur les connexions Cloud Interconnect entre différents CSP ni entre Google Cloud et les centres de données sur site. Si votre organisation nécessite le chiffrement pour ce trafic, vous pouvez utiliser les fonctionnalités suivantes :

  • MACsec pour Cloud Interconnect : chiffre le trafic via les connexions Cloud Interconnect entre vos routeurs et les routeurs périphériques de Google. Pour en savoir plus, consultez la page Présentation de MACsec pour Cloud Interconnect.
  • VPN haute disponibilité sur Cloud Interconnect : utilise plusieurs tunnels VPN haute disponibilité pour fournir toute la bande passante des connexions Cloud Interconnect sous-jacentes. Les tunnels VPN haute disponibilité sont chiffrés par IPsec et déployés sur des connexions Cloud Interconnect qui peuvent également être chiffrées par MACsec. Dans cette configuration, les connexions Cloud Interconnect sont configurées pour n'autoriser que le trafic VPN haute disponibilité. Pour en savoir plus, consultez la présentation du VPN haute disponibilité sur Cloud Interconnect.

Connectivité Internet pour les charges de travail

Pour la connectivité Internet entrante et sortante, le trafic de réponse est supposé suivre de manière avec état le sens inverse de la requête d'origine.

En général, les fonctionnalités qui fournissent une connectivité Internet entrante sont distinctes des fonctionnalités Internet sortantes, à l'exception des adresses IP externes qui fournissent les deux directions simultanément.

Connectivité Internet entrante

La connectivité Internet entrante consiste principalement à fournir des points de terminaison publics pour les services hébergés dans le cloud. Cela inclut par exemple la connectivité Internet à des serveurs d'applications Web et des serveurs de jeux hébergés surGoogle Cloud.

Les produits Cloud Load Balancing de Google sont les principales fonctionnalités qui fournissent une connectivité Internet entrante. La conception d'un réseau VPC est indépendante de sa capacité à fournir une connectivité Internet entrante :

Connectivité Internet sortante

Les exemples de connectivité Internet sortante (où la requête initiale provient de la charge de travail vers une destination Internet) incluent les charges de travail accédant à des API tierces, le téléchargement de packages logiciels et de mises à jour, et l'envoi de notifications push aux points de terminaison webhook sur Internet.

Pour la connectivité sortante, vous pouvez utiliser les options intégrées de Google Cloud , comme décrit dans Créer une connectivité Internet pour les VM privées. Vous pouvez également utiliser les NVA NGFW centraux, comme décrit dans la section Sécurité du réseau.

Le principal moyen de fournir une connectivité Internet sortante est la destination de la passerelle Internet par défaut dans la table de routage du VPC, qui est souvent la route par défaut dans les VPC Google. Les adresses IP externes et Cloud NAT (service NAT géré deGoogle Cloud) nécessitent une route pointant vers la passerelle Internet par défaut du VPC. Par conséquent, les conceptions de routage VPC qui remplacent la route par défaut doivent fournir une connectivité sortante par d'autres moyens. Pour en savoir plus, consultez la présentation de Cloud Router.

Pour sécuriser la connectivité sortante, Google Cloud propose à la fois l'application du pare-feu Cloud de nouvelle génération et le proxy Web sécurisé pour fournir un filtrage plus approfondi des URL HTTP et HTTPS. Dans tous les cas, cependant, le trafic suit la route par défaut vers la passerelle Internet par défaut ou via une route par défaut personnalisée dans la table de routage VPC.

Utiliser vos propres adresses IP

Vous pouvez utiliser les adresses IPv4 appartenant à Google pour la connectivité Internet, ou vous pouvez utiliser la fonctionnalité Utiliser vos propres adresses IP (BYOIP) pour utiliser un espace IPv4 appartenant à votre organisation. La plupart des produits Google Cloudnécessitant une adresse IP routable sur Internet peuvent également utiliser des plages BYOIP.

Vous pouvez également contrôler la réputation de l'espace IP grâce à son utilisation exclusive. BYOIP facilite la portabilité de la connectivité et peut permettre de réduire les coûts liés aux adresses IP.

Connectivité interne et mise en réseau VPC

Une fois le service de connectivité externe et hybride configuré, les ressources du VPC de transit peuvent accéder aux réseaux externes. L'étape suivante consiste à rendre cette connectivité disponible pour les ressources hébergées dans d'autres réseaux VPC.

Le schéma suivant montre la structure générale du VPC, quelle que soit la façon dont vous avez activé la connectivité externe. Il montre un VPC de transit qui met fin aux connexions externes et héberge un routeur Cloud Router dans chaque région. Chaque routeur Cloud Router reçoit les routes de ses pairs externes via les NNI de chaque région. Les VPC d'application sont connectés au VPC de transit afin qu’ils puissent partager une connectivité externe. De plus, le VPC de transit sert de hub pour les VPC spokes. Les VPC spokes peuvent héberger des applications, des services ou une combinaison des deux.

Structure générale de Cross-Cloud Network

Pour des performances et une évolutivité optimales avec les services de mise en réseau cloud intégrés, les VPC doivent être connectés à l'aide de Network Connectivity Center, comme décrit dans Connectivité inter-VPC avec Network Connectivity Center. Network Connectivity Center fournit les éléments suivants :

  • Accès transitif aux points de terminaison Private Service Connect de niveau 4 et 7 et à leurs services associés
  • Accès transitif aux réseaux sur site appris via BGP
  • Échelle du réseau VPC de 250 réseaux par hub

Si vous souhaitez insérer des appliances virtuelles réseau (NVA) pour le pare-feu ou d'autres fonctions réseau, vous devez utiliser l'appairage de réseaux VPC. Les pare-feu de périmètre peuvent rester sur les réseaux externes. Si l'insertion de NVA est requise, utilisez le modèle de connectivité inter-VPC avec l'appairage de réseaux VPC pour interconnecter vos VPC.

Configurez également le transfert et l'appairage DNS dans le VPC de transit. Pour en savoir plus, consultez la section Conception de l'infrastructure DNS.

Les sections suivantes présentent les conceptions possibles de connectivité hybride qui prennent en charge la connectivité IP de base ainsi que les déploiements de points d'accès aux API.

Connectivité inter-VPC avec Network Connectivity Center

Nous recommandons que les VPC d'application, les VPC de transit et les VPC d'accès aux services se connectent tous à l'aide de spokes VPC Network Connectivity Center.

Les points d'accès client de service sont déployés dans des VPC d'accès aux services lorsqu'ils doivent être accessibles depuis d'autres réseaux (autres VPC ou réseaux externes). Vous pouvez déployer des points d'accès pour les consommateurs de services dans des VPC d'application si ces points d'accès ne doivent être accessibles qu'à partir du VPC d'application.

Si vous devez fournir un accès aux services derrière l'accès aux services privés, créez un VPC d'accès aux services qui est connecté à un VPC de transit à l'aide d'un VPN haute disponibilité. Connectez ensuite le VPC des services gérés au VPC d'accès aux services. Le VPN haute disponibilité permet le routage transitif à partir d'autres réseaux.

La conception est une combinaison de deux types de connectivité :

  • Network Connectivity Center : fournit une connectivité entre les VPC de transit, les VPC d'application et les VPC d'accès aux services qui hébergent les points de terminaison Private Service Connect.
  • Connexions inter-VPC via VPN haute disponibilité : fournissent une connectivité transitive pour les sous-réseaux d'accès aux services privés hébergés sur les VPC d'accès aux services. Ces VPC d'accès aux services ne doivent pas être ajoutés en tant que spoke du hub Network Connectivity Center.

Lorsque vous combinez ces types de connectivité, tenez compte des points suivants :

  • Redistribution des sous-réseaux d'appairage de réseaux VPC et de pairs Network Connectivity Center dans le routage dynamique (vers le VPC d'accès aux services via un VPN haute disponibilité et vers les réseaux externes via des interconnexions hybrides)
  • Considérations relatives au routage multirégional
  • Propagation des routes dynamiques à l'appairage de réseaux VPC et à l'appairage Network Connectivity Center (à partir du VPC d'accès aux services via un VPN haute disponibilité et à partir de réseaux externes via des interconnexions hybrides)

Le schéma suivant montre un VPC d'accès aux services hébergeant des sous-réseaux d'accès aux services privés connectés au VPC de transit avec un VPN haute disponibilité. Le schéma montre également les VPC d'application, les VPC de transit et les VPC d'accès aux services hébergeant des points de terminaison de consommateur Private Service Connect connectés à l'aide de Network Connectivity Center :

Structure générale de Cross-Cloud Network utilisant des spokes VPC Network Connectivity Center

La structure présentée dans le schéma précédent contient les composants suivants :

  • Réseau externe : centre de données ou bureau distant dans lequel vous disposez de l'équipement réseau. Cet exemple suppose que les emplacements sont connectés entre eux à l'aide d'un réseau externe.
  • Réseau VPC de transit : réseau VPC du projet de hub qui envoie les connexions depuis l'environnement sur site et d'autres fournisseurs de services cloud, puis sert de chemin de transit depuis d'autres VPC vers les réseaux de l'environnement sur site et du fournisseur de services cloud.
  • VPC d'application : projets et réseaux VPC hébergeant diverses applications.
  • VPC de consommateur pour l'accès privé aux services : réseau VPC hébergeant un accès centralisé via l'accès privé aux services requis par les applications dans d'autres réseaux.
  • VPC de services gérés : services fournis et gérés par d'autres entités, mais rendus accessibles aux applications exécutées dans des réseaux VPC.
  • Réseau VPC consommateur pour Private Service Connect : réseau VPC hébergeant des points d'accès Private Service Connect à des services hébergés dans d'autres réseaux.

Utilisez Network Connectivity Center pour connecter les VPC d'application aux rattachements de VLAN Cloud Interconnect et aux instances VPN haute disponibilité dans les VPC de transit. Transformez tous les VPC en spokes du hub Network Connectivity Center, et transformez les rattachements de VLAN et les VPN haute disponibilité en spokes hybrides du même hub Network Connectivity Center. Utilisez la topologie maillée Network Connectivity Center par défaut pour permettre la communication entre tous les spokes (VPC et hybrides). Cette topologie permet également la communication entre les VPC d'application soumis aux règles Cloud NGFW. Les VPC de services consommateurs connectés via un VPN haute disponibilité ne doivent pas être des spokes du hub Network Connectivity Center. Les points de terminaison Private Service Connect peuvent être déployés dans les spokes VPC Network Connectivity Center et ne nécessitent pas de connexion VPN haute disponibilité pour la transitivité entre les VPC lors de l'utilisation de Network Connectivity Center.

Connectivité inter-VPC avec l'appairage de réseaux VPC

Lorsque les points d'accès aux clients de services publiés sont déployés dans un VPC d'accès aux services, nous recommandons que les VPC d'application se connectent au VPC de transit à l'aide de l'appairage de réseaux VPC et que les VPC d'accès aux services se connectent au VPC de transit via un VPN haute disponibilité.

Dans cette conception, le VPC de transit est le hub, et vous déployez les points d'accès des consommateurs pour les points de terminaison de service privé dans un VPC d'accès aux services.

La conception est une combinaison de deux types de connectivité :

  • Appairage de réseaux VPC : fournit une connectivité entre le VPC de transit et les VPC d'application.
  • Connexions inter-VPC via VPN haute disponibilité : fournissent une connectivité transitive entre les VPC d'accès aux services et le VPC de transit.

Lorsque vous combinez ces architectures, tenez compte des points suivants :

  • Redistribution des sous-réseaux de pairs VPC dans le routage dynamique (vers le VPC d'accès aux services via un VPN haute disponibilité et vers les réseaux externes via des connexions hybrides)
  • Considérations relatives au routage multirégional
  • Propagation des routes dynamiques à l'appairage de VPC (à partir du VPC d'accès aux services via un VPN haute disponibilité et à partir de réseaux externes via des connexions hybrides)

Le schéma suivant montre un VPC d'accès aux services, connecté au VPC de transit avec un VPN haute disponibilité, et les VPC d'application, connectés au VPC de transit avec appairage de réseaux VPC :

VPC de services connecté au VPC de transit avec un VPN haute disponibilité, et VPC d'application connectés au VPC de transit avec appairage de réseaux VPC

La structure présentée dans le schéma précédent contient les composants suivants :

  • Emplacement du client : centre de données ou bureau distant dans lequel vous disposez de l'équipement réseau. Cet exemple suppose que les emplacements sont connectés entre eux à l'aide d'un réseau externe.
  • Agglomération : zone métropolitaine contenant un ou plusieurs domaines de disponibilité de périphérie Cloud Interconnect. Cloud Interconnect se connecte à d'autres réseaux dans ces zones métropolitaines.
  • Projet de hub : projet hébergeant au moins un réseau VPC servant de hub pour d'autres réseaux VPC.
  • VPC de transit : réseau VPC du projet de hub qui envoie les connexions depuis l'environnement sur site et d'autres fournisseurs de services cloud, puis sert de chemin de transit depuis d'autres VPC vers les réseaux de l'environnement sur site et du fournisseur de services cloud.
  • Projets hôtes d'application et VPC : projets et réseaux VPC hébergeant diverses applications.
  • VPC d'accès aux services : réseau VPC hébergeant un accès centralisé aux services requis par les applications dans les réseaux VPC d'applications.
  • VPC de services gérés : services fournis et gérés par d'autres entités, mais rendus accessibles aux applications exécutées dans des réseaux VPC.

Pour la conception avec appairage de réseaux VPC, lorsque les VPC d'application doivent communiquer entre eux, vous pouvez connecter les VPC d'application à un hub Network Connectivity Center en tant que spokes VPC. Cette approche permet la connectivité entre tous les VPC du hub Network Connectivity Center. Vous pouvez créer des sous-groupes de communication en utilisant plusieurs hubs Network Connectivity Center. Les règles de pare-feu permettent de mettre en place les restrictions de communication requises entre les points de terminaison d'un hub donné.

La sécurité des charges de travail pour les connexions est-ouest entre les VPC d'application peut utiliser le pare-feu Cloud nouvelle génération.

Pour obtenir des conseils détaillés et des plans de configuration afin de déployer ces types de connectivité, consultez Architecture de réseau en étoile.

Conception de l'infrastructure DNS

Dans un environnement hybride, Cloud DNS ou un fournisseur externe (sur site ou CSP) peut gérer une résolution DNS. Les serveurs DNS externes font autorité pour les zones DNS externes, et Cloud DNS fait autorité pour les zonesGoogle Cloud . Le transfert DNS doit être activé de manière bidirectionnelle entreGoogle Cloud et les réseaux externes, et les pare-feu doivent être configurés pour autoriser le trafic de résolution DNS.

Si vous utilisez un VPC partagé pour votre VPC d'accès aux services, dans lequel les administrateurs de différents projets de service d'application peuvent instancier leurs propres services, utilisez une liaison inter-projets de zones DNS. La liaison inter-projets permet de segmenter et de déléguer l'espace de noms DNS aux administrateurs de projet de service.

Dans le cas du transit, où des réseaux externes communiquent avec d'autres réseaux externes via Google Cloud, les zones DNS externes doivent être configurées pour transférer les requêtes directement les unes aux autres. Google Cross-Cloud Network fournirait une connectivité pour les requêtes et réponses DNS, mais Google Cloud DNS est impliqué dans le transfert de tout trafic de résolution DNS entre les zones de réseaux externes. Toutes les règles de pare-feu appliquées dans Cross-Cloud Network doivent autoriser le trafic de résolution DNS entre les réseaux externes.

Le schéma suivant illustre une conception DNS pouvant être utilisée avec n'importe laquelle des configurations de connectivité VPC en étoile proposées dans ce guide de conception :

Conception DNS pouvant être utilisée avec des modèles de connectivité en étoile

Le schéma précédent montre les étapes suivantes du flux de conception :

  1. DNS sur site
    Configurez vos serveurs DNS sur site pour qu'ils fassent autorité pour les zones DNS sur site. Configurez le transfert DNS (pour les noms DNS Google Cloud) en ciblant l'adresse IP de transfert entrant Cloud DNS, qui est créée via la configuration de la règle du serveur entrant dans le VPC hub. Cette configuration permet au réseau sur site de résoudre les noms Google Cloud.
  2. VPC de transit – Proxy de sortie DNS
    Annoncez la plage de proxy de sortie DNS Google 35.199.192.0/19 au réseau sur site à l'aide des routeurs Cloud Router. Les requêtes DNS sortantes provenant de Google vers l'environnement sur site proviennent de cette plage d'adresses IP.
  3. VPC de transit – Cloud DNS
    1. Configurez une règle de serveur entrant pour les requêtes DNS entrantes provenant du réseau sur site.
    2. Configurez la zone de transfert Cloud DNS (pour les noms DNS sur site) ciblant les serveurs DNS sur site.
  4. VPC avec accès aux services – Cloud DNS
    1. Configurez la zone d'appairage DNS des services (pour les noms DNS sur site) en définissant le VPC hub en tant que réseau de pairs. La résolution DNS pour les ressources sur site et de service passe par le VPC de hub.
    2. Configurez les zones privées DNS des services dans le projet hôte des services et associez le VPC partagé des services, le VPC partagé d'application et le VPC hub à la zone. Cela permet à tous les hôtes (sur site et dans tous les projets de service) de résoudre les noms DNS des services.
  5. Projet hôte d'application - Cloud DNS
    1. Configurez la zone d'appairage DNS des applications pour les noms DNS sur site en définissant le VPC hub en tant que réseau de pairs. La résolution DNS pour les hôtes sur site passe par le VPC de hub.
    2. Configurez des zones privées DNS d'application dans le projet hôte d'application et associez le VPC d'application, le VPC partagé des services et le VPC hub à la zone. Cette configuration permet à tous les hôtes (sur site et dans tous les projets de service) de résoudre les noms DNS de l'application.

Pour plus d'informations, consultez la section Architecture hybride utilisant un réseau VPC hub connecté à des réseaux VPC spoke.

Étapes suivantes

Contributeurs

Auteurs :

  • Victor Moreno | Responsable produit, Mise en réseau cloud
  • Ghaleb Al-habian | Spécialiste réseau
  • Deepak Michael | Ingénieur client spécialiste en gestion des réseaux
  • Osvaldo Costa | Ingénieur client spécialiste en gestion des réseaux
  • Jonathan Almaleh | Consultant solutions techniques pour le personnel

Autres contributeurs :