Architecture hub-and-spoke

Last reviewed 2024-07-29 UTC

Ce document présente deux options d'architecture pour configurer une topologie de réseau hub-and-spoke dans Google Cloud. L'une utilise la fonctionnalité d'appairage de réseaux du cloud privé virtuel (VPC) et l'autre utilise Cloud VPN.

Les entreprises peuvent 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 et d'associer les autres réseaux VPC en tant que spokes. Le schéma suivant illustre un exemple de réseau hub-and-spoke, parfois appelé topologie en étoile.

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

Dans cet exemple, des réseaux VPC spoke distincts sont utilisés pour les charges de travail des unités commerciales individuelles au sein d'une grande entreprise. Chaque réseau VPC spoke est connecté à un réseau VPC hub 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.

Architecture utilisant l'appairage de réseaux VPC

Le schéma suivant présente un réseau hub-and-spoke utilisant 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
  • Dans cette architecture, les ressources nécessitant une isolation au niveau du réseau utilisent également des réseaux VPC spoke distincts. Par exemple, l'architecture montre une VM Compute Engine sur le réseau VPC spoke-1. Le réseau VPC spoke-2 dispose d'une VM Compute Engine et d'un cluster Google Kubernetes Engine (GKE).
  • Chaque réseau VPC spoke de cette architecture possède une relation d'appairage avec un réseau VPC de hub central.
  • L'appairage de réseaux VPC ne limite pas la bande passante de la VM. Chaque VM peut envoyer du trafic à sa pleine bande passante.
  • Chaque réseau VPC spoke dispose d'une passerelle Cloud NAT pour une communication sortante avec Internet.
  • L'appairage de réseaux VPC ne fournit pas d'annonces de routage transitives. À moins qu'un mécanisme supplémentaire ne soit utilisé, la VM du réseau spoke-1 ne peut pas envoyer de trafic vers la VM du réseau spoke-2. Pour contourner cette contrainte de non-transitivité, l'architecture offre la possibilité d'utiliser Cloud VPN pour transférer les routes entre les réseaux. Dans cet exemple, les tunnels VPN entre le réseau VPC spoke-2 et le réseau VPC hub permettent d'accéder au réseau VPC spoke-2 à partir des autres spokes. Si vous avez besoin d'une connectivité entre seulement quelques spokes spécifiques, vous pouvez appairer directement ces paires de réseaux VPC.

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 ressources nécessitant une isolation au niveau du réseau utilisent des réseaux VPC spoke distincts.
  • Les tunnels VPN IPSec connectent chaque réseau VPC spoke à un réseau VPC hub.
  • Il existe une zone privée DNS dans le réseau hub, ainsi qu'une zone d'appairage DNS et une zone privée dans chaque réseau spoke.
  • La bande passante entre les réseaux est limitée par les bandes passantes totales des tunnels.

Lorsque vous choisissez entre les deux architectures décrites jusqu'ici, tenez compte des avantages relatifs de l'appairage de réseaux VPC et de Cloud VPN :

  • L'appairage de réseaux VPC présente une contrainte de non-transitivité, mais il accepte la bande passante complète définie par le type de machine des VM, ainsi que d'autres facteurs qui déterminent la bande passante réseau. Toutefois, vous pouvez ajouter un routage transitif en ajoutant des tunnels VPN.
  • Cloud VPN autorise le routage transitif, mais la bande passante totale (entrée et sortie) est limitée aux bandes passantes des tunnels.

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 hub
Pour activer la communication entre spokes, 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 hub afin de servir de passerelle pour le trafic spoke-to-spoke.
Appairage de réseaux VPC sans hub
Si vous n'avez pas besoin d'un contrôle centralisé sur la connectivité sur site ou sur les services de partage entre les réseaux VPC, aucun réseau VPC hub n'est nécessaire. Vous pouvez configurer l'appairage pour les paires de réseaux VPC qui nécessitent une connectivité et gérer les interconnexions individuellement. Tenez compte des limites applicables au nombre de relations d'appairage par réseau VPC.
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.

Étapes suivantes