Consideraciones de red para Azure VMware Solution implementaciones de dos regiones
En este artículo se describe cómo configurar la conectividad de red cuando las nubes privadas de Azure VMware Solution se implementan en dos regiones de Azure con fines de resistencia ante desastres. Si hay interrupciones regionales parciales o completas, la topología de red de este artículo permite a los componentes supervivientes (nubes privadas, recursos nativos de Azure y sitios locales) mantener la conectividad entre sí y con Internet.
Escenario de dos regiones
Este artículo se centra en un escenario típico de dos regiones, que se muestra en la Figura 1 siguiente:
- Existe una red en estrella tipo centro y radio de Azure en cada región.
- Se ha implementado una configuración resistente ante desastres para ExpressRoute (dos circuitos en dos ubicaciones de emparejamiento diferentes, con cada circuito conectado a redes virtuales de concentrador en ambas regiones). Las instrucciones proporcionadas en las secciones siguientes siguen siendo las mismas en caso de que se configure la conectividad VPN de reserva.
- Una nube privada de Azure VMware Solution se ha implementado en cada región.
Nota
En el escenario de referencia de la Figura 1, las dos redes virtuales del centro regional se conectan a través del emparejamiento de VNet global. Aunque no es estrictamente necesario, ya que el tráfico entre redes virtuales de Azure en las dos regiones se podría enrutar a través de conexiones de ExpressRoute, se recomienda encarecidamente esta configuración. El emparejamiento de VNet minimiza la latencia y maximiza el rendimiento, ya que elimina la necesidad de redireccionar el tráfico a través de los enrutadores perimetrales de ExpressRoute meet-me.
Patrones de comunicación de dos regiones
En las secciones siguientes se describe la configuración de red Azure VMware Solution necesaria para habilitar, en el escenario de doble región de referencia, los siguientes patrones de comunicación:
- Azure VMware Solution a Azure VMware Solution (que se trata en la sección Conectividad entre regiones de Azure VMware Solution);
- Azure VMware Solution a sitios locales conectados a través de ExpressRoute (tratado en la sección Conectividad híbrida);
- Azure VMware Solution a Azure Virtual Network (que se describe en la sección Conectividad de Azure Virtual Network);
- Azure VMware Solution a Internet (que se trata en la sección Conectividad a Internet).
Conectividad entre regiones de Azure VMware Solution
Cuando existen varias nubes privadas Azure VMware Solution, la conectividad de nivel 3 entre ellas suele ser un requisito para tareas como admitir la replicación de datos.
Azure VMware Solution admite de forma nativa la conectividad directa entre dos nubes privadas implementadas en diferentes regiones de Azure. Las nubes privadas se conectan a la red de Azure en su propia región a través de circuitos ExpressRoute, administrados por la plataforma y terminados en ubicaciones de reunión de ExpressRoute dedicadas. En este artículo, estos circuitos se conocen como circuitos administrados de Azure VMware Solution. Circuitos administrados de Azure VMware Solution no deben confundirse con los circuitos normales que los clientes implementan para conectar sus sitios locales a Azure. Los circuitos normales que los clientes implementan son circuitos administrados por el cliente (consulte la Figura 2).
La conectividad directa entre nubes privadas se basa en las conexiones de Global Reach de ExpressRoute entre los circuitos administrados de Azure VMware Solution, como se muestra en la línea verde del diagrama siguiente. Para obtener más información, vea Tutorial: Emparejamiento de entornos locales con Azure VMware Solution. En el artículo se describe el procedimiento para conectar un circuito administrado de Azure VMware Solution con un circuito administrado por el cliente. El mismo procedimiento se aplica a la conexión de dos circuitos administrados de Azure VMware Solution.
Conectividad híbrida
La opción recomendada para conectar las nubes privadas de Azure VMware Solution a sitios locales es Global Reach de ExpressRoute. Las conexiones de Global Reach se pueden establecer entre circuitos ExpressRoute administrados por el cliente y circuitos administrados ExpressRoute de Azure VMware Solution. Las conexiones de Global Reach no son transitivas, por lo que es necesaria una malla completa (cada circuito administrado de Azure VMware Solution conectado a cada circuito administrado por el cliente) para la resistencia ante desastres, como se muestra en la Figura 3 (representada por líneas naranjas).
Conectividad de Azure Virtual Network
Azure Virtual Network se puede conectar a las nubes privadas de Azure VMware Solution a través de conexiones entre puertas de enlace de ExpressRoute y circuitos administrados de Azure VMware Solution. Esta conexión es exactamente la misma manera que Azure Virtual Network se puede conectar a sitios locales a través de circuitos ExpressRoute administrados por el cliente. Consulte Conexión manual a la nube privada para obtener instrucciones de configuración.
En escenarios de dos regiones, se recomienda una malla completa para las conexiones de ExpressRoute entre los dos centros regionales Virtual Network y nubes privadas, como se muestra en la Figura 4 (representada por líneas amarillas).
Conectividad de Internet
Al implementar nubes privadas de Azure VMware Solution en varias regiones, se recomienda optar por opciones nativas para la conectividad a Internet (Traducción de direcciones de red de origen (SNAT) o direcciones IP públicas hasta NSX-T). Cualquiera de las opciones se puede configurar a través del Azure Portal (o a través de PowerShell, la CLI o las plantillas de ARM/Bicep) en el momento de la implementación, como se muestra en la Figura 5 siguiente.
Ambas opciones resaltadas en la Figura 5 proporcionan a cada nube privada una interrupción directa de Internet en su propia región. Las consideraciones siguientes deben informar a la decisión sobre qué opción nativa de conectividad a Internet usar:
- SNAT administrado debe usarse en escenarios con requisitos básicos y de solo salida (volúmenes bajos de conexiones salientes y sin necesidad de un control pormenorizado sobre el grupo de SNAT).
- Las direcciones IP públicas hasta el perímetro de NSX-T deben tener preferencia en escenarios con grandes volúmenes de conexiones salientes o cuando se requiere un control granular sobre las direcciones IP NAT. Por ejemplo, que las máquinas virtuales de Azure VMware Solution usan SNAT detrás de las direcciones IP. Las direcciones IP públicas hasta el perímetro NSX-T también admiten la conectividad entrante a través de DNAT. La conectividad entrante a Internet no se trata en este artículo.
Cambiar la configuración de conectividad a Internet de una nube privada después de la implementación inicial es posible. Pero la nube privada pierde la conectividad a Internet, a la red virtual de Azure y a sitios locales mientras se actualiza la configuración. Cuando se usa una de las opciones de conectividad nativa de Internet en la Figura 5 anterior, no se necesita ninguna configuración adicional en escenarios de dos regiones (la topología permanece igual que la que se muestra en la Figura 4). Para obtener más información sobre la conectividad a Internet para Azure VMware Solution, consulte Consideraciones de diseño de conectividad a Internet.
Interrupción de Internet nativa de Azure
Si un perímetro seguro de Internet se creó en Azure Virtual Network antes de que adoptara Azure VMware Solution, es posible que sea necesario usarlo para el acceso a Internet para las nubes privadas de Azure VMware Solution. El uso de un perímetro seguro de Internet de esta manera es necesario para la administración centralizada de directivas de seguridad de red, optimización de costos, etc. Los bordes de seguridad de Internet en Azure Virtual Network se pueden implementar mediante Azure Firewall o aplicaciones virtuales de red proxy y firewall de terceros disponibles en el Azure Marketplace.
El tráfico enlazado a Internet emitido por las máquinas virtuales de Azure VMware Solution se puede atraer a una red virtual de Azure mediante la creación de una ruta predeterminada y su anuncio, a través del protocolo de puerta de enlace de borde (BGP), al circuito ExpressRoute administrado de la nube privada. Esta opción de conectividad a Internet se puede configurar a través del Azure Portal (o a través de PowerShell, la CLI o las plantillas de ARM/Bicep) en el momento de la implementación, como se muestra en la Figura 6 siguiente. Para obtener más información, consulte Deshabilitar el acceso a Internet o habilitar una ruta predeterminada.
Las aplicaciones virtuales de red perimetrales de Internet pueden originar la ruta predeterminada si admiten BGP. Si no es así, debe implementar otras aplicaciones virtuales de red compatibles con BGP. Para más información sobre cómo implementar la conectividad saliente de Internet para Azure VMware Solution en una sola región, consulte Implementación de la conectividad a Internet para Azure VMware Solution con aplicaciones virtuales de red de Azure. En el escenario de doble región descrito en este artículo, se debe aplicar la misma configuración a ambas regiones.
Lo más importante en escenarios de dos regiones es que la ruta predeterminada originada en cada región debe propagarse a través de ExpressRoute solo a la nube privada de Azure VMware Solution de la misma región. Esta propagación permite que las cargas de trabajo de Azure VMware Solution accedan a Internet a través de una interrupción local (en la región). Sin embargo, si usa la topología que se muestra en la figura 4, cada nube privada de Azure VMware Solution también recibe una ruta predeterminada de igual costo desde la región remota a través de las conexiones ExpressRoute entre regiones. Las líneas discontinuas rojas representan esta propagación de ruta predeterminada entre regiones no deseadas en la Figura 7.
La eliminación de las conexiones ExpressRoute entre regiones de Azure VMware Solution logra el objetivo de insertar, en cada nube privada, una ruta predeterminada para reenviar conexiones enlazadas a Internet al perímetro de Internet de Azure en la región local.
Debe tenerse en cuenta que si se quitan las conexiones ExpressRoute entre regiones (líneas discontinuas rojas de la Figura 7), la propagación entre regiones de la ruta predeterminada se sigue produciendo a través de Global Reach. Sin embargo, las rutas propagadas a través de Global Reach tienen una ruta de acceso AS más larga que la originada localmente y se descartan mediante el proceso de selección de rutas BGP.
La propagación entre regiones a través de Global Reach de una ruta predeterminada menos preferida proporciona resistencia frente a errores del perímetro local de Internet. Si el perímetro de Internet de una región se queda sin conexión, deja de originar la ruta predeterminada. En ese caso, la ruta predeterminada menos preferida aprendida de la región remota se instala en la nube privada de Azure VMware Solution, de modo que el tráfico enlazado a Internet se enrute a través del punto de interrupción de la región remota.
La topología recomendada para implementaciones de dos regiones con saltos de Internet en redes virtuales de Azure se muestra en la Figura 8 siguiente.
Cuando se originan rutas predeterminadas en Azure, se debe tener especial cuidado para evitar la propagación a sitios locales, a menos que sea necesario proporcionar acceso a Internet a sitios locales a través de un perímetro de Internet en Azure. Los dispositivos operados por el cliente que terminan los circuitos ExpressRoute administrados por el cliente deben configurarse para filtrar las rutas predeterminadas recibidas de Azure, como se muestra en la Figura 9. Esta configuración es necesaria para evitar interrumpir el acceso a Internet para los sitios locales.
Pasos siguientes
Para obtener más información sobre las características de red de Azure VMware Solution, consulte Conceptos de redes e interconectividad de Azure VMware Solution.
Para obtener más información sobre la conectividad a Internet para Azure VMware Solution, consulte Consideraciones de diseño de conectividad a Internet.