Spokes VPC
Network Connectivity Center fournit une connectivité réseau inter-VPC à grande échelle, compatible avec les spokes VPC. Les spokes VPC réduisent la complexité des opérations de gestion des connexions d'appairage individuelles entre deux réseaux VPC grâce à un modèle plus simple de gestion centralisée de la connectivité. Ils exportent et importent les routes de sous-réseau IPv4 vers/depuis d'autres spokes Cela garantit une connectivité IPv4 complète entre toutes les charges de travail résidant dans tous ces réseaux VPC. Le trafic réseau inter-VPC reste à l'intérieur du réseau Google Cloud et ne transite pas par Internet, ce qui contribue à garantir la confidentialité et la sécurité.
Les spokes VPC peuvent se trouver dans le même projet et la même organisation, ou dans un projet et une organisation différents du hub Network Connectivity Center.
Les spokes VPC peuvent être connectés à un hub à la fois.
Pour en savoir plus sur la création d'un spoke VPC, consultez la section Créer un spoke VPC.
Comparaison avec l'appairage de réseaux VPC
Les spokes VPC sont conçus pour répondre aux exigences de charge de travail moyenne à grande des entreprises pour la connectivité acheminée entre les plages de sous-réseaux IPv4 situées dans de nombreux réseaux VPC distincts.
Un réseau VPC peut être à la fois un spoke Network Connectivity Center et être connecté à d'autres réseaux VPC à l'aide de l'appairage de réseaux VPC. Les routes d'appairage de sous-réseau que le réseau VPC spoke importe à l'aide de l'appairage de réseaux VPC ne sont pas partagées avec d'autres spokes VPC connectés au hub Network Connectivity Center. Par conséquent, les services gérés basés sur l'accès aux services privés ne sont pas accessibles de manière transitoire via les autres spokes VPC d'un hub Network Connectivity Center.
| Caractéristique | Appairage de réseaux VPC | Spokes VPC |
|---|---|---|
| Réseaux VPC |
Jusqu'à 25 (nécessite de réduire les autres quotas de VPC) |
Jusqu'à 250 spokes VPC actifs par hub |
| Instances de VM |
Network Connectivity Center accepte jusqu'à la limite par réseau VPC (aucun quota distinct de groupes d'appairage nécessaire). |
|
| Plages de sous-réseaux (routes de sous-réseau) | ||
| Routes statiques et dynamiques |
L'échange de route statique et dynamique n'est pas accepté. |
|
| Filtres d'exportation |
Les filtres spécifiques ne sont pas acceptés. Consultez la section Options d'échange de routage dans la documentation sur l'appairage de réseaux VPC. |
Jusqu'à 16 plages CIDR acceptées par spoke VPC. |
| Adressage IP |
Adresses IP internes, y compris des adresses IP privées et des adresses IPv4 publiques utilisées en mode privé. Consultez la section Plages IPv4 valides. |
Adresses IPv4 internes privées uniquement, à l'exclusion des adresses IPv4 publiques utilisées en mode privé. Consultez la section Plages IPv4 valides. |
| Familles d'adresses IP |
Adresses à double pile IPv4 et IPv6/IPv4 |
Adresses IPv4 uniquement |
| Performances et débit (par rapport à d'autres mécanismes de connectivité VPC) |
Latence la plus faible, débit le plus élevé (équivalent VM à VM) |
Latence la plus faible, débit le plus élevé (équivalent VM à VM) |
Spokes VPC dans un projet différent d'un hub
En utilisant Network Connectivity Center, vous pouvez associer des réseaux VPC, représentés par des spokes, à un seul hub dans un autre projet, y compris un projet d'une autre organisation. Cela vous permet de connecter vos réseaux VPC à plusieurs projets et organisations à grande échelle.
Vous pouvez utiliser les types d'utilisateurs suivants :
- Administrateur de hub propriétaire d'un hub dans un projet
- Un administrateur de spoke dans un réseau VPC ou un administrateur réseau qui souhaite ajouter son réseau VPC dans un autre projet en tant que spoke vers le hub
L'administrateur du hub contrôle qui peut créer un spoke VPC dans un autre projet associé à son hub à l'aide des autorisations IAM (Identity and Access Management). L'administrateur de spoke dans le réseau VPC crée un spoke dans un projet différent du hub. Ces spokes sont inactifs lors de leur création. L'administrateur du hub doit les examiner, et peut accepter ou refuser le spoke. Si l'administrateur du hub accepte le spoke, celui-ci devient actif.
Network Connectivity Center accepte toujours automatiquement les spokes créés dans le même projet que le hub.
Pour en savoir plus sur la gestion des hubs comportant des spokes VPC dans un projet différent du hub, consultez la section Présentation de l'administration de Hub. Pour obtenir des informations détaillées concernant les administrateurs de spoke, consultez la section Présentation de l'administration de Spoke.
Connectivité VPC avec filtres d'exportation
Network Connectivity Center vous permet de limiter la connectivité de tous les spokes de réseaux VPC à un sous-ensemble de sous-réseaux dans le VPC du spoke. Vous pouvez empêcher l'annonce d'une plage d'adresses IP à l'aide de l'option exclude-export-ranges dans Google Cloud CLI ou du champ excludeExportRanges dans l'API. Tous les sous-réseaux correspondant à la plage spécifiée sont exclus de l'exportation vers le hub. Ce filtrage est utile lorsque vous disposez de sous-réseaux qui doivent être privés dans le réseau VPC ou qui sont susceptibles de chevaucher d'autres sous-réseaux de la table de routage du hub.
Topologies prédéfinies
Network Connectivity Center vous permet de spécifier la configuration de connectivité souhaitée sur tous les spokes VPC. Vous pouvez choisir l'une des deux topologies prédéfinies suivantes:
- Topologie maillée
- Topologie en étoile
Lorsque vous créez un hub à l'aide de la commande gcloud network-connectivity hubs create, choisissez la topologie maillée ou en étoile prédéfinie. Si la topologie n'est pas spécifiée, elle est définie par défaut sur "Mesh". Une fois définie lors de la création du hub, vous ne pouvez pas modifier la topologie d'un hub donné.
Pour modifier les paramètres de topologie d'un spoke, vous pouvez le supprimer et créer un spoke avec un nouveau hub qui utilise une topologie différente.
Topologie maillée
La topologie en maillage fournit une connectivité réseau à grande échelle entre les spokes VPC.
Cette topologie permet à tous les spokes de se connecter et de communiquer entre eux. Les sous-réseaux de ces spokes VPC sont entièrement accessibles, sauf si vous spécifiez exclude export filters.
Par défaut, lorsque deux ou plusieurs réseaux VPC sont configurés pour joindre un hub Network Connectivity Center en tant que spokes, Network Connectivity Center crée automatiquement un maillage complet de connectivité entre chaque spoke.
Tous les spokes de la topologie du réseau maillé appartiennent à un seul groupe par défaut. La topologie maillée est compatible avec les types de spokes VPC et hybrides.
Le schéma suivant illustre la connectivité de la topologie de maillage dans Network Connectivity Center.
Topologie en étoile
La topologie en étoile n'est compatible qu'avec les spokes VPC. Lorsque vous utilisez la topologie en étoile pour la connectivité, les spokes périphériques et leurs sous-réseaux associés n'atteignent que les spokes centres désignés, tandis que les spokes centres peuvent atteindre tous les autres spokes. Cela permet d'assurer la séparation de la segmentation et de la connectivité entre les réseaux VPC périphériques.
Les spokes VPC pouvant être associés à un hub dans un autre projet, ils peuvent provenir de différents domaines administratifs. Ces spokes situés dans un projet différent du hub peuvent ne pas avoir besoin de communiquer avec tous les autres spokes du hub Network Connectivity Center.
Vous pouvez choisir une topologie en étoile pour le cas d'utilisation suivant :
- Charges de travail exécutées dans différents réseaux VPC qui n'ont pas besoin de connectivité entre eux, mais qui ont besoin d'accéder aux réseaux sur site via le réseau VPC de services partagés central.
Le schéma suivant illustre la connectivité de la topologie en étoile dans Network Connectivity Center.
center-vpc-a et center-vpc-b sont associés au groupe central, et edge-vpc-c et edge-vpc-d sont associés au groupe périphérique. Dans ce cas, l'utilisation d'une topologie en étoile permet à edge-vpc-c et edge-vpc-d d'être connectés à center-vpc-a et center-vpc-b, et de propager leurs sous-réseaux au groupe central, mais pas d'être connectés entre eux (pas de connectivité directe entre edge-vpc-c et edge-vpc-d). Pendant ce temps, center-vpc-a et center-vpc-b sont connectés entre eux, et à la fois à edge-vpc-c et edge-vpc-d, ce qui permet une connectivité complète des VPC du groupe central aux VPC du groupe périphérique.
Groupes de spokes
Un groupe de spokes est un sous-ensemble de spokes associés à un hub. Pour configurer Network Connectivity Center à l'aide de la topologie en étoile, vous devez séparer tous les spokes VPC en deux groupes différents, également appelés domaines de routage:
- Un groupe de spokes central qui communiquent entre tous les autres spokes connectés au hub.
- Un groupe périphérique de spokes qui ne communiquent qu'avec les spokes appartenant au groupe central
Un spoke VPC ne peut appartenir qu'à un seul groupe à la fois. Les groupes sont créés automatiquement lorsque vous créez un hub.
Un administrateur de hub peut mettre à jour un groupe de spokes à l'aide de la commande gcloud network-connectivity hubs groups update. L'administrateur du hub peut ajouter une liste d'ID ou de numéros de projet afin d'activer l'acceptation automatique des spokes. Lorsque l'acceptation automatique est activée, le spoke du projet d'acceptation automatique est automatiquement connecté au hub, sans qu'il soit nécessaire d'examiner chaque proposition de spoke.
Vous pouvez répertorier les groupes centraux et périphériques en tant que ressources imbriquées pour un hub spécifique à l'aide de la commande gcloud network-connectivity hubs groups list --hub.
Pour les hubs créés avec la topologie de maillage, le résultat renvoie le groupe par défaut.
Pour les hubs créés avec la topologie en étoile, le résultat renvoie des groupes centraux et périphériques.
Pour en savoir plus sur la configuration de la topologie maillée ou en étoile pour vos spokes VPC, consultez la section Configurer un hub.
Limites
Cette section décrit les limites des spokes VPC en général, et lorsqu'ils sont associés à un hub dans un autre projet.
Limites des spokes VPC
- Network Connectivity Center n'est pas compatible avec les réseaux VPC comportant des types de spokes mixtes tels que VPC, VPN, Cloud Interconnect et dispositif de routeur sur le même hub.
- Les réseaux VPC peuvent se connecter les uns aux autres de manière exclusive via le hub Network Connectivity Center ou via l'appairage de réseaux VPC. Vous ne pouvez pas utiliser l'appairage de réseaux VPC entre deux spokes VPC connectés au même hub Network Connectivity Center. Cependant, vous pouvez disposer d'un spoke VPC connecté à Network Connectivity Center qui est appairé via l'appairage de réseaux VPC avec un VPC distinct qui ne fait pas partie de Network Connectivity Center.
- Les VPC connectés à l'aide de Network Connectivity Center et de l'appairage de réseaux VPC dans une combinaison ne sont pas transitifs.
- L'échange de routes statiques et dynamiques IPv4 entre les spokes VPC n'est pas accepté.
- Les routes pointant vers des adresses IP virtuelles d'équilibreur de charge réseau passthrough interne dans d'autres spokes VPC ne sont pas acceptées.
- Les sous-réseaux qui se chevauchent doivent être masqués par des filtres d'exportation.
- Vous pouvez spécifier au maximum 16 filtres
exclude export rangespar spoke. - La mise à jour de
exclude export rangesaprès la création du spoke VPC n'est plus possible. - Pour un spoke dans un projet différent du hub, lorsqu'un nouveau périmètre VPC Service Controls est ajouté, vous ne pouvez pas ajouter de spokes qui ne respectent pas le périmètre, mais les spokes existants continuent de fonctionner.
- La connectivité de topologie en étoile n'est compatible qu'avec les spokes VPC.
Exigences de période d'attente après la suppression d'un spoke VPC
Cette section répertorie la période d'attente entre la suppression d'un spoke VPC et la création d'un spoke pour le même VPC. Si la période d'attente n'est pas autorisée, la nouvelle configuration peut ne pas prendre effet.
- Après avoir supprimé un spoke, vous devez respecter une période d'attente d'au moins 10 minutes avant de créer un spoke pour le même réseau VPC associé au même hub.
- Pour un nouveau spoke pour le même réseau VPC associé à un autre hub, la période d'attente à respecter est d'au moins 24 heures.
- Il est possible que les filtres de création d'un spoke pour le même réseau VPC ne soient pas appliqués correctement. La solution consiste à supprimer le spoke, à attendre un délai plus long, puis à recréer le spoke.
Quotas et limites
Pour en savoir plus sur les quotas et limites applicables à Network Connectivity Center, consultez la page Quotas et limites.
Facturation
Heures spoke
Les heures spoke sont facturées en fonction du projet dans lequel réside la ressource de spoke et suit les tarifs des heures de spoke standards. Les heures spoke ne sont facturées que lorsque le spoke est à l'état ACTIVE.
Trafic sortant
Le trafic de sortie est facturé dans le projet de la ressource spoke d'où provient le trafic. Le prix est le même, que le trafic dépasse les limites du projet ou non.
Contrat de niveau de service
Pour en savoir plus sur le contrat de niveau de service de Network Connectivity Center, consultez le Contrat de niveau de service de Network Connectivity Center.
Tarifs
Pour en savoir plus sur les tarifs, consultez la page Tarifs du Network Connectivity Center.
Étapes suivantes
- Apprenez à créer des hubs et des spokes en consultant la section Utiliser des hubs et des spokes.
- Pour afficher la liste des partenaires dont les solutions sont intégrées à Network Connectivity Center, consultez la page Partenaires Network Connectivity Center.
- Pour trouver des solutions aux problèmes courants, consultez la page Dépannage.
- Pour obtenir des détails sur les commandes de l'API et
gcloud, consultez la section API et documentation de référence.