Redes de radio a radio

Los modelos de diseño de redes más comunes de Azure implican la creación de topologías de red virtual en estrella tipo hub-and-spoke en una o varias regiones de Azure, opcionalmente conectadas a redes locales mediante Azure ExpressRoute o túneles de red privada virtual (VPN) de sitio a sitio a través de la red pública de Internet.

La mayoría de las guías de diseño se centran en el tráfico de aplicaciones hacia esas redes virtuales de los usuarios de redes internas y locales o desde Internet (lo que normalmente se denomina tráfico vertical de arriba abajo en el sector, ya que a menudo se representa mediante líneas verticales en los diagramas de red). Este artículo se centra en varios modelos que están disponibles para el tráfico horizontal de derecha a izquierda. Es decir, la comunicación fluye entre las cargas de trabajo implementadas en redes virtuales de Azure, ya sea dentro de una región o en regiones diferentes.

Asegurarse de que el diseño de red cumple los requisitos del tráfico horizontal de derecha a izquierda es fundamental para proporcionar rendimiento, escalabilidad y resistencia a las aplicaciones que se ejecutan en Azure.

Posibles casos de uso

El tráfico de radio a radio puede ser importante en varios escenarios:

• Los distintos niveles de una aplicación sencilla se encuentran en redes virtuales independientes. Por ejemplo, los servidores de red perimetral (también conocidos como servidores DMZ) de una red virtual perimetral se comunican con los servicios de aplicación de una red virtual interna.
• Las cargas de trabajo de la aplicación en diferentes entornos (desarrollo, ensayo, producción) deben replicar datos entre sí.
• Las distintas aplicaciones o microservicios deben comunicarse entre sí.
• Las bases de datos deben replicar datos entre regiones para garantizar la continuidad empresarial en caso de desastre.
• Los usuarios están dentro de redes virtuales de Azure. Por ejemplo, usan Azure Virtual Desktop.

Modelos y topologías para la comunicación entre radios

Hay dos topologías principales que puede usar en diseños de Azure que abarcan varias redes virtuales: topología en estrella tipo hub-and-spoke tradicional y Azure Virtual WAN. En un entorno de Virtual WAN, Microsoft administra la red virtual del centro de conectividad y todo lo que contiene. En un entorno tradicional en estrella tipo hub-and-spoke, es el usuario quien administra la red virtual del centro de conectividad.

Las topologías de Virtual WAN y en estrella tipo hub-and-spoke son ejemplos de arquitecturas en las que las cargas de trabajo se ejecutan en redes virtuales radiales y la conectividad con el entorno local está centralizada en una red virtual de un centro de conectividad. Muchos de los conceptos que se explican en este artículo se aplican en diseños en estrella tipo hub-and-spoke y en Virtual WAN.

Hay dos modelos principales para conectar redes virtuales radiales entre sí:

• Radios conectados directamente entre sí. Los emparejamientos de red virtual o túneles VPN se crean entre las redes virtuales radiales para proporcionar conectividad directa sin atravesar la red virtual del centro de conectividad.
• Los radios se comunican mediante un dispositivo de red. Cada red virtual radial tiene un emparejamiento con Virtual WAN o con una red virtual de centro de conectividad. Un dispositivo enruta el tráfico de radio a radio. El dispositivo lo puede administrar Microsoft (como con Virtual WAN) o el usuario.

Modelo 1: Radios conectados directamente entre sí

Las conexiones directas entre radios suelen ofrecer un mejor rendimiento, latencia y escalabilidad que las conexiones que pasan por una aplicación virtual de red (NVA) en un centro de conectividad. El envío de tráfico a través de NVA puede agregar latencia al tráfico si estas NVA están en una zona de disponibilidad diferente y es necesario cruzar al menos dos emparejamientos de red virtual cuando se envía tráfico a través del centro de conectividad. Hay varias opciones para conectar dos redes virtuales radiales entre sí directamente: emparejamiento de red virtual, Azure Virtual Network Manager y túneles VPN.

• Emparejamiento de red virtual. Las ventajas de los emparejamientos directos de redes virtuales mediante radios son:

  • Menor costo, ya que se requieren menos saltos de emparejamiento de red virtual.
  • Mejor rendimiento, ya que el tráfico no necesita atravesar ningún dispositivo de red que produzca latencia o posibles cuellos de botella.

  Otros escenarios incluyen conectividad entre inquilinos. Sin embargo, es posible que tenga que inspeccionar el tráfico entre redes virtuales radiales, lo que podría requerir el envío de tráfico a través de dispositivos de red centralizados en la red virtual del centro de conectividad.

• Azure Virtual Network Manager. Además de las ventajas que ofrece el emparejamiento de redes virtuales, Azure Virtual Network Manager proporciona un servicio de administración que le permite administrar entornos de red virtual y que crea conectividad a gran escala. Con Azure Virtual Network Manager, puede crear tres tipos de topologías entre suscripciones, para redes virtuales existentes y para nuevas:

  • Topologías en estrella tipo hub-and-spoke con radios que no están conectados entre sí.

  • Topologías en estrella tipo hub-and-spoke con radios que se conectan directamente entre sí, sin ningún salto en el medio.

  • Un grupo en malla de redes virtuales que están interconectadas.

    

    Descargue todos los diagramas de Visio de este artículo.

    Cuando se crea una topología en estrella tipo hub-and-spoke con Azure Virtual Network Manager en la que los radios están conectados entre sí, la conectividad directa entre las redes virtuales radiales del mismo grupo de red se crea automáticamente de forma bidireccional. Mediante Azure Virtual Network Manager, puede hacer estática o dinámicamente que las redes virtuales de radio sean miembros de un grupo de redes específico, que crea automáticamente la conectividad para cualquier red virtual.

    Puede crear varios grupos de red para aislar clústeres de redes virtuales radiales de conectividad directa. Cada grupo de red proporciona la misma compatibilidad regional y multirregional para la conectividad de radio a radio. Asegúrese de mantenerse por debajo de los límites máximos de Azure Virtual Network Manager que se describen en las preguntas más frecuentes sobre Azure Virtual Network Manager.

• Túneles VPN que conectan redes virtuales. Puede configurar servicios VPN para conectar directamente redes virtuales radiales mediante puertas de enlace de VPN de Microsoft o NVA de VPN de terceros. La ventaja de esta opción es que las redes virtuales radiales se conectan a través de nubes comerciales y soberanas dentro del mismo proveedor de nube o proveedores de conectividad entre nubes. Además, si hay NVA de redes de área extensa definidas por software (SD-WAN) en cada red virtual radial, esta configuración puede facilitar el uso del plano de control y el conjunto de características del proveedor de terceros para administrar la conectividad de red virtual.

  Esta opción también puede ayudarle a cumplir los requisitos de cumplimiento para el cifrado del tráfico entre redes virtuales de un único centro de datos de Azure que aún no proporciona el cifrado MACsec. Pero esta opción presenta sus propias dificultades debido a los límites de ancho de banda de los túneles IPsec (1,25 Gbps por túnel) y las restricciones de diseño que obligan a tener puertas de enlace de red virtual en las redes virtuales de centro de conectividad y en las radiales: si la red virtual de radial tiene una puerta de enlace de red virtual, no se puede conectar a Virtual WAN ni usar una puerta de enlace de red virtual de centro de conectividad para conectarse a redes locales.

Modelo 1: Región única

Independientemente de la tecnología que use para conectar redes virtuales radiales entre sí, las topologías de red tendrían este aspecto para una sola región:

Modelo 1: Varias regiones

Los diseños que conectan todas las redes virtuales radiales entre sí también se pueden extender a varias regiones. En esta topología, Azure Virtual Network Manager resulta aún más importante para reducir la sobrecarga administrativa de mantener el gran número de conexiones necesario.

Cuando conecta directamente redes virtuales radiales entre sí en una topología totalmente en malla, debe tener en cuenta el número potencialmente elevado de emparejamientos de red virtual necesarios. En el siguiente diagrama se muestra este problema. En este escenario, se recomienda especialmente usar Azure Virtual Network Manager para poder crear automáticamente conexiones de red virtual.

Modelo 2: Radios que se comunican a través de un dispositivo de red

En lugar de conectar redes virtuales radiales directamente entre sí, puede usar dispositivos de red para reenviar el tráfico entre los radios. Los dispositivos de red proporcionan servicios de red adicionales, como la inspección profunda de paquetes y la segmentación o supervisión del tráfico, pero pueden generar cuellos de botella de latencia y rendimiento si no tienen el tamaño correcto. Normalmente, estos dispositivos se encuentran en una red virtual de centro de conectividad a la que se conectan los radios. Hay varias opciones para usar un dispositivo de red para reenviar el tráfico entre radios:

• Enrutador de centro de conectividad de Virtual WAN. Totalmente administrado por Microsoft, Virtual WAN contiene un enrutador virtual que atrae el tráfico de los radios y lo enruta a otra red virtual conectada a Virtual WAN o a redes locales a través de ExpressRoute o túneles VPN de punto a sitio o de sitio a sitio. El enrutador de Virtual WAN escala y reduce verticalmente de forma automática, por lo que solo tiene que asegurarse de que el volumen de tráfico entre los radios permanezca dentro de los límites de Virtual WAN.

• Azure Firewall. Azure Firewall es un dispositivo de red administrado por Microsoft y se puede implementar en redes virtuales centrales que administra el usuario o en centros de conectividad de Virtual WAN. Puede reenviar paquetes IP y también puede inspeccionarlos y aplicar reglas de segmentación de tráfico que se definen en las directivas. Proporciona escalado automático hasta los límites de Azure Firewall para que no se convierta en un cuello de botella. Tenga en cuenta que Azure Firewall proporciona funcionalidades integradas en varias regiones solo cuando se usa con Virtual WAN. Sin Virtual WAN, tiene que implementar rutas definidas por el usuario para lograr la comunicación entre radios entre regiones.

• Aplicaciones virtuales de red de terceros. Si prefiere usar una aplicación virtual de red de un asociado de Microsoft para realizar el enrutamiento y la segmentación de red, puede implementar aplicaciones virtuales de red en una topología de estrella tipo hub-and-spoke o en una de Virtual WAN. Para más información, consulte Implementación de NVA de alta disponibilidad o Aplicaciones virtuales de red en un centro de conectividad de Virtual WAN. Debe asegurarse de que la aplicación virtual de red admite el ancho de banda que generan las comunicaciones entre radios.

• Azure VPN Gateway. Puede usar una puerta de enlace de VPN de Azure como un tipo de próximo salto de ruta definida por el usuario, pero Microsoft no recomienda usar puertas de enlace de red virtual VPN para enrutar el tráfico de radio a radio. Están diseñadas para cifrar el tráfico a sitios locales o usuarios de VPN. Por ejemplo, no hay ninguna garantía del ancho de banda entre radios que una puerta de enlace de VPN puede enrutar.

• ExpressRoute. En determinadas configuraciones, una puerta de enlace de ExpressRoute puede anunciar rutas que atraigan la comunicación de radio a radio, enviando tráfico al enrutador perimetral de Microsoft, donde se enrutará al radio de destino. Microsoft no recomienda este escenario ya que genera latencia al enviar tráfico al perímetro de la red troncal de Microsoft y viceversa. Además, Microsoft no recomienda este enfoque, debido al único punto de error y al radio de explosión grande. Este escenario también presenta varios problemas causados por la presión adicional sobre la infraestructura de ExpressRoute (la puerta de enlace y los enrutadores físicos). Esta presión adicional puede provocar pérdida de paquetes.

En los diseños de red en estrella tipo hub-and-spoke que tienen NVA centralizadas, el dispositivo se coloca normalmente en el centro de conectividad. Los emparejamientos de red virtual entre redes virtuales en estrella tipo hub-and-spoke deben crearse manual o automáticamente con Azure Virtual Network Manager:

• Emparejamientos de red virtual manuales. Este enfoque es suficiente si tiene un número bajo de redes virtuales radiales, pero crea sobrecarga de administración a gran escala.

• Azure Virtual Network Manager. Como se indicó anteriormente, Azure Virtual Network Manager proporciona características para administrar entornos de red virtual y emparejamientos a gran escala. Las configuraciones de emparejamiento entre redes virtuales en estrella tipo hub-and-spoke se configuran automáticamente de forma bidireccional para los grupos de red.

  Azure Virtual Network Manager proporciona la capacidad de agregar de forma estática o dinámica pertenencias de red virtual radial a un grupo de red específico, el cual crea automáticamente la conexión de emparejamiento de los nuevos miembros. Las redes virtuales radiales de los grupos de red pueden usar las puertas de enlace VPN del centro de conectividad o las de ExpressRoute para la conectividad. Asegúrese de que se mantiene por debajo de los límites máximos de Azure Virtual Network Manager.

Modelo 2: Región única

En el diagrama siguiente se muestra una topología en estrella tipo hub-and-spoke de una sola región que envía tráfico entre los radios mediante un firewall de Azure implementado en la red virtual del centro de conectividad. El tráfico se reenvía al dispositivo centralizado en el centro de conectividad a través de rutas definidas por el usuario que se aplican a las subredes radiales.

En determinadas circunstancias, puede ser beneficioso separar las aplicaciones virtuales de red que controlan el tráfico de radio a radio y hacia Internet con fines de escalabilidad. Para lograr esta separación, haga lo siguiente:

• Ajuste las tablas de rutas de los radios para enviar direcciones privadas (aquellas que tienen una ruta para prefijos RFC 1918) a una NVA responsable del tráfico de Azure a Azure y de Azure al entorno local (también denominado tráfico horizontal de derecha a izquierda).
• Ajuste el tráfico de Internet (que tiene una ruta 0.0.0.0/0) a una segunda NVA. Esta NVA es responsable del tráfico de Azure a Internet (también denominado tráfico vertical de arriba abajo).

El diagrama siguiente muestra esta configuración:

Modelo 2: Varias regiones

Puede ampliar la misma configuración a varias regiones. Por ejemplo, en un diseño en estrella tipo hub-and-spoke que usa Azure Firewall, debe aplicar tablas de rutas adicionales a las subredes de Azure Firewall de cada centro de conectividad para los radios de la región remota. Esta configuración garantiza que el tráfico entre regiones se pueda reenviar entre los firewalls de Azure en cada red virtual del centro de conectividad. El tráfico interregional entre redes virtuales radiales atraviesa ambos firewalls de Azure. Para más información, consulte Azure Firewall para enrutar una topología de varios concentradores y radios:

La variación de diseño con firewalls de Azure independientes o aplicaciones virtuales de red para el tráfico vertical de arriba abajo y horizontal de derecha a izquierda también es posible en una topología en estrella tipo hub-and-spoke de varias regiones:

Virtual WAN crea una topología similar y toma el control de la complejidad del enrutamiento. Lo hace en los centros de conectividad (que administra Microsoft) y en los radios (donde se pueden insertar rutas y no es necesario que se definan manualmente en tablas de rutas). Por lo tanto, el administrador de red solo tiene que conectar las redes virtuales radiales a un centro de conectividad de Virtual WAN y no tiene que preocuparse por el reenvío del tráfico entre regiones.

Patrones híbridos

Muchas situaciones requieren un enfoque híbrido que combina los dos patrones descritos anteriormente. En este enfoque, el tráfico entre determinados radios tiene que pasar por conexiones directas, pero el resto de los radios se comunican a través de un dispositivo de red central. Por ejemplo, en un entorno de Virtual WAN, puede conectar directamente dos radios específicos que tengan requisitos de ancho de banda alto y baja latencia. Otro escenario implica redes virtuales radiales que forman parte de un único entorno. Por ejemplo, podría permitir que una red virtual radial de desarrollo se conectara directamente a otra red virtual radial de desarrollo, pero forzar a que las cargas de trabajo de desarrollo y producción se comuniquen a través del dispositivo central.

Otro patrón habitual conlleva la conexión de radios de una región a través de emparejamientos directos de red virtual o grupos conectados de Azure Virtual Network Manager, pero permitiendo el tráfico interregional entre NVA. La motivación principal de este modelo suele ser reducir el número de emparejamientos de red virtual en la arquitectura. Sin embargo, en comparación con el primer modelo (conectividad directa entre radios), una desventaja introducida en este modelo es la necesidad de más saltos de emparejamiento de red virtual para el tráfico entre regiones. Estos saltos aumentan los costos debido a los varios emparejamientos de red virtual que se cruzan. Otra desventaja es la carga adicional de las NVA del centro de conectividad para hacer frente a todo el tráfico entre regiones.

Los mismos diseños son aplicables a Virtual WAN. Sin embargo, una consideración a tener en cuenta es que la conectividad directa entre redes virtuales radiales debe configurarse manualmente entre las redes virtuales y no mediante el recurso de Virtual WAN. Azure Virtual Network Manager no admite actualmente arquitecturas basadas en Virtual WAN. Por ejemplo:

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• Jay Li | Jefe de productos sénior
• Jose Moreno | Ingeniero principal de clientes
• Alejandra Palacios | Ingeniero sénior de clientes de infraestructura de Azure

Otros colaboradores:

• Mick Alberts | Escritor técnico
• Mohamed Hassan | Project Manager principal
• Andrea Michael | Jefe de programas
• Yasukuni Morishima | Ingeniero de clientes II
• Jithin PP | Ingeniero de clientes

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Cloud Adoption Framework: Topología de red de zona de aterrizaje y conectividad
• Interconexión de red virtual
• Azure Virtual Network Manager
• Virtual WAN
• Azure Firewall
• Conectividad de red segura en Azure
• Introducción a las redes virtuales de Azure

Recursos relacionados

• Topología de red en estrella tipo hub-and-spoke en Azure
• Topología de red en estrella tipo hub-and-spoke con Azure Virtual WAN
• Topología tradicional de redes de Azure