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

Last reviewed 2024-04-05 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 et la connectivité de la segmentation 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.
  • L'emplacement de votre charge de travail
  • La manière dont vos projets sont connectés aux réseaux externes sur site et à d'autres réseaux de 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 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 choisir 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. En même temps, l'équipe de développement peut gérer ses charges de travail dans un projet, et l'équipe de production peut gérer ses charges de travail dans un projet distinct. Les développeurs utilisent ensuite les ressources d'infrastructure du projet d'infrastructure pour créer et gérer des ressources, des services, un équilibreur de charge et des 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 la section 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 VPC de transit, où toute la connectivité externe est gérée.
  • Un VPC de services facultatif, qui peut être utilisé 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 présenté ici 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 sous-réseaux, les connexions de pair à pair 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 services d'applications peuvent partager un nombre réduit de VPC d'applications.

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

Projet hôte consolidé sur l'infrastructure et plusieurs projets de service d'application

Projets hôtes segmentés

Dans ce modèle, chaque groupe d'applications dispose de son propre projet hôte d'application et de ses propres VPC. Plusieurs projets de services 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 liés aux 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 de l'emplacement régional de vos charges de travail. Pour obtenir des conseils sur l'emplacement des charges de travail, consultez la section Bonnes pratiques pour la sélection des régions Compute Engine. Vous devez déterminer l'emplacement de vos charges de travail 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 sur site. Les réseaux externes peuvent être détenus et gérés par différentes organisations. Ces réseaux se connectent physiquement les uns aux autres via une ou plusieurs interfaces réseau à réseau (NNI). La combinaison de NNI doit être conçue, provisionnée et configurée pour les performances, la résilience, la confidentialité et la sécurité.

Pour bénéficier de la modularité, de la réutilisation et de 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 fois dans le VPC de transit et exploitées par de nombreux autres réseaux VPC.

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

Le schéma suivant montre le 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é :

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

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

Si vous exécutez des services dans d'autres réseaux de fournisseurs de services cloud (CSP) que vous souhaitez 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é, des coûts et de la viabilité opérationnelle.

Pour optimiser 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 pouvant atteindre 100 Gbit/s par lien.

Si vous ne pouvez pas utiliser Cross-Cloud Interconnect, vous pouvez utiliser Dedicated Interconnect ou Partner Interconnect 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 Cross-Cloud Interconnect, consultez la liste des emplacements disponibles pour Google Cloud et les CSP (la disponibilité varie selon le fournisseur de cloud).
    • Pour Dedicated Interconnect ou Partner Interconnect, choisissez un emplacement à faible latence pour l'installation hébergée en colocation.
  • Évaluez la latence entre le point de présence (POP) donné et la région concernée dans chaque CSP.

Pour optimiser la fiabilité de vos connexions multicloud, nous vous recommandons une configuration compatible avec 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 à démarrer, et vous pouvez passer à Cross-Cloud Interconnect lorsque vos applications distribuées utilisent 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 d'acheminement pour ces connexions sont similaires à 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 améliorer la résilience et le débit entre les réseaux, utilisez plusieurs chemins pour les connecter.

Lorsque le trafic est transféré sur plusieurs domaines réseau, il doit être inspecté par des appareils 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 inter-domaines pour répondre à vos exigences pour le transit interrégional, la symétrie du trafic, le débit et la 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 Edge, nous vous recommandons de réduire le nombre de préfixes agrégés pour chaque combinaison de région et de domaine dans votre plan d'adressage IP.

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

  • Les réseaux VPC Google Cloud et Cloud Router sont tous deux compatibles avec le routage mondial interrégional. 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éblocage BGP pour définir la préférence des routes. Consultez la documentation de votre CSP pour obtenir plus de détails.

Routage interdomaines dans une seule région

Nous vous suggérons de commencer par le routage interdomaine d'une seule région, sur lequel vous pourrez vous appuyer pour créer des connexions à plusieurs régions avec routage interdomaine.

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.
  • Actif/passif oblige une liaison à devenir une liaison prête à l'emploi, n'acceptant que le trafic si la liaison active est interrompue.

Nous recommandons une conception en mode actif/actif pour les liaisons intrarégionales. Toutefois, certaines topologies de 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 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 des architectures de contrat de niveau de service garantissant une disponibilité de 99,99 %. Il montre des routeurs sur site situés 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 l'acheminement 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éseau Google Cloud, qui fournit une fonctionnalité de routage VPC global.

La symétrie des flux n'est pas toujours obligatoire, mais une 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 à chaud et à froid pour spécifier votre réseau de transports en commun 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 passe à l'autre réseau dans la région d'origine, puis traverse l'autre réseau jusqu'à la destination (routage de type "hot-potato").

Utiliser le routage hot-potato et cold-potato pour spécifier votre réseau de transports en commun interrégional préféré

Chiffrement du trafic entre les domaines

Sauf indication contraire, le trafic n'est pas chiffré sur les connexions Cloud Interconnect entre différents CSP ou entre Google Cloud et des 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 HA 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 page Présentation du VPN haute disponibilité via 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 étatique 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 concerne principalement la fourniture de 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 sur Google Cloud.

Les principales fonctionnalités qui fournissent une connectivité Internet entrante sont les produits Cloud Load Balancing de Google. 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 Google Cloud intégrées, comme décrit dans la section Créer une connectivité Internet pour des VM privées. Vous pouvez également utiliser les NVA NGFW centraux, comme décrit dans la section Sécurité du réseau.

Le chemin principal pour fournir une connectivité Internet sortante est la destination de passerelle Internet par défaut dans la table de routage VPC, qui est souvent la route par défaut dans les VPC Google. Les adresses IP externes et Cloud NAT (service NAT géré de Google 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 Présentation de Cloud Router.

Pour sécuriser la connectivité sortante, Google Cloud propose à la fois l'application du pare-feu Cloud nouvelle génération et le proxy Web sécurisé, afin de fournir un filtrage plus précis des URL HTTP et HTTPS. Cependant, dans tous les cas, 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 Cloud né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. Le BYOIP facilite la portabilité de la connectivité et permet de réduire les coûts liés aux adresses IP.

Connectivité interne et mise en réseau du 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 VPC.

Le schéma suivant illustre 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 spoke. Les VPC de rayon peuvent héberger des applications, des services ou une combinaison des deux.

Structure générale de Cross-Cloud Network

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

Pour obtenir de meilleures performances et des services de mise en réseau cloud intégrés, nous vous recommandons d'interconnecter des VPC via Cross-Cloud Network ou un appairage de réseaux VPC, plutôt qu'avec un VPN haute disponibilité.

Les points de terminaison Private Service Connect et les interfaces d'accès aux services privés ne sont pas accessibles via l'appairage de réseaux VPC ou Cross-Cloud Network. Nous vous recommandons l'utilisation d'un VPN haute disponibilité pour la connectivité inter-VPC afin de surmonter ces limites. Étant donné que l'utilisation d'un VPN haute disponibilité pour la connectivité inter-VPC peut entraîner une baisse du débit et une augmentation des frais généraux opérationnels, la conception des services centralisés réduit la portée du déploiement du VPN haute disponibilité.

Vous pouvez aussi implémenter une connectivité transitive inter-VPC aux points de terminaison de service publiés en plaçant un équilibreur de charge réseau proxy interne devant les points de terminaison du service. Cette approche présente certaines limites à prendre en compte, décrites dans la section Connectivité avec les spokes Network Connectivity Center utilisant l'équilibrage de charge.

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 de terminaison d'API.

Connectivité inter-VPC pour l'accès aux services partagés

Lorsque les points de terminaison de service publiés sont déployés dans un VPC de services, nous recommandons que les VPC d'application se connectent au hub via l'appairage de réseaux VPC (VPC de transit) et que le VPC de services se connecte au hub 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 services privés dans un VPC de services.

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

  • Appairage de réseaux VPC : fournit une connectivité entre le VPC hub et les VPC d'application.
  • Connexions inter-VPC via VPN haute disponibilité : fournissent une connectivité transitive pour le VPC de services vers le hub.

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

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

  • Redistribution des sous-réseaux pairs VPC en routage dynamique (vers VPN haute disponibilité ou hybride)
  • Considérations sur le routage multirégional
  • Propagation des routes dynamiques à l'appairage de VPC (à partir d'un VPN haute disponibilité et hybride)

Le schéma suivant montre un VPC de 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 établissements 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 de 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 en étoile, lorsque les VPC d'application doivent communiquent entre eux, vous pouvez connecter les VPC d'application à un hub Network Connectivity Center en tant que spokes. Cette approche permet d'assurer 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é.

Connectivité avec les VPC spoke Network Connectivity Center à l'aide de l'équilibrage de charge

Ce modèle inclut tous les VPC en tant que spokes dans un hub Network Connectivity Center, et peut accueillir jusqu'à 250 VPC interconnectés. Un hub Network Connectivity Center est un plan de gestion qui crée une connectivité de plan de données maillé complète entre tous les réseaux VPC enregistrés en tant que spokes au hub Network Connectivity Center. Ce modèle fournit une connectivité de type "n'importe quel point à n'importe quel point" et permet le déploiement de points d'accès aux services gérés dans n'importe quel VPC.

Pour contourner les limites de transitivité, les points d'accès aux services gérés et aux connexions hybrides sont accessibles via des équilibreurs de charge réseau proxy internes. La sécurité des charges de travail pour les connexions est-ouest peuvent utiliser le pare-feu Cloud nouvelle génération. Vous pouvez également utiliser le NAT inter-VPC avec ce modèle.

Ce modèle présente certaines limites. Vous devez donc prendre en compte les éléments suivants avant de l'adopter :

  • Vous ne pouvez pas utiliser de pare-feu de périmètre avec NVA avec ce modèle. Les pare-feu de périmètre doivent rester sur les réseaux externes.
  • Seul le trafic TCP est accepté vers et depuis les réseaux externes. Cette limitation est due au fait que les connexions à des réseaux externes passent par un équilibreur de charge réseau proxy interne.
  • Les services publiés disposeront d'une interface supplémentaire dans l'équilibreur de charge proxy. Cette interface supplémentaire prolifère des enregistrements supplémentaires dans le DNS et nécessite des résolutions DNS fractionnées.
  • Les services de couche 4 nécessitent un nouvel équilibreur de charge réseau proxy interne pour chaque nouveau service. Vous aurez peut-être besoin de différents équilibreurs de charge en fonction des protocoles requis pour la connexion.
  • Les quotas d'équilibrage de charge sont limités pour chaque réseau VPC. C'est un point important à prendre en compte, car les services de couche 4 nécessitent un nouvel équilibreur de charge réseau proxy interne pour chaque service de destination.
  • L'option de conception haute disponibilité et basculement interrégional choisie dépend de vos exigences.
  • Le trafic chiffré au-delà de la limite hybride a des conséquences sur la coordination de la gestion des certificats.

Si les considérations précédentes sont des compromis gérables ou ne sont pas pertinentes pour votre environnement, nous vous recommandons ce modèle comme option à privilégier.

Le schéma suivant illustre un hub hybride Network Connectivity Center en tant que plan de gestion pour les connexions Cloud Interconnect. Il affiche également un hub VPC Network Connectivity Center connectant les spokes VPC de l'application et des services :

VPC d'application connectés en tant que spokes à un hub Network Connectivity Center

Équilibrage de charge proxy pour la transitivité

Les éléments suivants ne sont pas accessibles à travers les VPC spoke Network Connectivity Center :

  • Points de terminaison de services Private Service Connect et interfaces utilisateur de services gérés
  • Réseaux derrière des connexions hybrides (Cloud Interconnect ou VPN haute disponibilité) car les routes dynamiques ne sont pas propagées via Cross-Cloud Network.

Pour contourner ces limites de transitivité, déployez des équilibreurs de charge réseau proxy internes avec les ressources non transitives gérées en tant que groupes de points de terminaison du réseau (NEG) hybrides. Vous pouvez déployer des équilibreurs de charge réseau proxy internes devant les interfaces de service et devant les points de terminaison accessibles via les connexions hybrides. Les interfaces de l'équilibreur de charge réseau proxy interne sont déployées dans des sous-réseaux VPC propagés sur des VPC de spoke Cross-Cloud Network. Les équilibreurs de charge réseau proxy internes permettent d'accéder aux ressources non transitives via Cross-Cloud Network. Pour les hôtes et services externes, les points de terminaison Private Service Connect et les réseaux d'accès aux services privés, les backends doivent être configurés en tant que NEG hybrides. Les backends Private Service Connect sont le seul modèle dans lequel les NEG n'ont pas besoin d'être hybrides.

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 zones Google Cloud. Le transfert DNS doit être activé de manière bidirectionnelle entre Google 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 de services centraux, 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 la segmentation et la délégation de l'espace de noms DNS aux administrateurs du projet de service.

Dans le cas du transit, lorsque 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 vers les 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 d'environnements sur site.
    2. Configurez la zone de transfert Cloud DNS (pour les noms DNS sur site) ciblant les serveurs DNS sur site.
  4. Services VPC - 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 des ressources sur site et des services passe par le VPC 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 :