VLANs y subredes en VMware Engine

VMware Engine de Google Cloud crea una red por región en la que se implementa tu servicio de VMware Engine. La red es un espacio de direcciones de capa 3 TCP único con el enrutamiento habilitado de forma predeterminada. Todas las nubes privadas y subredes creadas en esta región pueden comunicarse entre sí sin necesidad de realizar ninguna configuración adicional. Puedes crear segmentos de red (subredes) con NSX para tus máquinas virtuales de carga de trabajo.

VLANs y subredes.

VLANs de gestión

Google crea una VLAN (red de capa 2) para cada nube privada. El tráfico de la capa 2 permanece dentro del límite de una nube privada, lo que te permite aislar el tráfico local dentro de la nube privada. Estas VLANs se usan para la red de gestión. En el caso de las máquinas virtuales de carga de trabajo, debes crear segmentos de red en NSX Manager para tu nube privada.

Subredes

Debes crear un segmento de red en el gestor de NSX de tu nube privada. Se asigna un único espacio de direcciones de capa 3 privado por cliente y región. Puedes configurar cualquier intervalo de direcciones IP que no se solape con otras redes de tu nube privada, tu red local, tu red de gestión de nube privada o los intervalos de direcciones IP de subred de tu red de nube privada virtual (VPC). Para obtener un desglose detallado de cómo asigna VMware Engine los intervalos de direcciones IP de subredes, consulta los requisitos de red.

Todas las subredes pueden comunicarse entre sí de forma predeterminada, lo que reduce la sobrecarga de configuración del enrutamiento entre nubes privadas. Los datos de este a oeste entre nubes privadas de la misma región permanecen en la misma red de capa 3 y se transfieren a través de la infraestructura de red local de la región. No se requiere salida para la comunicación entre nubes privadas de una región. Este enfoque elimina cualquier penalización de rendimiento de WAN o de salida al implementar diferentes cargas de trabajo en distintas nubes privadas del mismo proyecto.

Subredes de gestión creadas en una nube privada

Cuando creas una nube privada, VMware Engine crea las siguientes subredes de gestión:

  • Gestión del sistema: VLAN y subred de la red de gestión de los hosts ESXi, servidor DNS y vCenter Server
  • VMotion: VLAN y subred de la red de vMotion de los hosts ESXi
  • vSAN: VLAN y subred para la red vSAN de los hosts ESXi
  • NsxtEdgeUplink1: VLAN y subred para enlaces ascendentes de VLAN a una red externa
  • NsxtEdgeUplink2: VLAN y subred para enlaces ascendentes de VLAN a una red externa
  • HCXUplink: lo usan los dispositivos de HCX IX (movilidad) y NE (extensión) para comunicarse con sus iguales y permitir la creación de la malla de servicios de HCX.
  • NsxtHostTransport: VLAN y subred de la zona de transporte del host

Intervalo CIDR de red de despliegue de HCX

Cuando creas una nube privada en VMware Engine, VMware Engine instala automáticamente HCX en la nube privada. Ya no es necesario especificar un intervalo CIDR dedicado para los componentes de HCX. En su lugar, VMware Engine asigna automáticamente el espacio de red necesario para los componentes de HCX (como HCX Manager, vMotion y WAN Uplink) a partir del intervalo CIDR de gestión que especifiques para tu nube privada.

Subredes de servicio

Cuando creas una nube privada, VMware Engine crea automáticamente subredes de servicio adicionales. Puedes orientar las subredes de servicio a escenarios de implementación de servicios o dispositivos, como almacenamiento, copias de seguridad, recuperación tras desastres, streaming de contenido multimedia y proporcionar un rendimiento lineal de alta escala y procesamiento de paquetes incluso para las nubes privadas de mayor tamaño. Los nombres de las subredes de servicio son los siguientes:

  • service-1
  • service-2
  • service-3
  • service-4
  • service-5

La comunicación entre máquinas virtuales a través de una subred de servicio sale del host VMware ESXi directamente a la infraestructura de red Google Cloud , lo que permite una comunicación de alta velocidad.

Configurar subredes de servicio

Cuando VMware Engine crea una subred de servicio, no asigna un intervalo ni un prefijo CIDR. Debes especificar un intervalo y un prefijo de CIDR que no se solapen. La primera dirección utilizable se convertirá en la dirección de la pasarela. Para asignar un intervalo y un prefijo CIDR, edita una de las subredes de servicio.

Las subredes de servicio se pueden actualizar si cambian los requisitos de CIDR. Si se modifica el CIDR de una subred de servicio, puede que se interrumpa la disponibilidad de la red para las VMs conectadas a esa subred de servicio.

Configurar grupos de puertos distribuidos de vSphere

Para conectar una VM a una subred de servicio, debe crear un grupo de puertos distribuidos. Este grupo asigna el ID de subred de servicio a un nombre de red en una nube privada de vCenter.

Para ello, vaya a la sección de configuración de la red de la interfaz de vCenter, seleccione Datacenter-dvs y, a continuación, New Distributed Port Group (Nuevo grupo de puertos distribuidos).

Una vez creado el grupo de puertos distribuidos, puede asociar máquinas virtuales seleccionando el nombre correspondiente en la configuración de red de las propiedades de la máquina virtual.

Estos son los valores de configuración críticos de los grupos de puertos distribuidos:

  • Enlace de puertos: enlace estático
  • Asignación de puertos: elástica
  • Número de puertos: 120
  • Tipo de VLAN: VLAN
  • ID de VLAN: el ID de subred correspondiente en la sección de subredes de la interfaz de VMware Engine de Google Cloud

La unidad de transmisión máxima (MTU) es el tamaño, en bytes, del paquete más grande admitido por un protocolo de capa de red, incluidos los encabezados y los datos. Para evitar problemas relacionados con la fragmentación, te recomendamos que uses los siguientes ajustes de MTU:

  • En el caso de las VMs que solo se comunican con otros endpoints de una nube privada estándar, puedes usar ajustes de MTU de hasta 8800 bytes.

  • En el caso de las máquinas virtuales que solo se comunican con otros endpoints de una nube privada extendida, puedes usar ajustes de MTU de hasta 8600 bytes.

  • En las VMs que se comunican con una nube privada sin encapsulación, usa el ajuste de MTU estándar de 1500 bytes. Esta configuración predeterminada común es válida para las interfaces de VM que envían tráfico de las siguientes formas:

    • De una máquina virtual en una nube privada a una máquina virtual en otra nube privada
    • De un endpoint local a una nube privada
    • De una VM en una nube privada a un endpoint local
    • De Internet a una nube privada
    • De una VM en una nube privada a Internet

  • En el caso de las VMs que se comunican con Internet o desde Internet con flujos de tráfico UDP de paquetes grandes que son sensibles a la fragmentación, utiliza un ajuste de MTU de 1370 bytes o inferior. Esta recomendación se aplica a las comunicaciones que usan conexiones públicas o direcciones IP proporcionadas por VMware Engine. El ajuste de MSS suele resolver los problemas de fragmentación con los flujos de tráfico basados en TCP.

  • En el caso de las VMs que se comunican con una nube privada con encapsulación, calcula el mejor ajuste de MTU en función de las configuraciones de los endpoints de VPN. Por lo general, esto da como resultado un ajuste de MTU de entre 1350 y 1390 bytes, o inferior, para las interfaces de las VMs que envían tráfico de las siguientes formas:

    • De un endpoint local a una nube privada con encapsulación
    • De una máquina virtual de una nube privada a un endpoint local con encapsulación
    • De una máquina virtual de una nube privada a otra máquina virtual de otra nube privada con encapsulación

Estas recomendaciones son especialmente importantes en los casos en los que una aplicación no puede controlar el tamaño máximo de la carga útil. Para obtener más información sobre cómo calcular la sobrecarga de encapsulación, consulta los siguientes recursos: