Consideraciones de diseño para las nubes privadas de la Solución de VMware de Azure de generación 2

En este artículo se describen las consideraciones clave de diseño para las nubes privadas de Azure VMware Solution Generación 2 (Gen 2). Explica las funcionalidades que esta generación aporta a entornos de nube privada basados en VMware, lo que permite el acceso a las aplicaciones desde la infraestructura local y los recursos basados en Azure. Hay varias consideraciones que debe revisar antes de configurar la nube privada de Azure VMware Solution Gen 2. En este artículo se proporcionan soluciones para casos de uso que puede encontrar al usar el tipo de nube privada.

Nota:

La generación 2 está disponible en regiones específicas Azure públicas. Póngase en contacto con el equipo de la cuenta de Microsoft o Soporte técnico de Microsoft para confirmar la cobertura.

Limitaciones

La funcionalidad siguiente está limitada durante este tiempo. Estas limitaciones se levantarán en el futuro:

  • No puede eliminar el grupo de recursos, que contiene la nube privada. Primero debe eliminar la nube privada antes de eliminar el grupo de recursos.
  • Solo puede implementar 1 nube privada por red virtual de Azure.
  • Solo puede crear 1 nube privada por grupo de recursos. No se admiten varias nubes privadas en un único grupo de recursos.
  • La nube privada y la red virtual de la nube privada deben estar en el mismo grupo de recursos.
  • No puede mover la nube privada de un grupo de recursos a otro una vez que esta se haya creado.
  • No puede mover la nube privada de un grupo de inquilino a otro una vez que esta se haya creado.
  • Si necesita ExpressRoute FastPath o Global Virtual Network Peering para la nube privada de AVS, cree un caso de soporte técnico a través del portal de Azure.
  • La conectividad directa desde las cargas de trabajo de Azure VMware Solution no es compatible con Service Endpoints.
  • Puntos de conexión privados, cuando están emparejados globalmente entre regiones conectadas a Azure VMware Solution, no se admiten.
  • Se admite el Director de vCloud a través de puntos de conexión privados. Sin embargo, vCloud Director con puntos de conexión públicos no está soportado.
  • No se admiten clústeres extendidos de vSAN.
  • No se admite la dirección IP pública a VMware NSX Microsoft Edge para configurar el acceso a Internet. Puede encontrar qué opciones de Internet se admiten en las Opciones de conectividad a Internet.
  • Durante el mantenimiento no planeado, como un fallo de hardware en un host, en cualquiera de los cuatro primeros hosts de su centro de datos definido por software (SDDC), es posible que se produzca una interrupción temporal de la conectividad de red norte-sur para algunas cargas de trabajo, con una duración de hasta 30 segundos. Conectividad Norte-Sur hace referencia al tráfico entre las cargas de trabajo de AVS VMware y los puntos de conexión externos más allá del perímetro de nivel 0 (T0) de NSX-T, como servicios de Azure o entornos locales. Esta limitación se quitó en regiones específicas de Azure. Confirme si la región se ve afectada por esta limitación comprobando con Azure soporte técnico.  
  • Los grupos de seguridad de red asociados a la red virtual de host de nube privada deben crearse en el mismo grupo de recursos que la nube privada y su red virtual.
  • Las referencias entre grupos de recursos y entre suscripciones desde las redes virtuales del cliente a la red virtual de Azure VMware Solution no se admiten de forma predeterminada. Esto incluye tipos de recursos como: rutas definidas por el usuario (UDR), planes de DDoS Protection y otros recursos de red vinculados. Si una red virtual del cliente está asociada a una de estas referencias que reside en un grupo de recursos o en una suscripción diferente de la red virtual de Azure VMware Solution, la programación de red, como la propagación del segmento NSX, puede fallar. Para evitar problemas, los clientes deben asegurarse de que la red virtual Azure VMware Solution no está conectada a recursos de otro grupo de recursos o suscripción. Antes de continuar, quite las conexiones de este tipo, como los planes de protección contra DDoS, de la red virtual.
    • Para mantener la referencia entre grupos de recursos, cree una asignación de roles a partir del grupo de recursos o la suscripción y asigne a "AzS VIS Prod App" el rol "AVS on Fleet VIS". La asignación de roles le permite usar la referencia y hacer que la referencia se aplique correctamente a la nube privada de Azure VMware Solution.
  • Las implementaciones de nube privada Gen 2 pueden fallar si las directivas de Azure aplican reglas estrictas para grupos de seguridad de red o tablas de rutas (por ejemplo, convenciones de nomenclatura específicas) . Estas restricciones de directiva pueden bloquear el grupo de seguridad de red de Azure VMware Solution necesario y la creación de tablas de rutas durante la implementación. Debe quitar estas directivas de la red virtual Azure VMware Solution antes de implementar la nube privada. Una vez implementada la nube privada, estas directivas se pueden volver a agregar a la nube privada de Azure VMware Solution.
  • Si usa DNS privado para la nube privada de Azure VMware Solution Gen 2, no se admite usar Custom DNS en la red virtual donde se implementa una nube privada de Azure VMware Solution Gen 2. DNS personalizado interrumpe las operaciones de ciclo de vida, como el escalado, las actualizaciones y la aplicación de revisiones.
  • Si está eliminando su nube privada y algunos recursos creados por Azure VMware Solution no se eliminan, puede volver a intentar la eliminación de la nube privada de Azure VMware Solution mediante la CLI de Azure.
  • Azure VMware Solution Gen 2 usa un proxy HTTP para distinguir entre el tráfico de red de administración y el cliente. Es posible que determinados puntos de conexión de servicio en la nube de VMware no sigan la misma ruta de acceso de red o reglas de proxy que el tráfico administrado por vCenter general. Algunos ejemplos son: "scapi.vmware" y "apigw.vmware". El proxy VAMI rige el acceso general a Internet saliente (VCSA) de vCenter Server Appliance, pero no todas las interacciones del punto de conexión de servicio fluyen a través de este proxy. Algunas interacciones se originan directamente desde el explorador del usuario o desde los componentes de integración, que en su lugar siguen la configuración de proxy de la estación de trabajo o inician conexiones de forma independiente. Como resultado, el tráfico a los puntos de conexión de servicio en la nube de VMware puede omitir completamente el proxy de VCSA.
  • Las migraciones de HCX RAV y masivas en Gen 2 pueden experimentar un rendimiento más lento debido a las interrupciones durante las fases de sincronización básica y sincronización en línea. Los clientes deben planear ventanas de migración más largas y programar oleadas en consecuencia por ahora. Para cargas de trabajo adecuadas, vMotion ofrece una opción rápida y de baja sobrecarga cuando las condiciones del host y de la red lo permiten.
  • Emparejamiento del HUB virtual (virtual WAN): Para establecer una conexión de emparejamiento entre una red virtual Gen-2 y un HUB virtual (virtual WAN), el HUB virtual debe estar en la misma región que la red virtual Gen-2. Si necesita emparejarse con un centro virtual en otra región, debe crear un caso de soporte técnico a través del portal de Azure.
  • /32 Destino de ruta desde una red virtual (VNET) emparejada: si va a anunciar rutas /32 desde NSX (como rutas HCX MON o rutas de reenviador de DNS) y necesita acceso a ese destino /32 desde una red virtual (VNET) emparejada, debe abrir un caso de soporte en el portal de Azure. La conectividad con el destino /32 funciona correctamente desde la red virtual local.
  • Anuncio de subred de sincronización con el emparejamiento de VNET y la asociación de tabla de rutas de Azure: Azure VMware Solution Gen 2 utiliza dos arquitecturas internas. La arquitectura actual sincroniza tanto las subredes específicas como el espacio de direcciones más amplio de Azure para las rutas de segmentos o subredes de NSX con las redes virtuales de Azure emparejadas. Como resultado, con la arquitectura actual de la generación 2, es posible que tenga que configurar las tablas de rutas de Azure (UDR) con rutas de subredes de segmentos de NSX más específicas, en lugar de usar las rutas generales del espacio de direcciones para los segmentos de cargas de trabajo de Azure VMware Solution.

Integraciones no admitidas

Las siguientes integraciones de la primera parte y de terceros no están disponibles:

  • DR de Zerto

Subredes delegadas y grupos de seguridad de red para Gen 2

Cuando se implementa una nube privada de Azure VMware Solution (AVS) Gen 2, Azure crea automáticamente varias subredes delegadas dentro de la red virtual host de la nube privada. Estas subredes se usan para aislar y proteger los componentes de administración de la nube privada.

Los clientes pueden administrar el acceso a estas subredes mediante grupos de seguridad de red (NSG) que están visibles en el portal de Azure o a través de CLI de Azure/PowerShell. Además de los NSG administrables por el cliente, AVS aplica NSG administrados por el sistema adicionales a interfaces de administración críticas. Estos NSG administrados por el sistema no son visibles ni editables por los clientes y existen para asegurarse de que la nube privada permanece segura de forma predeterminada.

Como parte de la posición de seguridad predeterminada:

  • El acceso a Internet está deshabilitado para la nube privada a menos que el cliente lo habilite explícitamente.
  • Solo se permite el tráfico de administración necesario para acceder a los servicios de la plataforma.

Nota:

Es posible que vea una advertencia en el portal de Azure que indica que determinados puertos parecen estar expuestos a Internet. Esto ocurre porque el portal solo evalúa la configuración del grupo de seguridad de red (NSG) visible para el cliente. Sin embargo, Azure VMware Solution también aplica grupos de seguridad de red administrados por el sistema adicionales que no están visibles en el portal. Estos grupos de seguridad de red administrados por el sistema bloquean el tráfico entrante a menos que el acceso se haya habilitado explícitamente a través de Azure VMware Solution configuración.

Este diseño mantiene el entorno de AVS seguro y separado de forma predeterminada, a la vez que permite a los clientes administrar y ajustar el acceso de red para satisfacer sus necesidades.

Consideraciones sobre el enrutamiento y las subredes

Azure VMware Solution Gen 2 proporciona un entorno de nube privada de VMware accesible para usuarios y aplicaciones desde entornos locales y recursos basados en Azure. La conectividad se entrega a través de redes de Azure estándar. Para habilitar estos servicios se necesitan rangos de direcciones de red y puertos de firewall específicos. Esta sección le ayuda a configurar las redes para que funcionen con Azure VMware Solution.

La nube privada se conecta a la red virtual de Azure mediante redes estándar Azure. Las nubes privadas de Azure VMware Solution Gen 2 requieren como mínimo un bloque de direcciones de red CIDR /22 para las subredes. Esta red complementa sus redes locales, por lo que el bloque de direcciones no debería solaparse con los bloques de direcciones utilizados en otras redes virtuales de sus redes de suscripción y locales. Las redes de administración, vMotion y Replicación se aprovisionan automáticamente dentro de este bloque de direcciones como subredes dentro de la red virtual.

Nota:

Los rangos permitidos para el bloque de direcciones son los espacios de direcciones privados RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), excepto 172.17.0.0/16. La red de replicación no es aplicable a los nodos AV64 y está planeada para el desuso general en una fecha futura.

Evite usar el siguiente esquema IP reservado para el uso de VMware NSX:

  • 169.254.0.0/24: se usa para la red de tránsito interna
  • 169.254.2.0/23: se usa para la red de tránsito entre VRF
  • 100.64.0.0/16: se usa para conectar puertas de enlace T1 y T0 internamente
  • 100.73.x.x: usado por la red de administración de Microsoft

Nota:

La mayoría de las subredes enumeradas en la tabla se mostrarán como subredes dentro de la red virtual Azure. No realice cambios manuales en la configuración de la subred en estos, ya que se administran mediante el plano de control de Azure VMware Solution y las modificaciones podrían tener consecuencias negativas.

El bloque de direcciones de red CIDR de ejemplo /22 10.31.0.0/22 se divide en las siguientes subredes:

Uso de red Subred Descripción Ejemplo
Red NSX de VMware /27 Red de NSX Manager. 10.31.0.0/27
Red vCSA /27 Red de vCenter Server. 10.31.0.32/27
avs-mgmt /27 Los dispositivos de administración (vCenter Server, NSX Manager y HCX Cloud Manager) están detrás de la subred "avs-mgmt", programada como intervalos IP secundarios en esta subred. Es posible que tenga que ajustar las tablas de rutas asociadas a esta subred si el tráfico de red, para los dispositivos de administración, debe enrutarse a través de una aplicación virtual de red o un firewall. 10.31.0.64/27
avs-vnet-sync /27 Usado por Azure VMware Solution Gen 2 para programar rutas creadas en VMware NSX en la red virtual. 10.31.0.96/27
avs-services /27 Se utiliza para los servicios de proveedor de Azure VMware Solution Gen 2. También se usa para configurar la resolución DNS privada para la nube privada. 10.31.0.224/27
avs-nsx-gw, avs-nsx-gw-1 /27 Las dos subredes avs-nsx-gw controlan todo el tráfico saliente de Azure VMware Solution a la Virtual Network y más allá. Por lo tanto, las tablas de rutas de Azure (UDR) y los grupos de seguridad de red (NSG) deben aplicarse a estas subredes en todos los casos. En nubes privadas de AVS Gen-2 iniciales, estas subredes también administran el tráfico entrante, con todas las subredes de segmento NSX configuradas como direcciones IP secundarias. En las nubes privadas actuales de AVS Gen-2, se agrega una tercera subred conocida como "avs-network-infra-gw" para controlar todo el tráfico entrante. Ahora, todos los segmentos NSX se asignan a esta subred en lugar de a las subredes avs-nsx-gw. 10.31.0.128/27, 10.31.0.160/27
avs-network-infra-gw /26 Cuando esta subred está presente, controla el tráfico entrante de todas las cargas de trabajo de NSX de la red virtual y la usa la administración de Azure VMware Solution para configurar subredes de segmento NSX como direcciones IP secundarias. Evite asociar ninguna tabla de rutas de Azure a esta subred; en su lugar, use la subred "avs-nsx-gw" para administrar el tráfico saliente de AVS, como el dirigido a Azure Firewall o a dispositivos virtuales de red (NVA) de terceros. 10.31.2.128/26
esx-mgmt-vmk1 /25 vmk1 es la interfaz de administración que usan los clientes para acceder al host. Las direcciones IP de la interfaz vmk1 proceden de estas subredes. Todo el tráfico de vmk1 para todos los hosts procede de este rango de subred. 10.31.1.0/25
esx-vmotion-vmk2 /25 Interfaces VMkernel de vMotion. 10.31.1.128/25
esx-vsan-vmk3 /25 Interfaces VMkernel de vSAN y comunicación entre nodos. 10.31.2.0/25
Reservado /27 Espacio reservado. 10.31.0.128/27
Reservado /27 Espacio reservado. 10.31.0.192/27

Nota:

Para las implementaciones de Azure VMware Solution Gen 2, los clientes ahora deben asignar dos subredes /24 adicionales para la administración y el uplink de HCX, además de los /22 especificados durante la implementación de SDDC. En AVS Gen 2, solo se requieren las subredes de administración y de vínculo superior de HCX. Las redes de replicación y vMotion no son necesarias para AVS Gen 2.

Programación de rutas de NSX hacia la red virtual de Azure

Las rutas NSX de Gen-2 de Azure VMware Solution se integran en Azure utilizando el espacio de direcciones y asignándolas como direcciones IP secundarias en la subred "avs-network-infra-gw", creada por el sistema, lo que permite una conectividad fluida entre Azure y las cargas de trabajo de los clientes de AVS. Cuando NSX Tier-0 anuncia una ruta basada en la configuración del usuario, como la creación de segmentos, la adición de rutas estáticas o el uso de máquinas virtuales HCX MON, el plano de control de Azure VMware Solution comprueba si el prefijo de ruta existe en el espacio de direcciones de la red virtual. Si no es así, crea el espacio de direcciones y agrega el prefijo de ruta como direcciones IP secundarias en la subred "avs-network-infra-gw". Para las rutas anunciadas de Tier-0 /32, como las rutas HCX MON, no se configuran IP secundarias, pero el plano de datos se configura internamente para garantizar la conectividad con destinos /32 en Azure VMware Solution.

Además de la actualización del espacio de direcciones y de las subredes para las rutas de NSX, existe una lógica interna que los clientes deben conocer, especialmente en lo que respecta a la escala admitida cuando se utilizan máscaras de subred más bajas. Para obtener más información sobre el aspecto relacionado con la escalabilidad, consulte Arquitectura de enrutamiento para Azure VMware Solution Gen 2

Asociación de tabla de rutas (UDR) de Azure

Azure VMware Solution Gen-2 incluye dos arquitecturas internas, con ligera variación. Algunas de las nubes privadas de Gen-2 iniciales usan la arquitectura interna inicial. Se actualizan a la arquitectura actual a través del mantenimiento programado, coordinado con el cliente. Sin embargo, hay cambios en el comportamiento con la arquitectura actual, en comparación con la arquitectura inicial, que puede afectar a ciertas consideraciones de diseño de red, como se describe a continuación.

Nube privada de Gen-2 inicial:

  • La VNET de Azure tiene dos subredes base de puerta de enlace denominadas "avs-nsx-gw" y no cuenta con la subred "avs-network-infra-gw", como en la arquitectura actual.
  • Todas las subredes de los segmentos NSX de AVS se configuran en la subred "avs-nsx-gw" como direcciones IPv4 adicionales para conectar Azure con las cargas de trabajo de NSX.
  • La tabla de rutas (UDR) o el NSG de Azure para el tráfico desde AVS hacia la red virtual (VNET) de Azure y más allá (por ejemplo, el entorno local) debe aplicarse a la subred "avs-nsx-gw".

Nube privada de Gen-2 actual:

Asegúrese de tomar nota de este cambio en el comportamiento.

  • Azure VNET mostraría una subred adicional con el prefijo "avs-network-infra-gw", junto con dos subredes base de puerta de enlace con el nombre "avs-nsx-gw", como en la arquitectura inicial.
  • Todas las subredes del segmento NSX de AVS ahora están programadas en esta subred como dirección IPv4 secundaria para conectar Azure a cargas de trabajo de NSX. Esto no cambia la conectividad de red del cliente.
  • El emparejamiento de VNET anuncia tanto el espacio de direcciones como las subredes a la VNET emparejada, a diferencia de la arquitectura inicial o de la sincronización nativa de VNET de Azure, donde solo se sincroniza el espacio de direcciones.

Diagrama que muestra las subredes de puerta de enlace nativas de Gen-2.

Consideraciones de diseño debido a cambios en la arquitectura interna de Gen-2

  • Los clientes observan rutas eficaces adicionales para las subredes de AVS dentro de la red virtual (VNET) emparejada debido a un cambio en el comportamiento de sincronización de los emparejamientos de la red virtual.
  • Si un cliente usa una tabla de rutas (UDR) de Azure para enviar tráfico desde el entorno local a AVS a través de un firewall o una aplicación virtual de red, debe actualizar la UDR para usar rutas de subred NSX específicas en lugar del amplio intervalo de direcciones de supernet usado antes. Esto es necesario para evitar que el tráfico destinado a AVS tome rutas de subred de VNET más específicas, eludiendo el firewall previsto, debido al comportamiento de coincidencia de prefijo más largo del enrutamiento de Azure. De lo contrario, esto puede dar lugar a un enrutamiento asimétrico, lo que puede provocar problemas de conectividad.
  • Sin embargo, la tabla de rutas (UDR) o el NSG de Azure para el tráfico de AVS hacia la VNET de Azure y más allá (por ejemplo, hacia el entorno local) seguirá aplicándose a las subredes "avs-nsx-gw", no a "avs-network-infra-gw". Los clientes no deben usar la tabla de rutas (UDR) en la subred "avs-network-infra-gw", aunque las subredes del segmento NSX estén configuradas allí como direcciones IP secundarias.

Pasos siguientes

  • Last updated on