Descripción general de la arquitectura

En este documento, se proporciona una descripción general de la arquitectura de VMware Solution en Google Cloud.

La solución de VMware ejecuta VMware Cloud Foundation (VCF) 9.1 en instancias completas de Compute Engine dedicadas en tu proyecto de Google Cloud . Las instancias de equipos físicos se conectan directamente a tu red de nube privada virtual (VPC) y usan SSD de NVMe locales para el almacenamiento de VMware vSAN.

En el siguiente diagrama, se muestra la arquitectura de alto nivel de VMware Solution en un proyecto de consumidor y cómo se asigna a una flota de VCF (haz clic para ampliar):

Instancias de equipos físicos Z3 en una red de VPC de proyecto de consumidor asignada a dominios de administración y carga de trabajo de VCF. Instancias de equipos físicos Z3 en una red de VPC de proyecto de consumidor asignada a dominios de administración y carga de trabajo de VCF.

Alineación de los componentes de la infraestructura

La solución de VMware alinea las construcciones de infraestructura de Google Cloud con los componentes de VCF de la siguiente manera:

  • Proyecto de consumidor y red de nube privada virtual (VPC) deGoogle Cloud : Sirve como el límite administrativo de nivel superior que contiene tu red de VPC, subredes, reglas de firewall y recursos de procesamiento.
  • Nodos de Bare Metal y hosts de ESXi: Instancias de Bare Metal dedicadas de Compute Engine (z3-highmem-192-highlssd-metal) equipadas con SSD NVMe locales que ejecutan VMware ESXi.
  • Políticas de posición y clústeres de vSphere: Las políticas de posición distribuida de Compute Engine controlan la distribución física de las instancias dentro de una zona para proteger los clústeres de vSphere contra interrupciones de hardware localizadas.
  • Dominios de disponibilidad y dominios de fallas de vSAN: Son agrupaciones lógicas de recursos dentro de una zona que proporcionan aislamiento de hardware físico y se asignan de forma individual a los dominios de fallas de VMware vSAN.

En la siguiente tabla, se resume el tipo de máquina de Compute Engine de equipos físicos admitido:

Tipo de máquina CPUs virtuales (núcleos físicos) Memoria (GiB) Almacenamiento SSD NVMe local (TiB) Ancho de banda de red
z3-highmem-192-highlssd-metal 192 (96) 1,536 70.31 200 Gbps

Arquitectura de la red

La solución de VMware implementa hosts de equipos físicos y dispositivos de administración directamente en tu red de VPC, como se muestra en el siguiente diagrama (haz clic para ampliarlo):

Zonas de Cloud DNS, balanceadores de cargas internos regionales, NEG zonales y subredes de capa 2 que conectan hosts de Z3. Zonas de Cloud DNS, balanceadores de cargas internos regionales, NEG zonales y subredes de capa 2 que conectan hosts de Z3.

Asignación de interfaces y redes de VPC subyacentes

Las redes subyacentes asignan interfaces físicas y virtuales entre Compute Engine y VMware ESXi de la siguiente manera:

  • Asignación de interfaz de hardware a virtual: Cada host de Bare Metal se conecta a través de una interfaz de red de 200 Gbps. Compute Engine presenta esta interfaz a ESXi como una interfaz de red virtual principal (nic0) para el tráfico de administración sin etiquetar y las subinterfaces dinámicas (nic0.2, nic0.3, nic0.4 y las interfaces de VLAN adicionales) para el tráfico etiquetado con VLAN 802.1Q.
  • Segmentación del tráfico: El conmutador distribuido virtual (VDS) de VMware separa los puertos de VMkernel en subredes de VPC regionales dedicadas, incluidas vmk0 para la administración, vmk1 para vMotion, vmk2 para el almacenamiento de vSAN y vmk10 (o vmk3) para los extremos de túnel (TEP) de NSX.
  • Emulación de capa 2 y aprendizaje dinámico de MAC: Las subredes de VPC designadas interceptan las tramas del protocolo de resolución de direcciones (ARP) y del ARP injustificado (GARP). Esta capacidad programa el plano de datos de Andromeda de Google Cloud para aprender de forma dinámica las direcciones MAC de VMware y emular dominios de transmisión de capa 2 en todas las instancias.

Para obtener más información, consulta Herramientas de redes de VPC subyacentes, aprendizaje de MAC de capa 2 y DNS.

Balanceo de cargas de alta disponibilidad para dispositivos de VCF

Los dispositivos virtuales de administración se ejecutan en la red de VPC subyacente y usan el balanceo de cargas de Google Cloud para obtener alta disponibilidad:

  • Implementación de dispositivos de capa 3: Los dispositivos de administración que requieren acceso directo a la VPC, como vCenter Server, SDDC Manager y los nodos de NSX Manager agrupados en clústeres, residen directamente en las subredes de VPC subyacentes.
  • Cambio rápido de IP (GARP_RA): Debido a que una red de VPC enrutada no depende del aprendizaje de MAC de conmutador físico, la solución de VMware usa balanceadores de cargas de red de transferencia internos regionales y servicios de backend regionales para admitir la movilidad y la conmutación por error de vMotion. Cuando un dispositivo de administración migra o conmuta por error a otro host de ESXi, el dispositivo emite una trama de GARP y el balanceador de cargas dirige de inmediato el tráfico de IP virtual (VIP) a la interfaz del host de destino.

Para obtener más información, consulta Balanceo de cargas de alta disponibilidad para dispositivos de VCF.

Arquitectura de superposición y enrutamiento norte-sur

VMware NSX administra las redes de cargas de trabajo y se conecta a la red subyacente de VPC con uno de los dos modelos de enrutamiento:

  • Estructura de superposición desacoplada: VMware NSX abstrae las redes de cargas de trabajo encapsulando el tráfico de las VM invitadas en marcos de Geneve en los TEP de los hosts. Esta encapsulación desvincula los espacios de direcciones IP de las cargas de trabajo y las políticas de firewall distribuido (DFW) de la infraestructura de VPC.
  • Enrutamiento de VPC estático (activo-en espera): Las rutas estáticas de VPC dirigen los rangos CIDR de la carga de trabajo de superposición a una VIP flotante compartida que se encuentra frente a un balanceador de cargas de red de transferencia interno regional.
  • Enrutamiento dinámico de BGP con Network Connectivity Center (activo-activo): Hasta ocho nodos perimetrales de nivel 0 de NSX establecen sesiones de intercambio de tráfico de BGP externo (eBGP) con instancias de Cloud Router mediante el modelo de dispositivo de router de Network Connectivity Center. Este diseño admite el enrutamiento de ruta múltiple de igual costo (ECMP) y el intercambio automático de prefijos.

Para obtener más información, consulta Enrutamiento perimetral y de superposición de NSX.

Arquitectura de almacenamiento

Las instancias de equipos físicos de Compute Engine incluyen SSD de NVMe locales conectados directamente que sirven como almacenamiento físico para tu infraestructura hiperconvergente. Cada host de z3-highmem-192-highlssd-metal proporciona almacenamiento SSD NVMe local dedicado directamente a VMware ESXi.

Usas VMware vSAN Express Storage Architecture (ESA) como tu plataforma de almacenamiento hiperconvergente principal. vSAN ESA está optimizada para dispositivos flash NVMe locales y admite compresión, encriptación y codificación de borrado RAID-5/RAID-6. Además, los dominios de fallas de vSAN se asignan de forma individual a los dominios de disponibilidad de Google Cloud en tu política de posición para mantener el aislamiento de fallas físicas en todo el clúster.

Almacenamiento de archivos y en bloque complementario

Para escalar la capacidad de almacenamiento de forma independiente sin agregar nodos de procesamiento de equipos físicos, puedes conectar tu entorno a Google Cloud NetApp Volumes de la siguiente manera:

  • Almacenes de datos de NFS: Activa los volúmenes de NFS de NetApp Volumes como almacenes de datos de vSphere complementarios con compatibilidad con instantáneas, clonación y replicación de volúmenes.
  • Almacenamiento en bloque de iSCSI: Conecta los LUN de iSCSI de NetApp Volumes para los sistemas operativos invitados y las extensiones de almacenamiento de cargas de trabajo con la ruta múltiple en tu red de VPC.

¿Qué sigue?