Topología de red y conectividad para Azure VMware Solution

Al usar un Centro de datos definido por software (SDDC) de VMware con el ecosistema en la nube de Azure, tiene un conjunto único de consideraciones de diseño para seguir para escenarios híbridos y nativos en la nube. En este artículo se proporcionan las principales consideraciones y los procedimientos recomendados para las redes y la conectividad hacia, desde y dentro de Azure y las implementaciones de Azure VMware Solution.

El artículo se basa en varios principios arquitectónicos de zonas de aterrizaje de escala empresarial de Cloud Adoption Framework y recomendaciones para administrar la topología de red y la conectividad a escala. Puede usar esta guía del área de diseño de la zona de aterrizaje de Azure para plataformas críticas de Azure VMware Solution. Entre las áreas de diseño se incluyen:

Recomendaciones y consideraciones generales de diseño

La sección siguiente proporciona algunas consideraciones de diseño generales y recomendaciones para la conectividad y topología de red de Azure VMware Solution.

Topología de red en estrella tipo hub-and-spoke o Virtual WAN

Si no tiene una conexión de ExpressRoute desde el entorno local a Azure y, en su lugar, usa VPN S2S, puede usar Virtual WAN para transitar la conectividad entre la VPN local y ExpressRoute de Azure VMware Solution. Si usa una topología en estrella tipo hub-and-spoke, necesita Azure Route Server. Para más información, consulte Compatibilidad de Azure Route Server con ExpressRoute y VPN de Azure.

Nubes privadas y clústeres

  • Todos los clústeres pueden comunicarse dentro de una nube privada de Azure VMware Solution, ya que todos comparten el mismo espacio de direcciones /22.

  • Todos los clústeres comparten la misma configuración de conectividad, incluidas Internet, ExpressRoute, HCX, IP pública y ExpressRoute Global Reach. Las cargas de trabajo de la aplicación también pueden compartir algunas configuraciones de red básicas, como segmentos de red, protocolo de configuración dinámica de host (DHCP) y configuración del sistema de nombres de dominio (DNS).

  • Diseñe nubes privadas y clústeres de antemano antes de la implementación. El número de nubes privadas que necesita afecta directamente a los requisitos de red. Cada nube privada requiere su propio espacio de direcciones /22 para la administración de la nube privada y el segmento de direcciones IP para las cargas de trabajo de VM. Considere la posibilidad de definir esos espacios de direcciones de antemano.

  • Hable con los equipos de redes y VMware sobre cómo segmentar y distribuir las nubes privadas, los clústeres y los segmentos de red para las cargas de trabajo. Planee bien y evite desperdiciar direcciones IP.

Para obtener más información sobre la administración de direcciones IP para nubes privadas, consulte Definición del segmento de direcciones IP para la administración de nubes privadas.

Para obtener más información sobre la administración de direcciones IP para cargas de trabajo de VM, consulte Definición del segmento de direcciones IP para cargas de trabajo de VM.

DNS y DHCP

Para DHCP, use el servicio DHCP integrado en NSX-T Data Center o un servidor DHCP local en una nube privada. No devuelva el tráfico DHCP de difusión mediante WAN a las redes locales.

Para DNS, en función del escenario que adopte y sus requisitos, tiene múltiples opciones:

  • Para un entorno exclusivamente en Azure VMware Solution, puede implementar una nueva infraestructura de DNS en la nube privada de Azure VMware Solution.
  • Para Azure VMware Solution conectado a un entorno local, puede usar la infraestructura de DNS existente. Si es necesario, implemente reenviadores DNS para extenderlos a Azure Virtual Network o, preferiblemente, a Azure VMware Solution. Para obtener más información, consulte Agregar un servicio de reenviador DNS.
  • Para Azure VMware Solution conectado a entornos y servicios locales y de Azure, puede usar servidores DNS existentes o reenviadores DNS en la red virtual de centro si están disponibles. También puede ampliar la infraestructura DNS local existente a la red virtual de centro de Azure. Para obtener más información, consulte el diagrama de zonas de aterrizaje de escala empresarial.

Para más información, consulte los siguientes artículos.

Internet

Las opciones de salida para habilitar Internet y filtrar e inspeccionar el tráfico incluyen:

  • Azure Virtual Network, NVA y Azure Route Server mediante el acceso a Internet de Azure.
  • Ruta predeterminada local mediante el acceso a Internet local.
  • Centro protegido de Virtual WAN con Azure Firewall o NVA, mediante el acceso a Internet de Azure.

Entre las opciones de entrada para entregar contenido y aplicaciones se incluyen las siguientes:

  • Azure Application Gateway con L7, terminación de Capa de sockets seguros (SSL) y Web Application Firewall.
  • DNAT y equilibrador de carga desde el entorno local.
  • Azure Virtual Network, NVA y Azure Route Server en varios escenarios.
  • Centro protegido de Virtual WAN con Azure Firewall, con L4 y DNAT.
  • Centro protegido de Virtual WAN con NVA en varios escenarios.

ExpressRoute

La implementación de la nube privada integrada de Azure VMware Solution crea automáticamente un circuito ExpressRoute gratuito de 10 Gbps. Este circuito conecta Azure VMware Solution a D-MSEE.

Considere la posibilidad de implementar Azure VMware Solution en regiones emparejadas de Azure cerca de los centros de datos. Revise este artículo para obtener recomendaciones sobre topologías de red de doble región para Azure VMware Solution.

Global Reach

  • Global Reach es un complemento de ExpressRoute necesario para que Azure VMware Solution se comunique con centros de datos locales, Azure Virtual Network y Virtual WAN. La alternativa es diseñar la conectividad de red con Azure Route Server.

  • Puede emparejar el circuito Azure VMware Solution ExpressRoute con otros circuitos de ExpressRoute mediante Global Reach sin cargo alguno.

  • Puede usar Global Reach para emparejar circuitos de ExpressRoute mediante un ISP y para circuitos de ExpressRoute Direct.

  • Global Reach no se admite para los circuitos locales de ExpressRoute. En el caso de ExpressRoute local, el tránsito de Azure VMware Solution a los centros de datos locales se realiza mediante NVA de terceros en una red virtual de Azure.

  • Global Reach no está disponible en todas las ubicaciones.

Ancho de banda

Elija una SKU de puerta de enlace de red virtual para un ancho de banda óptimo entre Azure VMware Solution y Azure Virtual Network. Azure VMware Solution admite un máximo de cuatro circuitos de ExpressRoute a una puerta de enlace de ExpressRoute en una región.

Seguridad de las redes

La seguridad de red implica la inspección del tráfico y la creación de reflejo del puerto.

La inspección del tráfico de este a oeste dentro de un SDDC usa NSX-T Data Center o NVA para inspeccionar el tráfico a Azure Virtual Network entre regiones.

La inspección del tráfico norte-sur inspecciona el flujo de tráfico bidireccional entre Azure VMware Solution y los centros de datos. La inspección del tráfico de norte a sur puede usar:

  • Una NVA de firewall de terceros y Azure Route Server mediante Internet de Azure.
  • Una ruta predeterminada local mediante Internet local.
  • Azure Firewall y Virtual WAN mediante Internet de Azure
  • NSX-T Data Center dentro del SDDC mediante Internet de Azure VMware Solution.
  • Una NVA de firewall de terceros en Azure VMware Solution dentro del SDDC mediante Internet de Azure VMware Solution

Requisitos de puertos y protocolos

Configure todos los puertos necesarios para que un firewall local garantice el acceso adecuado a todos los componentes de la nube privada de Azure VMware Solution. Para obtener más información, consulte Puertos de red necesarios.

Acceso de administración de Azure VMware Solution

  • Considere la posibilidad de usar un host de Azure Bastion en Azure Virtual Network para acceder al entorno de Azure VMware Solution durante la implementación.

  • Una establezca el enrutamiento al entorno local, la red de administración de Azure VMware Solution no respeta las rutas 0.0.0.0/0 de las redes locales, por lo que necesita anunciar rutas más específicas para las redes locales.

Continuidad empresarial, recuperación ante desastres (BCDR) y migraciones

Pasos siguientes