Présentation de l'architecture

Ce document fournit une présentation de l'architecture de la solution VMware sur Google Cloud.

La solution VMware exécute VMware Cloud Foundation (VCF) 9.1 sur des instances Bare Metal Compute Engine dédiées dans votre projet Google Cloud . Les instances Bare Metal se connectent directement à votre réseau cloud privé virtuel (VPC) et utilisent des disques SSD NVMe locaux pour le stockage VMware vSAN.

Le diagramme suivant montre l'architecture de haut niveau de la solution VMware dans un projet client et comment elle est mappée à un parc VCF (cliquez pour agrandir) :

Alignement des composants d'infrastructure

La solution VMware aligne les constructions d'infrastructure Google Cloud avec les composants VCF comme suit :

• Google Cloud Projet client et réseau de cloud privé virtuel (VPC) : sert de limite administrative de premier niveau contenant votre réseau VPC, vos sous-réseaux, vos règles de pare-feu et vos ressources de calcul.
• Nœuds Bare Metal et hôtes ESXi : instances Bare Metal Compute Engine dédiées (z3-highmem-192-highlssd-metal) équipées de disques SSD NVMe locaux exécutant VMware ESXi.
• Stratégies d'emplacement et clusters vSphere : les stratégies d'emplacement par répartition de Compute Engine contrôlent la distribution physique des instances au sein d'une zone pour protéger les clusters vSphere contre les perturbations matérielles localisées.
• Domaines de disponibilité et domaines d'erreur vSAN : regroupements de ressources logiques au sein d'une zone qui fournissent une isolation matérielle physique et correspondent à un mappage 1:1 avec les domaines d'erreur VMware vSAN.

Le tableau suivant récapitule le type de machine Bare Metal Compute Engine compatible :

Type de machine	vCPU (cœurs physiques)	Mémoire (Gio)	Stockage SSD NVMe local (Tio)	Bande passante réseau
z3-highmem-192-highlssd-metal	192 (96)	1 536	70,31	200 Gbit/s

Architecture de réseau

La solution VMware déploie des hôtes bare metal et des dispositifs de gestion directement dans votre réseau VPC, comme illustré dans le schéma suivant (cliquez pour l'agrandir) :

Mise en réseau VPC sous-jacente et mappage d'interface

La mise en réseau sous-jacente mappe les interfaces physiques et virtuelles entre Compute Engine et VMware ESXi comme suit :

• Mappage d'interface matérielle à virtuelle : chaque hôte Bare Metal se connecte via une interface réseau de 200 Gbit/s. Compute Engine présente cette interface à ESXi en tant qu'interface réseau virtuelle principale (nic0) pour le trafic de gestion non tagué et les sous-interfaces dynamiques (nic0.2, nic0.3, nic0.4 et interfaces VLAN supplémentaires) pour le trafic tagué VLAN 802.1Q.
• Segmentation du trafic : le commutateur VMware Virtual Distributed Switch (VDS) sépare les ports VMkernel entre des sous-réseaux VPC régionaux dédiés, y compris vmk0 pour la gestion, vmk1 pour vMotion, vmk2 pour le stockage vSAN et vmk10 (ou vmk3) pour les points de terminaison de tunnel NSX (TEP).
• Émulation de couche 2 et apprentissage MAC dynamique : les sous-réseaux VPC désignés interceptent les trames ARP (Address Resolution Protocol) et GARP (Gratuitous ARP). Cette fonctionnalité programme le plan de données Andromeda Google Cloud pour apprendre de manière dynamique les adresses MAC VMware et émuler les domaines de diffusion de couche 2 entre les instances.

Pour en savoir plus, consultez Mise en réseau VPC sous-jacente, apprentissage MAC de couche 2 et DNS.

Équilibrage de charge à haute disponibilité pour les appliances VCF

Les dispositifs virtuels de gestion s'exécutent sur le sous-réseau VPC et utilisent l'équilibrage de charge Google Cloudpour la haute disponibilité :

• Déploiement d'appareils de sous-couche de couche 3 : les appareils de gestion qui nécessitent un accès VPC direct, tels que vCenter Server, SDDC Manager et les nœuds NSX Manager en cluster, résident directement sur les sous-réseaux VPC de sous-couche.
• Déplacement d'adresse IP rapide (GARP_RA) : étant donné qu'un réseau VPC routé ne repose pas sur l'apprentissage MAC du commutateur physique, la solution VMware utilise des équilibreurs de charge réseau passthrough internes régionaux et des services de backend régionaux pour assurer la mobilité et le basculement vMotion. Lorsqu'un appareil de gestion migre ou bascule vers un autre hôte ESXi, il émet une trame GARP, et l'équilibreur de charge dirige immédiatement le trafic de l'adresse IP virtuelle (VIP) vers l'interface de l'hôte cible.

Pour en savoir plus, consultez Équilibrage de charge à haute disponibilité pour les appliances VCF.

Architecture d'overlay et routage nord-sud

VMware NSX gère la mise en réseau des charges de travail et se connecte au réseau VPC sous-jacent à l'aide de l'un des deux modèles de routage suivants :

• Structure d'overlay dissociée : VMware NSX extrait la mise en réseau des charges de travail en encapsulant le trafic des VM invitées dans des frames Geneve sur les TEP hôtes. Cette encapsulation dissocie les espaces d'adresses IP des charges de travail et les règles de pare-feu distribué (DFW) de la couche sous-jacente du VPC.
• Routage VPC statique (actif/passif) : les routes statiques VPC dirigent les plages CIDR de la charge de travail de superposition vers une adresse IP virtuelle flottante partagée, précédée d'un équilibreur de charge réseau passthrough interne régional.
• Routage BGP dynamique à l'aide de Network Connectivity Center (actif-actif) : jusqu'à huit nœuds NSX Tier-0 Edge établissent des sessions d'appairage BGP externe (eBGP) avec des instances Cloud Router à l'aide du modèle d'appareil de routeur Network Connectivity Center. Cette conception est compatible avec le routage ECMP (Equal-Cost Multi-Path) et l'échange automatique de préfixes.

Pour en savoir plus, consultez Routage de périphérie et d'overlay NSX.

Architecture de stockage

Les instances Bare Metal Compute Engine incluent des disques SSD NVMe locaux directement associés qui servent de stockage physique pour votre infrastructure hyperconvergée. Chaque hôte z3-highmem-192-highlssd-metal fournit un stockage SSD NVMe local dédié directement à VMware ESXi.

Vous utilisez VMware vSAN Express Storage Architecture (ESA) comme plate-forme de stockage hyperconvergée principale. vSAN ESA est optimisé pour les appareils flash NVMe locaux et est compatible avec la compression, le chiffrement et le codage d'effacement RAID-5/RAID-6. De plus, les domaines de défaillance vSAN sont mappés de manière univoque aux domaines de disponibilité Google Cloud dans votre stratégie d'emplacement afin de maintenir l'isolation des défaillances physiques dans votre cluster.

Stockage de fichiers et de blocs supplémentaire

Pour faire évoluer la capacité de stockage indépendamment sans ajouter de nœuds de calcul Bare Metal, vous pouvez connecter votre environnement à Google Cloud NetApp Volumes comme suit :

• Datastores NFS : installez des volumes NFS NetApp Volumes en tant que datastores vSphere supplémentaires, avec prise en charge des instantanés, du clonage et de la réplication de volumes.
• Stockage de blocs iSCSI : associez des LUN iSCSI NetApp Volumes pour les systèmes d'exploitation invités et les extensions de stockage de charges de travail en utilisant le multipathing sur votre réseau VPC.

Étapes suivantes

• Découvrez la conception de l'interface hôte et du DNS dans Mise en réseau VPC sous-jacente, apprentissage MAC de couche 2 et DNS.
• Découvrez comment l'équilibrage de charge sous-jacent permet la mobilité des appareils dans Équilibrage de charge à haute disponibilité pour les appareils VCF.
• Examinez les topologies de routage d'overlay dans Routage d'overlay et de périphérie NSX.
• Consultez le modèle de responsabilité partagée.