Herramientas de redes de VPC subyacentes, aprendizaje de MAC de capa 2 y DNS

En este documento, se describe la arquitectura de red de nube privada virtual (VPC) subyacente, la emulación de transmisión de capa 2, la administración de direcciones IP (IPAM) y el sistema de nombres de dominio (DNS) en la solución de VMware en Google Cloud.

En la solución de VMware, las redes a nivel de host asignan interfaces de VMkernel de VMware ESXi a interfaces de red virtuales (vNIC) principales y dinámicas de Compute Engine. Cada host usa subredes de nube privada virtual (VPC) dedicadas, etiquetado de VLAN 802.1Q, aprendizaje de MAC de capa 2 y administración de direcciones IP (IPAM) interna.

Subredes principales y segmentación del tráfico

Para aislar las clases de tráfico de red en VMware Cloud Foundation (VCF), debes aprovisionar subredes subyacentes dedicadas, como se muestra en el siguiente diagrama (haz clic para ampliar):

Asignación de instancias Z3 de puertos VMkernel de ESXi a través de un Virtual Distributed Switch a NIC principales y NIC Dinámicas. Asignación de instancias Z3 de puertos VMkernel de ESXi a través de un Virtual Distributed Switch a NIC principales y NIC Dinámicas.

Un clúster de VCF estándar requiere un mínimo de cuatro subredes de VPC dedicadas, como se muestra en la siguiente tabla:

Clase de subred Tipo de tráfico Asignación de VLAN Objetivo
Administración (MGMT) Control de subyacente Nativo (sin etiquetar) Transporta el tráfico de administración del host ESXi (vmk0) y aloja los nodos de SDDC Manager, vCenter Server y NSX Manager.
vSAN Almacenamiento Etiquetado (por ejemplo, VLAN 2) Transporta el tráfico de replicación de almacenamiento entre las SSD NVMe locales de ESXi (vmk2).
vMotion Migración en vivo Etiquetado (por ejemplo, VLAN 3) Transporta el tráfico de migración en vivo de máquinas virtuales entre hosts ESXi (vmk1).
TEP de NSX TEP de superposición de Geneve Etiquetado (por ejemplo, VLAN 4) Transporta el tráfico de encapsulamiento del túnel de superposición de Geneve de host a host (vmk10).

Configuración de NIC Dinámica y VLAN

Para segmentar varias clases de tráfico en las interfaces de host de equipos físicos, Compute Engine usa NIC dinámicas (subinterfaces virtuales) asociadas con la interfaz de red principal:

  • Interfaz principal (nic0): Se aprovisiona en la subred de administración sin etiquetar. Esta interfaz controla el inicio inicial del host, la interfaz de usuario de la consola directa (DCUI) de ESXi y el tráfico de administración de vmk0.
  • Interfaces dinámicas (nic0.VLAN_ID): Se conectan a la interfaz principal con metadatos --vlan explícitos durante el aprovisionamiento de la instancia y se asignan a las subredes de VPC correspondientes.
  • Alineación del switch distribuido virtual (VDS) de VMware: En el host de ESXi, los grupos de puertos en el VDS se etiquetan con IDs de VLAN 802.1Q coincidentes. Los marcos salientes etiquetados por el hipervisor se asignan directamente a la interfaz dinámica de Compute Engine correspondiente para el reenvío a través de la red de VPC.

Redundancia de red física

Aunque las instancias de Bare Metal de Compute Engine presentan una sola interfaz de red (nic0 o vmnic0) al sistema operativo del host de ESXi, esta interfaz única es una abstracción que proporciona la capa de red definida por software (SDN) de Google Cloud .

En la infraestructura física subyacente, las rutas de red son redundantes y usan conectividad óptica de varias rutas en la estructura de conmutación del centro de datos. Debido a que la capa de transporte físico no depende del hardware de ruta única, no necesitas configurar la formación de equipos de NIC a nivel de hipervisor para la redundancia de ruta física. Si se produce un evento de hardware a nivel de host, la disponibilidad de la carga de trabajo se protege con los flujos de trabajo de alta disponibilidad (HA) de vSphere y de reemplazo de nodos.

Emulación de capa 2: Transmisión de ARP y aprendizaje de MAC personalizado

Las instancias de VM de Compute Engine estándar usan direcciones MAC fijas derivadas de forma algorítmica (42:01:ac:...). En cambio, los hosts de VMware ESXi, los puertos de VMkernel y los dispositivos virtuales generan direcciones MAC personalizadas a partir de los rangos de identificadores únicos de organización (OUI) de VMware (como 00:50:56:... o 00:0c:29:...).

Para admitir direcciones MAC de VMware personalizadas y tráfico de transmisión de invitados de forma nativa, la solución de VMware requiere que las subredes de tu red de VPC tengan la propiedad Resolver máscara de subred configurada en Transmitir solo el rango principal con aprendizaje (--resolve-subnet-mask=ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING) para admitir redes basadas en VLAN. Para incluir la conectividad de red de capa 2 en la lista de entidades permitidas de tu proyecto, abre un ticket de asistencia en el Centro de asistencia de la consola deGoogle Cloud con la siguiente información:

  • Producto: Google Cloud VMware Engine
  • Prioridad: P2
  • Categoría: Conectividad de red
  • Impacto comercial: Pregunta técnica general
  • Proporciona más detalles: Allowlist L2 network connectivity for my project, junto con el ID del proyecto, el número del proyecto y la región y la zona de destino para la implementación

Modos de transmisión de subred

Compute Engine admite los siguientes modos de transmisión de ARP de subred:

  • ARP_BROADCAST_PRIMARY_RANGE: Transmite consultas de ARP y ARP gratuito (GARP) en todas las instancias conectadas a la subred. La instancia propietaria de la dirección IP de destino responde directamente.
  • ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNINGEs obligatorio para la solución de VMware. Además de la transmisión de ARP, Google Cloud aprende y almacena en caché de forma dinámica las asignaciones de IP a MAC personalizadas. Cuando se aprende una asignación, Google Cloud usa la dirección MAC personalizada de VMware como la dirección MAC de destino para el tráfico enviado a esa dirección IP. Si no existe una asignación personalizada para la dirección IP principal de un extremo, Google Cloudrecurre a la dirección MAC predeterminada asignada por Google Cloud. Los paquetes enviados a cualquier otra dirección IP no asignada se descartan.

Métodos de aprendizaje de MAC

Google Cloud propaga y actualiza la caché de direcciones MAC personalizadas con dos mecanismos:

  • ARP injustificado (GARP): Supervisa la subred en busca de anuncios de GARP emitidos por los puertos de VMkernel de ESXi y los dispositivos virtuales que se migran.
  • Sondeo activo: Sondea las direcciones IP en el rango CIDR principal de la subred y usa las respuestas ARP del host para propagar la caché de MAC.

Restricciones y especificaciones

Cuando configuras subredes con transmisión de ARP y aprendizaje de MAC, se aplican las siguientes restricciones:

  • Inmutabilidad: Debes especificar la marca --resolve-subnet-mask cuando creas la subred. No puedes modificar este parámetro de configuración después de crear la subred.
  • Propósito de la subred y versión de IP: Solo se admite en subredes con un propósito PRIVATE y rangos CIDR solo IPv4.
  • Tamaño del rango principal: El aprendizaje de MAC solo se admite en rangos CIDR IPv4 principales de /24 o menos (por ejemplo, /24, /25 o /26). El aprendizaje de MAC no se admite en rangos CIDR secundarios.
  • Cuota de extremos: Las subredes con modos de transmisión habilitados admiten hasta 64 interfaces de red de VM conectadas.
  • Cuota de subredes de transmisión: Cada red de VPC admite hasta 64 subredes con transmisión habilitada por región. No se admiten aumentos de cuota para este límite.
  • Limitación de solicitudes ARP: Las solicitudes ARP y GARP que superan las 16 consultas por segundo (QPS) en una subred de 64 instancias se descartan para mantener la estabilidad de la estructura.
  • Servidor de metadatos y DHCP: No se admiten las solicitudes del protocolo de configuración dinámica de host (DHCP) enviadas desde direcciones MAC personalizadas y se descartan. El servidor de metadatos de Compute Engine solo expone las direcciones MAC asignadas porGoogle Cloudpredeterminadas, no las direcciones MAC aprendidas personalizadas.
  • Instancias de destino: Las instancias de destino no pueden hacer referencia a interfaces de red en subredes habilitadas para la transmisión de ARP.
  • MTU de VPC: Configura la unidad de transmisión máxima (MTU) de tu red de VPC en 8896 bytes y configura tus VDS de VMware, adaptadores de VMkernel y perfiles de NSX para que coincidan con 8896 bytes. Para obtener más información, consulta Problemas conocidos.

Para crear una subred de administración con transmisión de ARP, aprendizaje de MAC y Acceso privado a Google habilitado con Google Cloud CLI, ejecuta el siguiente comando:

gcloud compute networks subnets create SUBNET_NAME \
    --network=VPC_NAME \
    --region=REGION \
    --range=SUBNET_RANGE \
    --resolve-subnet-mask=ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING \
    --enable-private-ip-google-access

Antes de ejecutar el comando, reemplaza lo siguiente:

  • SUBNET_NAME: Es el nombre de la nueva subred de VPC.
  • VPC_NAME: Es el nombre de tu red de VPC de destino.
  • REGION: Es la región de Google Cloud en la que estás creando la subred.
  • SUBNET_RANGE: Es el rango CIDR IPv4 principal de /24 o menor (por ejemplo, 10.200.0.0/24).

Administración de direcciones IP (IPAM)

VMware Solution admite tres métodos de asignación de direcciones IP dentro de tu red de VPC:

  • Efímera (automática): Se alquila de forma dinámica desde el grupo de subredes de VPC y se vincula al ciclo de vida de la instancia de Bare Metal. Nota: Durante la puesta en marcha y la expansión del clúster de VCF, el instalador de VCF ordena y asigna las direcciones IP de vMotion y vSAN de forma secuencial. Prefiere las asignaciones de IP personalizadas o reservadas para mantener un orden predecible de host a IP. Para obtener más información, consulta Problemas conocidos.
  • Efímera (personalizada): Se especifica de forma explícita a partir de direcciones sin asignar en el rango de subred durante el aprovisionamiento de instancias o NIC dinámicas.
  • Direcciones IP estáticas reservadas: Son objetos de dirección IP de VPC asignados que permanecen reservados en tu proyecto, independientemente del estado de la instancia. Usa direcciones IP reservadas para las interfaces de host de ESXi y los dispositivos de administración flotantes (VIP de vCenter Server, SDDC Manager y NSX Manager) para evitar colisiones de direcciones IP durante los eventos de mantenimiento y conmutación por error.

Arquitectura de DNS y resolución de nombres

VCF requiere una resolución de DNS directa (A) y reversa (PTR) para todos los hosts de ESXi sin sistema operativo, los dispositivos virtuales de administración y los extremos del clúster. Los registros DNS de reenvío o inversos faltantes o mal configurados hacen que fallen las verificaciones de validación de certificados y la puesta en marcha de SDDC Manager.

Resolución de DNS de la red subyacente (hosts y dispositivos de administración)

Configura la resolución de DNS para los hosts ESXi de equipos físicos y los dispositivos de administración alojados en la infraestructura subyacente (vCenter Server, SDDC Manager y NSX Manager) de la siguiente manera:

  • Agente de resolución interno de Cloud DNS (169.254.169.254): Los hosts de ESXi subyacentes y las VMs de administración pueden consultar el agente de resolución de DNS de metadatos de Google Cloud (169.254.169.254) para resolver los recursos de Google Cloud y las zonas privadas administradas en Cloud DNS.

  • Políticas de servidor DNS de entrada: Si tu organización usa servidores DNS corporativos centralizados en Cloud Interconnect o Cloud VPN, configura una política de servidor de entrada en Cloud DNS en una subred estándar (no de transmisión de capa 2) dentro de tu VPC. Los nodos de la red subyacente pueden consultar las direcciones IP del reenviador de entrada para resolver los registros de Google Cloud privados y los dominios locales.

  • Zonas inversas (PTR): Crea zonas de búsqueda inversa privadas dedicadas en Cloud DNS (por ejemplo, 0.200.10.in-addr.arpa. para la subred de administración 10.200.0.0/24) de modo que todos los FQDN del host de ESXi y del dispositivo de administración se resuelvan en ambas direcciones.

Resolución de DNS de la VM de invitado de superposición

Las máquinas virtuales de carga de trabajo implementadas en la superposición de NSX residen en redes lógicas encapsuladas en Geneve que están desacopladas de la infraestructura de VPC:

  • Servidores DNS corporativos o políticas de reenvío entrante: Configura las VMs invitadas para que consulten tus servidores DNS empresariales o las direcciones IP estáticas de tu política del servidor entrante de Cloud DNS a la que se puede acceder a través de la puerta de enlace de nivel 0 de NSX.
  • Restricción de dirección de metadatos de vínculo local: Las VMs invitadas en la superposición de NSX no pueden consultar directamente el agente de resolución de metadatos de vínculo local (169.254.169.254) porque las direcciones de vínculo local no se enrutan a través de túneles de superposición de Geneve.

¿Qué sigue?