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 :

Dans cette partie, nous explorons la structure de la segmentation du réseau et la connectivité, qui constitue 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 réseaux 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.
  • La manière dont vos sous-réseaux VPC Google Cloud sont connectés les uns aux autres et à d'autres réseaux, y compris la façon dont vous configurez la joignabilité des services et le DNS.

Segmentation du réseau et structure de 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é, dans lequel vous utilisez un seul projet hôte d'infrastructure pour gérer toutes les 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

Lors de la phase de planification, nous vous recommandons également de choisir les domaines administratifs pour vos environnements de charge de travail. Limitez les autorisations pour les administrateurs et les développeurs d'infrastructure en fonction du principe du moindre privilège, et limitez 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 au sein d'un projet d'infrastructure. Par exemple, pour configurer la connectivité à des 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, et l'équipe de production peut les gérer dans un projet distinct. Les développeurs peuvent ensuite utiliser les ressources d'infrastructure du projet d'infrastructure pour créer et gérer des ressources, des services, l'équilibrage de charge et des règles de routage DNS pour leurs charges de travail.

En outre, vous devez décider du nombre de réseaux VPC que vous allez mettre en œuvre initialement et de la manière dont ils seront organisés dans la hiérarchie des ressources. Pour savoir comment choisir une hiérarchie de ressources, consultez la page Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud. Pour en savoir plus sur le choix du nombre de réseaux VPC, consultez la section Décider s'il convient de créer 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, dans lequel toute la connectivité externe est gérée.
  • Un VPC de services centraux facultatif, qui peut être utilisé pour consolider le déploiement d'un accès privé aux services publiés.

Le schéma suivant illustre une représentation visuelle de la structure de VPC recommandée qui vient d'être décrite. Vous pouvez utiliser la structure de VPC présentée dans le schéma avec une structure consolidée ou segmentée, comme décrit dans les sections suivantes. Le schéma présenté ici n'illustre pas la connectivité entre les réseaux VPC.

Structure de VPC recommandée

Projet hôte d'infrastructure consolidée

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

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

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

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

Projet hôte d'infrastructure consolidée et projets de service d'applications 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 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 imputés au projet hôte de l'infrastructure, tandis que les frais de réseau liés aux applications sont facturés sur chaque projet hôte.

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 schéma n'affiche pas la connectivité entre tous les projets.

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

Emplacement des charges 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 la page Bonnes pratiques pour la sélection des régions Compute Engine. Vous devez décider de 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 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 être détenus et gérés par différentes organisations. Ces réseaux se connectent physiquement les uns aux autres au niveau d'une ou plusieurs interfaces réseau à réseau (NNI). La combinaison de NNI doit être conçue, provisionnée et configurée pour garantir les performances, la résilience, la confidentialité et la sécurité.

Pour assurer la modularité, la réutilisation et la possibilité d'insérer des NVA de sécurité, placez les connexions et le routage externes dans un VPC de transit, qui sert ensuite de service de connectivité partagé pour d'autres VPC. Les règles de routage pour la résilience, le basculement et la préférence de chemin 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 sera 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é en tant que service de connectivité partagé pour d'autres VPC

Connexions privées à d'autres fournisseurs cloud

Si vous souhaitez connecter à votre réseau Google Cloud des services qui s'exécutent sur des réseaux d'autres fournisseurs de services cloud, vous pouvez vous y connecter via Internet ou via des connexions privées. Nous vous recommandons d'utiliser des connexions privées.

Lorsque vous choisissez les 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 haut débit directe entre les réseaux cloud. Les connexions directes éliminent le besoin d'équipements de mise en réseau physique intermédiaires. Nous vous recommandons d'utiliser Cross-Cloud Interconnect, qui fournit ces connexions directes, ainsi qu'un chiffrement MACsec et un débit de 100 Gbit/s par lien.

Si vous ne pouvez pas utiliser Cross-Cloud Interconnect, vous pouvez utiliser l'interconnexion dédiée ou partenaire via une installation hébergée en colocation.

Sélectionnez les emplacements dans lesquels 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, vérifiez la liste des emplacements disponibles pour Google Cloud et les fournisseurs de services cloud (la disponibilité varie selon le fournisseur cloud).
    • Pour une interconnexion dédiée ou une interconnexion partenaire, choisissez un emplacement à faible latence pour l'installation hébergée en colocation.
  • Évaluez la latence entre la périphérie du point de présence (POP) donnée et la région appropriée dans chaque fournisseur de services cloud.

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 en savoir plus, consultez les pages Haute disponibilité Cross-Cloud Interconnect, Établir une disponibilité de 99,99% pour l'interconnexion dédiée et Établir une disponibilité de 99,99% avec une interconnexion partenaire.

Si vous n'avez pas besoin d'une bande passante élevée entre les différents fournisseurs de services cloud, il est possible d'utiliser des tunnels VPN. Cette approche peut vous aider à démarrer et vous pourrez passer à Cross-Cloud Interconnect lorsque vos applications distribuées utilisent davantage de bande passante. Les tunnels VPN peuvent également atteindre un contrat de niveau de service garantissant une disponibilité de 99,99 %. Pour plus d'informations, consultez la page 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 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, connectez les réseaux à l'aide de plusieurs chemins.

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

Pour les réseaux qui transfèrent des données entre plusieurs régions, le coût et le niveau de qualité du 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 interdomaine pour répondre à vos exigences en matière 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éfixe sur les appareils de périphérie, nous vous recommandons de réduire le nombre de préfixes agrégés pour chaque région et combinaison de domaines 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 interrégional mondial. 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 fournisseur de services cloud.
  • Cloud Router annonce automatiquement les routes avec des préférences de chemin d'accès 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 fournisseurs de services cloud prennent en charge différentes fonctions BGP et BFD (Détection de transfert bidirectionnel), et le routeur Cloud Router de Google dispose également de fonctionnalités de règles de routage spécifiques, comme décrit dans la section Établir des sessions BGP.
  • Différents fournisseurs de services cloud peuvent utiliser des attributs de départage BGP différents pour dicter la préférence pour les routes. Pour en savoir plus, consultez la documentation de votre fournisseur de services cloud.

Routage inter-domaine dans une seule région

Nous vous suggérons de commencer par le routage interdomaine dans une seule région, sur lequel vous allez vous appuyer pour créer des connexions multirégionales avec routage inter-domaine.

Les conceptions qui utilisent Cloud Interconnect doivent disposer d'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 :

  • Le mode actif/actif utilise le routage ECMP (Equal Cost Multi-Path) pour agréger la bande passante des deux chemins et les utiliser simultanément pour le trafic interdomaine. Cloud Interconnect est également compatible avec l'utilisation de liaisons agrégées LACP pour atteindre jusqu'à 200 Gbit/s de bande passante globale par chemin.
  • En mode actif/passif, une liaison est considérée comme une instance de secours prête à l'emploi, et n'accepte le trafic que si la liaison active est interrompue.

Nous recommandons une conception en mode actif/actif pour les liaisons intrarégionales. Toutefois, certaines topologies de réseaux 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 au sein d'une région. Cette conception peut offrir une disponibilité de 99,9% dans le contrat de niveau de service au sein d'une seule zone métropolitaine lorsque vous suivez les consignes permettant d'établir une disponibilité de 99,9 % pour l'interconnexion dédiée.

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

Routage inter-domaine multirégional

Pour fournir une connectivité de sauvegarde, 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 de contrat de niveau de service garantissant une disponibilité de 99,99 %. Il montre les 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 de routage multirégional doit respecter une 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 de type "patate chaude" ou de type "patate froide". Associez le routage de type "patate froide" dans un domaine au routage de type "patate chaude" dans le domaine appairé. 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 de flux n'est pas toujours obligatoire, mais elle peut entraîner des problèmes avec les fonctions de sécurité avec état.

Le schéma suivant montre comment utiliser le routage de type "patate chaude" ou "patate froide" 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 de la région d'origine, puis transite sur l'autre réseau jusqu'à la destination (routage de type "hot-potato" ou "patate chaude").

Utiliser le routage de type "patate chaude" ou "patate froide" pour spécifier votre réseau de transit interrégional préféré

Chiffrement du trafic interdomaine

Sauf indication contraire, le trafic n'est pas chiffré sur les connexions Cloud Interconnect entre différents fournisseurs de services cloud 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 haute disponibilité sont chiffrés par IPsec et déployés via des connexions Cloud Interconnect qui peuvent également être chiffrées 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 avec état la direction inverse de la direction de la requête d'origine.

En règle générale, 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 sens 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. Il peut s'agir par exemple de la connectivité Internet à des serveurs d'applications Web et à des serveurs de jeux hébergés sur Google Cloud.

Les principales fonctionnalités fournissant une connectivité Internet entrante sont les produits Cloud Load Balancing de Google.

Tous les types de service Cloud Load Balancing fournissent leur propre chemin pour le trafic renvoyé vers la source Internet, que vous utilisiez des chemins de retour spéciaux ou des réseaux proxy définis par l'utilisateur. La conception du VPC est généralement 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 la section Créer une connectivité Internet pour les VM privées. Vous pouvez également utiliser des 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 la 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 la 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 des adresses IPv4 appartenant à Google pour la connectivité Internet ou vous pouvez utiliser l'option 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 d'adresses IP en utilisant son utilisation exclusive. 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 VPC

Une fois le service de connectivité externe et hybride configuré, les ressources du VPC de transit peuvent atteindre les 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 manière 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 de pouvoir partager une connectivité externe. En outre, le VPC de transit fonctionne comme un hub pour les VPC spoke. Les VPC spoke peuvent héberger des applications, des services ou une combinaison des deux.

Structure générale de Cross-Cloud Network

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.

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 d'utiliser un VPN haute disponibilité pour la connectivité inter-VPC afin de contourner ces limites. Étant donné que l'utilisation d'un VPN haute disponibilité pour la connectivité inter-VPC peut réduire le débit et accroître les coûts opérationnels, la conception des services centralisés réduit la portée du déploiement du VPN haute disponibilité.

Vous pouvez également mettre en œuvre une connectivité transitive inter-VPC vers des 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 comporte certaines limites à prendre en compte, qui sont décrites dans la section Connectivité avec les spokes Network Connectivity Center à l'aide de l'équilibrage de charge.

Les sections suivantes présentent les conceptions possibles pour la connectivité hybride compatible avec la connectivité IP de base, ainsi que les déploiements de points de terminaison d'API.

Connectivité inter-VPC pour les services centralisés

Lorsque les points de terminaison de service publiés peuvent être déployés dans un VPC de services centraux, 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 des services centraux se connecte au hub via un VPN haute disponibilité.

Dans cette conception, le VPC de transit est le hub et vous déployez les règles de transfert pour les points de terminaison de service privés dans un VPC de services centraux. Faites en sorte que le VPC de services centraux constitue un VPC partagé et laissez les administrateurs des projets de service créer des points de terminaison de service dans le réseau partagé.

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 centraux vers le hub.

Pour obtenir des conseils détaillés et des plans de configuration pour déployer ces types de connectivité, consultez la section Architecture de réseau hub-and-spoke.

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

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

Le schéma suivant montre un VPC de services centraux 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 centraux connectés au VPC de transit avec 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 à 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 de 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'applications doivent communiquer entre eux, vous pouvez connecter les VPC d'application à un hub Network Connectivity Center en tant que spokes. Cette approche fournit une connectivité entre tous les VPC du hub Network Connectivity Center. Les sous-groupes de communication peuvent être créés à l'aide de plusieurs hubs du centre de connectivité réseau. Toutes les restrictions de communication requises entre les points de terminaison d'un hub particulier peuvent être obtenues à l'aide de stratégies de pare-feu.

Connectivité avec des 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 accepter jusqu'à 250 VPC interconnectés. Un hub Network Connectivity Center est une construction de plan de gestion qui crée une connectivité complète du plan de données maillé entre tous les réseaux VPC enregistrés en tant que spokes vers le hub Network Connectivity Center. Ce modèle fournit une connectivité de type "any-to-any" et permet le déploiement de services gérés dans n'importe quel VPC, éliminant ainsi la nécessité de choisir entre des services centraux ou distribués.

Pour contourner les limites de transitivité, les services gérés et les connexions hybrides sont accessibles via des équilibreurs de charge réseau proxy internes. La sécurité de la charge de travail pour les connexions est-ouest peut utiliser le pare-feu Cloud nouvelle génération. Vous pouvez également utiliser la 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 NVA pour les pare-feu de périmètre avec ce modèle. Les pare-feu de périmètre doivent rester sur des réseaux externes.
  • Seul le trafic TCP est compatible avec les réseaux externes. Cette limitation se produit car les connexions aux réseaux externes s'exécutent via un équilibreur de charge réseau proxy interne.
  • Les services publiés disposent 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. Ceci est un aspect 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 besoins.
  • 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 montre 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 service Private Service Connect et interfaces de services gérés.
  • Réseaux situés derrière des connexions hybrides (Cloud Interconnect ou VPN haute disponibilité), car les routes dynamiques ne sont pas propagées sur Cross-Cloud Network.

Ces limites de transitivité peuvent être contournées en déployant 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 qui sont propagés sur des VPC 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 les 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 fournisseur de services cloud) peut gérer une résolution DNS. Les serveurs DNS externes font autorité pour les zones DNS externes, tandis que 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 des 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 de transit, où les réseaux externes communiquent avec d'autres réseaux externes via Google Cloud, les zones DNS externes doivent être configurées pour se transférer directement les requêtes les unes aux autres. Le réseau Cross-Cloud de Google fournirait une connectivité pour les requêtes et les réponses DNS, mais Google Cloud DNS est impliqué dans le transfert de tout le 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 les 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 soient primaires 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 DNS Google Cloud.
  2. VPC de transit - Proxy de sortie DNS
    Annoncez la plage de proxys de sortie DNS de Google 35.199.192.0/19 au réseau sur site à l'aide des routeurs cloud. Les requêtes DNS sortantes 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'un environnement sur site.
    2. Configurez la zone de transfert Cloud DNS (pour les noms DNS sur site) ciblant les serveurs DNS sur site.
  4. VPC de 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 des ressources sur site et des ressources de service 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 une zone d'appairage DNS d'application 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 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 d'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 :