Routage de l'overlay et de l'edge NSX

La solution VMware sur Google Cloud utilise VMware NSX pour fournir un réseau défini par logiciel (SDN) et une sécurité pour les machines virtuelles (VM) de vos charges de travail VMware Cloud Foundation (VCF). Ce document décrit comment la mise en réseau de superposition NSX interagit avec la sous-couche deGoogle Cloud cloud privé virtuel (VPC) et compare les architectures de routage entre les nœuds NSX Edge et votre réseau VPC.

Présentation de NSX dans Google Cloud

Dans la solution VMware, le réseau VPC Google Cloud fournit la sous-couche physique et virtualisée pour vos hôtes ESXi Bare Metal (instancesCompute Engine z3-highmem-192-highlssd-metal) et vos dispositifs de gestion. VMware NSX se trouve au-dessus de cette sous-couche pour fournir une topologie de réseau abstraite pour vos VM de charge de travail VCF :

  • Encapsulation de superposition Geneve : les hôtes ESXi et les nœuds NSX Edge établissent des interfaces de point de terminaison de transport (TEP) (vmk10 ou vmk3) sur le sous-réseau VPC NSX-TEP dédié. Le trafic des VM de charge de travail est encapsulé dans des paquets Geneve (port UDP 6081) et acheminé entre les TEP hôtes sur le sous-réseau VPC Google Cloudà l'aide d'une unité de transmission maximale (MTU) de 8896 octets.
  • Adressage IP dissocié : les VM de charge de travail connectées aux segments d'overlay NSX peuvent utiliser des plages d'adresses IP arbitraires sans consommer d'adresses IP des sous-réseaux VPC Google Cloud sous-jacents ni atteindre les quotas d'adresses IP des sous-réseaux VPC.
  • Architecture de routage multiniveau :
    • Passerelles de niveau 1 (T1) : fournissent un routage est-ouest entre les segments de superposition, les services DHCP localisés et les règles de pare-feu de passerelle.
    • Passerelles de niveau 0 (T0) : fournissent un routage nord-sud entre l'environnement d'overlay NSX et le réseau VPC Google Cloud sous-jacent.
  • Sécurité distribuée : le pare-feu distribué NSX (DFW) applique des règles de microsegmentation avec état directement au niveau de la carte d'interface réseau virtuelle (vNIC) de chaque VM de charge de travail, quel que soit le segment de superposition ou l'hôte ESXi sur lequel réside la VM.

Topologie de sous-couche et de superposition

L'architecture réseau est divisée en deux couches distinctes : la sous-couche VPC Google Cloud et la surcouche VMware NSX, comme illustré dans le diagramme suivant (cliquez pour agrandir) :

Sous-couche VPCGoogle Cloud hébergeant des instances Z3 et des appareils VCF sous la surcouche VMware NSX. Sous-couche VPCGoogle Cloud hébergeant des instances Z3 et des appliances VCF sous la surcouche VMware NSX.

Le tableau suivant récapitule les composants et les responsabilités de chaque couche réseau :

Couche réseau Composants principaux Responsabilités
Google Cloud Sous-couche VPC
  • Hôtes ESXi bare metal (cartes d'interface réseau principales et cartes d'interface réseau dynamiques)
  • VM de gestion VCF (vCenter Server, SDDC Manager, cluster NSX Manager, VMware HCX)
  • Sous-réseaux VPC (Management, vSAN, vMotion, NSX-TEP, NSX-Uplink)
  • Équilibreurs de charge internes régionaux et appliances de routeur Network Connectivity Center
  • Fournit une accessibilité IP entre les ports VMkernel de l'hôte ESXi
  • Héberge les appliances du plan de contrôle VCF directement sur les sous-réseaux VPC
  • Transporter les paquets Geneve encapsulés entre les TEP de l'hôte ESXi et les TEP NSX Edge
  • Connecte les réseaux sur site, les VPC appairés et les servicesGoogle Cloud
Overlay SDN NSX
  • Clusters NSX Edge (routeurs logiques de niveau 0 et de niveau 1)
  • Segments de superposition NSX
  • VM de charge de travail
  • Pare-feu distribué NSX (DFW) et pare-feu de passerelle
  • Fournit des domaines de couche 2 isolés et un routage est-ouest pour les VM de charge de travail
  • Annonce les blocs CIDR de charge de travail au sous-réseau VPC via des passerelles de niveau 0
  • Fournit l'équilibrage de charge, le NAT et la sécurité périphérique nord-sud

Cas d'utilisation d'architecture avancés

Vous pouvez structurer vos topologies NSX et VPC pour répondre à différentes exigences d'isolation et de mutualisation :

  • Domaines de charge de travail consolidés dans un seul VPC : déployez votre domaine de gestion VCF et un ou plusieurs domaines de charge de travail VI dans un seul réseau VPCGoogle Cloud . Chaque domaine de charge de travail utilise des sous-réseaux vSAN, vMotion et NSX-TEP dédiés au sein du même VPC, tout en partageant ou en isolant les clusters NSX Edge pour le routage nord-sud.
  • Mappages multi-VPC : connectez des passerelles NSX de niveau 0 distinctes ou des clusters NSX Edge distincts à des réseaux VPC Google Cloud isolés (par exemple, des VPC distincts pour les charges de travail de production, les réseaux de périmètre et les services partagés). Cette topologie préserve les limites strictes de pare-feu et de routage au niveau du VPC dans Google Cloud , tout en maintenant une gestion centralisée du cycle de vie de VCF.

Routage NSX Edge

Pour acheminer le trafic entre les segments d'overlay NSX et votre réseau VPC Google Cloud , les VM NSX Edge doivent échanger des routes ou transférer des paquets sur le sous-réseau VPCNSX-Uplink. Vous pouvez configurer le routage nord-sud entre les passerelles NSX de niveau 0 et votre réseau VPC à l'aide de l'une des options suivantes :

Option 1 : Routage statique VPC (actif-passif)

Dans une topologie de routage statique, une paire de nœuds NSX Edge actif/passif utilise une adresse IP virtuelle (VIP) flottante sur le sous-réseau VPC NSX-Uplink, précédée d'un équilibreur de charge réseau passthrough interne régional, comme illustré dans le diagramme suivant (cliquez pour l'agrandir) :

Routes statiques VPC dirigeant le trafic de superposition NSX via un équilibreur de charge interne vers des nœuds NSX Edge actifs/en veille. Routes statiques VPC dirigeant le trafic de superposition NSX via un équilibreur de charge interne vers des nœuds NSX Edge actifs/en veille.

  • Mécanisme de routage : vous créez des routes statiques personnalisées dans votre table de routage VPCGoogle Cloud qui spécifient vos blocs CIDR de charge de travail d'overlay NSX comme destination et l'adresse IP virtuelle flottante NSX Edge (ou la règle de transfert de l'équilibreur de charge interne) comme prochain saut.
  • Haute disponibilité : lorsque vous utilisez un service de backend interne régional avec la règle de haute disponibilité GARP_RA (ou un transfert de plage d'adresses IP d'alias), le trafic est automatiquement redirigé vers le nœud NSX Edge de secours en cas de défaillance du nœud Edge actif.
  • Cas d'utilisation : idéal pour les déploiements de petite taille ou les topologies d'overlay statiques où les blocs CIDR de charge de travail ne changent pas fréquemment et où la bande passante d'un seul périphérique Edge répond à vos exigences de débit.

Option 2 : Routage BGP dynamique à l'aide de l'appareil de routeur Network Connectivity Center (actif-actif)

Pour configurer l'échange de routes dynamique et le scaling horizontal de la bande passante, utilisez l'appairage BGP (Border Gateway Protocol) entre votre passerelle NSX de niveau 0 et Cloud Router à l'aide de l'appareil de routeur Network Connectivity Center, comme illustré dans le schéma suivant (cliquez pour agrandir) :

Appairage Cloud Router via BGP avec des appliances de routeur NSX Edge épinglées aux hôtes Z3 par des règles d'affinité DRS. Appairage Cloud Router via BGP avec des appliances de routeur NSX Edge épinglées aux hôtes Z3 par des règles d'affinité DRS.

  • Échange de routes dynamique : la passerelle NSX de niveau 0 annonce automatiquement les blocs CIDR de segment d'overlay NSX nouvellement créés à Cloud Router via BGP, et apprend les routes VPC et sur site (0.0.0.0/0 ou préfixes spécifiques) via des annonces de routage personnalisées. Cette architecture élimine les mises à jour manuelles des routes statiques VPC.
  • Scaling ECMP actif-actif : compatible avec le routage ECMP (Equal-Cost Multi-Path) sur un maximum de huit nœuds NSX Edge actifs par passerelle de niveau 0, scaling du débit nord-sud et compatibilité avec le basculement avec la détection de transfert bidirectionnel (BFD).
  • Exigence d'association Edge-hôte : étant donné qu'une VM NSX Edge s'exécute sur un hôte ESXi, son interface de liaison montante virtuelle est mappée à une carte d'interface réseau dynamique spécifique sur l'instance Compute Engine Bare Metal sous-jacente. Pour vous assurer que Cloud Router transfère le trafic BGP et du plan de données vers l'hôte bare metal exact où réside chaque VM NSX Edge, vous devez configurer des règles d'affinité VMware Distributed Resource Scheduler (DRS) (règles d'affinité VM-Host) pour épingler chaque VM NSX Edge à son hôte ESXi désigné.
  • Sessions BGP redondantes : configurez deux sessions BGP entre les interfaces de liaison montante de chaque nœud NSX Edge sur le sous-réseau NSX-Uplink et les interfaces Cloud Router redondantes pour maintenir la disponibilité continue du plan de contrôle pendant les événements de maintenance de l'hôte.

Étapes suivantes