Compartir vía

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 su nube privada de un grupo de recursos a otro una vez creada.
  • No puede mover la nube privada de un inquilino a otro después de crear la nube privada.
  • 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 admitirá la asignación de una dirección IP pública al VMware NSX Microsoft Edge para la configuración de Internet. Puede encontrar qué opciones de Internet se admiten en las Opciones de conectividad a Internet.
  • Durante el mantenimiento no planeado, como un error de hardware de host, en cualquiera de los cuatro primeros hosts del SDDC, puede experimentar una interrupción temporal de la conectividad de red North-South para algunas cargas de trabajo, que dura 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 ha quitado en regiones de Azure específicas. Consulte con Azure soporte técnico para ver si su región se ve afectada por esta limitación.
  • 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 redes virtuales de clientes 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 el Azure VMware Solution red virtual no esté vinculado a recursos de otro grupo de recursos o suscripción y desasociar dichos recursos (por ejemplo, planes de protección contra DDoS) de la red virtual antes de continuar.
    • Para mantener la referencia de grupo de recursos cruzada, cree una asignación de roles desde su grupo de recursos cruzados o suscripción y asigne a "AzS VIS Prod App" el "AVS en Fleet VIS Role". La asignación de roles permite utilizar una referencia y garantiza que esta 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 y la creación de tablas de rutas de Azure VMware Solution 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 está usando DNS privado para su nube privada de Azure VMware Solution Gen 2, no se admite el uso de Custom DNS en la red virtual donde se implementa esta nube privada. DNS personalizado interrumpe las operaciones de ciclo de vida, como el escalado, las actualizaciones y la aplicación de revisiones.
  • Si está eliminando la 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 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 del vCenter Server Appliance (VCSA), pero no todas las interacciones con los puntos finales 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 Bulk en Gen 2 pueden experimentar un rendimiento significativamente más lento debido a las interrupciones durante las fases de Sincronización Base 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.

Integraciones no admitidas

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

  • Recuperación ante desastres 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 garantiza que el entorno de AVS esté aislado y seguro de forma predeterminada, a la vez que permite a los clientes controlar y personalizar el acceso a la red en función de sus requisitos específicos.

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. Azure VMware Solution nubes privadas de la generación 2 requieren un bloque de direcciones de red CIDR /22 mínimo 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

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 Subredes fuera de cada una de las puertas de enlace T0 por perímetro. Estas subredes se usan para programar segmentos de red de VMware NSX como direcciones IP secundarias. 10.31.0.128/27, 10.31.0.160/27
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
avs-network-infra-gw /26 Usado por la administración de Azure VMware Solution para programar segmentos NSX. Los clientes no necesitan modificar esta subred porque solo se usa para Azure VMware Solution infraestructura. Verá que los segmentos de red de NSX se crean como prefijos IP secundarios en esta subred. Sin embargo, los segmentos de carga de trabajo siguen enrutando a través de las subredes avs-nsx-gw-1 y avs-nsx-gw-1. 10.31.2.128/26
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 HCX mgmt y HCX de vínculo superior. Las redes de replicación y vMotion no son necesarias para AVS Gen 2.

Pasos siguientes

  • Last updated on