Architecture hub-and-spoke

Ce document présente trois options d'architecture pour configurer une topologie de réseau hub-and-spoke dans Google Cloud. La première utilise Network Connectivity Center, la deuxième l'appairage de réseaux VPC et la troisième Cloud VPN.

Une entreprise peut répartir les charges de travail dans des réseaux VPC individuels à des fins de facturation, d'isolation d'environnement et d'autres considérations. Toutefois, l'entreprise peut également avoir besoin de partager des ressources spécifiques sur ces réseaux, telles qu'un service partagé ou une connexion sur site. Dans ce cas, il peut être utile de placer la ressource partagée dans un réseau hub (appelé réseau de routage dans le reste de ce document) et d'associer les autres réseaux VPC en tant que réseaux spoke (appelés réseaux de charge de travail dans le reste de ce document). Le schéma suivant montre un réseau hub-and-spoke avec deux VPC de charge de travail, bien que vous puissiez en ajouter d'autres.

Schéma du réseau hub-and-spoke.

Dans cet exemple, des réseaux VPC de charge de travail distincts sont utilisés pour les charges de travail des unités commerciales individuelles au sein d'une grande entreprise. Chaque réseau VPC de charge de travail est connecté à un réseau VPC de routage central contenant des services partagés et pouvant servir de point d'entrée unique vers le cloud à partir du réseau sur site de l'entreprise.

Résumé des options

Lorsque vous choisissez l'une des architectures décrites dans ce document, tenez compte des avantages relatifs de Network Connectivity Center, de l'appairage de réseaux VPC et de Cloud VPN:

  • Network Connectivity Center fournit la bande passante complète entre les VPC de charge de travail et assure la transitivité entre les VPC de charge de travail.
  • L'appairage de réseaux VPC offre une bande passante complète entre les VPC de charge de travail et le VPC de routage. Il n'assure pas de transitivité entre les VPC de charge de travail. L'appairage de réseaux VPC est compatible avec le routage vers les NVA d'autres VPC.
  • Cloud VPN autorise le routage transitif, mais la bande passante totale (entrée et sortie) entre les réseaux est limitée aux bandes passantes des tunnels. Vous pouvez ajouter des tunnels supplémentaires pour augmenter la bande passante.

Architecture utilisant Network Connectivity Center

Le schéma suivant présente un réseau hub-and-spoke qui utilise Network Connectivity Center.

Architecture en étoile à l'aide de Network Connectivity Center

Network Connectivity Center dispose d'une ressource de hub qui fournit la gestion du plan de contrôle, mais il ne s'agit pas d'un réseau de hub pour le plan de données.

  • Network Connectivity Center peut connecter les réseaux à l'aide d'une topologie en étoile (hub-and-spoke) ou en réseau maillé. L'utilisation d'une topologie en étoile empêche la communication entre les spokes VPC (VPC de charge de travail), contrairement à la topologie en maillage.
  • Le réseau VPC de routage (hub) est connecté au réseau sur site à l'aide de connexions Cloud VPN ou Cloud Interconnect.
  • Les routes dynamiques peuvent être propagées sur les réseaux VPC.
  • Les routes Private Service Connect sont transitives entre les VPC de charge de travail.
  • Les routes d'accès aux services privés sont transitives entre les VPC de charge de travail à l'aide de rayons de producteurs pour de nombreux services fournis par Google. Pour les services dont les routes ne sont pas transitives, vous pouvez connecter le réseau VPC client au réseau VPC de routage à l'aide de Cloud VPN au lieu de Network Connectivity Center.
  • Toutes les VM des réseaux appairés peuvent communiquer à la pleine bande passante.
  • Chaque VPC de charge de travail et le réseau VPC de routage disposent d'une passerelle Cloud NAT pour la communication sortante avec Internet.
  • L'appairage et le transfert DNS sont configurés pour que les charges de travail des VPC de charges de travail puissent être accessibles depuis l'environnement sur site.

Architecture utilisant l'appairage de réseaux VPC

Le schéma suivant présente un réseau hub-and-spoke qui utilise l'appairage de réseaux VPC. qui permet d'établir une communication à l'aide d'adresses IP internes entre les ressources de réseaux VPC distincts. Le trafic reste sur le réseau interne de Google et ne transite pas par l'Internet public.

Architecture hub et spoke via l'appairage de réseaux VPC

  • Chaque réseau VPC de charge de travail (spoke) de cette architecture possède une relation d'appairage avec un réseau VPC de routage central (hub).
  • Le réseau VPC de routage est connecté au réseau sur site à l'aide de connexions Cloud VPN ou Cloud Interconnect.
  • Toutes les VM des réseaux appairés peuvent communiquer à la pleine bande passante.
  • Les connexions d'appairage de réseaux VPC ne sont pas transitives. Dans cette architecture, les réseaux VPC sur site et de charge de travail peuvent échanger du trafic avec le réseau de routage, mais pas entre eux. Pour fournir des services partagés, placez-les dans le réseau de routage ou connectez-les au réseau de routage à l'aide de Cloud VPN.
  • Chaque VPC de charge de travail et le réseau VPC de routage disposent d'une passerelle Cloud NAT pour la communication sortante avec Internet.
  • L'appairage et le transfert DNS sont configurés pour que les charges de travail des VPC de charges de travail puissent être accessibles depuis l'environnement sur site.

Architecture utilisant Cloud VPN

L'évolutivité d'une topologie hub-and-spoke qui utilise l'appairage de réseaux VPC est soumise aux limites d'appairage de réseaux VPC. Comme indiqué précédemment, les connexions d'appairage de réseaux VPC n'autorisent pas le trafic transitif au-delà des deux réseaux VPC dans une relation d'appairage. Le schéma suivant illustre une autre architecture de réseau hub-and-spoke qui utilise Cloud VPN pour contourner les limites de l'appairage de réseaux VPC.

Architecture hub-and-spoke via Cloud VPN

  • Les tunnels VPN IPsec connectent chaque réseau VPC de charge de travail (spoke) à un réseau VPC de routage (hub).
  • Il existe une zone privée DNS dans le réseau de routage, ainsi qu'une zone d'appairage DNS et une zone privée dans chaque réseau de charge de travail.
  • Les connexions sont transitives. Les réseaux VPC sur site et spoke peuvent se connecter les uns aux autres via le réseau de routage, mais cela peut être limité.
  • La bande passante entre les réseaux est limitée par les bandes passantes totales des tunnels.
  • Chaque VPC de charge de travail (spoke) et le réseau VPC de routage disposent d'une passerelle Cloud NAT pour la communication sortante avec Internet.
  • L'appairage de réseaux VPC ne fournit pas d'annonces de routage transitives.
  • L'appairage et le transfert DNS sont configurés pour que les charges de travail des VPC de charges de travail puissent être accessibles depuis un environnement sur site.

Alternatives de conception

Considérez les alternatives architecturales suivantes pour l'interconnexion des ressources déployées dans des réseaux VPC distincts dans Google Cloud:

Connectivité spoke à l'aide d'une passerelle dans le réseau VPC de routage

Pour activer la communication entre réseaux spoke, vous pouvez déployer un dispositif virtuel de réseau (NVA) ou un pare-feu nouvelle génération (NGFW) sur le réseau VPC de routage afin de servir de passerelle pour le trafic spoke-to-spoke.

Créer plusieurs réseaux VPC partagés

Créez un réseau VPC partagé pour chaque groupe de ressources que vous souhaitez isoler au niveau du réseau. Par exemple, pour séparer les ressources utilisées pour les environnements de production et de développement, créez un réseau VPC partagé pour la production et un autre réseau VPC partagé pour le développement. Ensuite, appairez les deux réseaux VPC pour permettre la communication entre eux. Les ressources des projets individuels pour chaque application ou service peuvent utiliser les services du réseau VPC partagé approprié.

Pour connecter les réseaux VPC et votre réseau sur site, vous pouvez utiliser des tunnels VPN distincts pour chaque réseau VPC ou des rattachements de VLAN distincts sur la même connexion Dedicated Interconnect.

Étape suivante