Guía de VMware HCX Mobility Optimized Networking (MON)

Nota:

VMware HCX Mobility Optimized Networking es compatible oficialmente con VMware y Azure VMware Solution desde HCX versión 4.1.0.

Importante

Antes de habilitar HCX MON, lea las siguientes limitaciones y configuraciones no admitidas:

Configuraciones de origen no admitidas para HCX NE

Limitaciones de cualquier implementación de HCX, incluido MON

Las redes optimizadas para movilidad (MON) de VMware HCX no se admiten con el uso de una puerta de enlace de terceros. Solo se puede usar con la puerta de enlace de T1 conectada directamente a la puerta de enlace de T0 sin una aplicación virtual de red (NVA). Es posible que pueda realizar esta función de configuración, pero no se admite.

HCX Mobility Optimized Networking (MON) es una característica opcional que se puede habilitar al usar HCX Network Extension (NE). MON proporciona un enrutamiento óptimo del tráfico en determinados escenarios para evitar el desvío de tráfico entre los recursos locales y los recursos basados en la nube en redes extendidas.

Como MON es una funcionalidad empresarial de la característica NE, asegúrese de habilitar VMware HCX Enterprise a través de Azure Portal.

A lo largo del ciclo de migración, MON optimiza la movilidad de las aplicaciones para lo siguiente:

• Optimizar la comunicación L2 de máquina virtual (VM) a máquina virtual cuando se usan redes extendidas

• Optimizar y prevenir los flujos de tráfico asimétrico entre el entorno local, Azure VMware Solution y Azure

En este artículo, obtenga información sobre los casos de uso específicos de Azure VMware Solution para MON.

Optimización de los flujos de tráfico entre segmentos estándar y extendidos en el lado de la nube privada

En este escenario, VM1 se migra a la nube mediante NE, lo que proporciona una latencia óptima de máquina virtual a máquina virtual. Como resultado, VM1 necesita una latencia baja para VM3 en el segmento local de Azure VMware Solution. Migramos la puerta de enlace VM1 del entorno local a Azure VMware Solution (nube) para garantizar una ruta de acceso óptima para el tráfico (línea azul). Si la puerta de enlace permanece en el entorno local (línea roja), se observa un efecto de desvío de tráfico y una mayor latencia.

Nota:

Habilitar MON sin migrar la puerta de enlace de la máquina virtual al lado de la nube no garantiza una ruta de acceso óptima para el flujo de tráfico. Tampoco permite la evaluación de rutas de directiva.

Optimización y prevención de flujos de tráfico asimétricos

En este escenario, se supone que una máquina virtual del entorno local se migra a Azure VMware Solution y participa en el tráfico L2 y el tráfico L3 vuelve a estar en el entorno local para acceder a los servicios. También se supone que algunas comunicaciones de máquina virtual de Azure (en la red virtual conectada a Azure VMware Solution) podrían llegar a la nube privada de Azure VMware Solution.

Importante

La cuestión principal aquí es planear y evitar cuidadosamente los flujos de tráfico asimétrico.

De forma predeterminada y sin usar MON, una máquina virtual de Azure VMware Solution en una red extendida sin MON puede comunicarse de nuevo con el entorno local mediante la ruta de acceso preferida de ExpressRoute. En función de los casos de uso del cliente, se debe evaluar cómo una máquina virtual en un segmento extendido de Azure VMware Solution habilitado con MON debe volver a recorrer en el entorno local, ya sea a través de la extensión de red o la puerta de enlace de T0 a través de ExpressRoute mientras mantiene los flujos de tráfico simétricos.

Si elige la ruta de acceso ne, por ejemplo, las rutas de directiva MON tienen que abordar específicamente la subred en el lado local; De lo contrario, se usa la ruta predeterminada 0.0.0.0/0. Las rutas de directiva se pueden encontrar en el segmento NE seleccionando avanzadas.

De forma predeterminada, todas las direcciones IP rfC 1918 se incluyen en la definición de rutas de directiva MON.

Esto da como resultado que todo el tráfico de salida rfC 1918 se tuneliza a través de la ruta de acceso ne y todo el tráfico público y de Internet que se enruta a la puerta de enlace de T0.

Las rutas de directiva solo se evalúan si la puerta de enlace de la máquina virtual se migra a la nube. El resultado de esta configuración es que las subredes coincidentes del destino se tunelizan mediante el dispositivo NE. Si las subredes no coinciden, se enrutan a través de la puerta de enlace T0.

Nota:

Para usar MON en Azure VMware Solution, es importante proporcionar las rutas /32 anunciadas por medio de BGP a sus pares; esto incluye el entorno local y Azure mediante la conexión de ExpressRoute. Por ejemplo, una máquina virtual de Azure aprende la ruta de acceso a una máquina virtual de Azure VMware Solution en un segmento de Azure VMware Solution habilitado para MON. Una vez que el tráfico devuelto se devuelve a la puerta de enlace de T0 según lo previsto, si la subred de retorno es una coincidencia RFC 1918, el tráfico se fuerza a través del NE en lugar del T0. Después, vuelve a Azure a través de ExpressRoute en el lado local. Esto puede provocar confusión para los firewalls con estado en cuanto al comportamiento de enrutamiento asimétrico e intermedio. También es una buena idea determinar cómo tendrán que acceder a Internet las máquinas virtuales de los segmentos DE MON de NE, ya sea a través de la puerta de enlace de T0 en Azure VMware Solution o solo a través del NE de vuelta al entorno local. En general, se deben quitar todas las rutas de directiva predeterminadas para evitar el tráfico asimétrico. Habilite solo las rutas de directiva si la infraestructura de red tal como se ha configurado para tener en cuenta y evitar el tráfico asimétrico.

Las rutas de directiva mon se pueden eliminar sin definir ninguna. Esto da como resultado que todo el tráfico de salida se enrute a la puerta de enlace de T0.

Las rutas de directiva mon se pueden actualizar con una ruta predeterminada (0.0.0.0/0). Esto da como resultado que todo el tráfico de salida se tuneliza a través de la ruta de acceso ne.

Como se describe en los diagramas anteriores, la importancia es que coincida con una ruta de directiva a cada subred necesaria. De lo contrario, el tráfico se enruta a través del T0 y no se tuneliza a través del NE.

Para obtener más información sobre las rutas de directiva, consulte el artículo Mobility Optimized Networking Policy Routes (Rutas de directiva para Mobility Optimized Networking).