Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se explica cómo diseñar redes Azure que abarcan varias regiones. Una red de varias regiones proporciona alta disponibilidad frente a interrupciones regionales, sirve a los usuarios distribuidos geográficamente con menor latencia y admite los requisitos de residencia de datos normativos.
Lo que trata este artículo
En este artículo se tratan la redundancia zonal frente a la redundancia regional, las estrategias de enrutamiento entre regiones, las opciones de topología de concentrador para implementaciones multirregión, los patrones de conmutación por error activo-activo frente a activo-pasivo y las consideraciones sobre la latencia de replicación.
Quién necesita este artículo
Lea este artículo si el entorno coincide con alguna de estas condiciones:
- La carga de trabajo requiere protección de recuperación ante desastres frente a la caída total de una región de Azure.
- Sirve a los usuarios en varias zonas geográficas y necesita minimizar la latencia de red.
- Los requisitos normativos o de cumplimiento exigen que los datos permanezcan dentro de límites geográficos específicos.
- Los objetivos de continuidad empresarial definen un objetivo de tiempo de recuperación (RTO) que una sola región no puede cumplir solo.
Si la carga de trabajo funciona en una sola región y las implementaciones con redundancia de zona cumplen sus requisitos de disponibilidad, es posible que aún no necesite un diseño multirregional. Empieza con una topología en estrella o una WAN virtual en una región y amplía más adelante.
Enfoque lift-and-shift: Las cargas de trabajo heredadas a menudo no pueden ejecutarse en modo activo-activo entre regiones. Planee la recuperación ante desastres con Azure Site Recovery y un centro en la región de recuperación en lugar de un diseño activo-activo completo.
Enfoque de modernización: Implemente aplicaciones orientadas al cliente en modo activo-activo en dos regiones con SKU con redundancia por zonas, utilizando un espacio de direcciones no superpuesto para que las regiones puedan establecer emparejamiento (peering) si es necesario.
Enfoque multinube: Use Azure Virtual WAN para conectar varias regiones y sucursales, y planifique el enrutamiento entre regiones junto con su tránsito multinube.
servicios y características de Azure
En la tabla siguiente se enumeran los servicios y características de Azure que habilitan las redes multiregión:
| Servicio o característica | Rol en el diseño de varias regiones | Aprende más |
|---|---|---|
| Administrador de tráfico de Azure | Enrutamiento de tráfico basado en DNS entre regiones para cualquier protocolo | Introducción a Traffic Manager |
| Azure Front Door (portal de entrada de Azure) | Equilibrio de carga global HTTP/HTTPS con CDN y WAF en el perímetro | Introducción a Front Door |
| Emparejamiento global de VNet | Conectividad privada y de alto ancho de banda entre redes virtuales en diferentes regiones | Interconexión de redes virtuales |
| Global Reach de ExpressRoute | Conecta sitios locales entre sí a través de la red troncal de Azure | ExpressRoute Global Reach |
| Azure Virtual WAN (multi hub) | Tránsito global administrado por Microsoft con enrutamiento automático entre centros | tránsito global de Virtual WAN |
| Azure Virtual Network Manager (AVNM) | Automatiza la topología de emparejamiento entre regiones y la administración de grupos de red | Introducción a AVNM |
¿Por qué varias regiones requiere varias redes virtuales?
Una red virtual (VNet) abarca una sola región. Las subredes dentro de esa red virtual abarcan todas las zonas de disponibilidad de la región, pero la propia red virtual no puede extenderse a través de los límites de la región. Por lo tanto, las redes multirregión implican implementar varias VNets, una o más por región, y conectarlas con servicios entre regiones.
Esta restricción fundamental da forma a cada diseño de varias regiones:
- Cada región necesita su propio espacio de direcciones de VNet (que no se solape con el de otras regiones para el peering).
- El tráfico entre regiones requiere un mecanismo de conectividad explícito: emparejamiento global de redes virtuales, conectividad entre centros de Virtual WAN o enrutamiento basado en puertas de enlace.
- Los servicios globales de equilibrio de carga (Traffic Manager o Front Door) dirigen a los usuarios a la implementación regional correcta.
Para obtener instrucciones de planeamiento de subredes y direcciones, consulte Planeamiento de direcciones IP.
Zonas de disponibilidad frente a redundancia regional
Antes de diseñar una topología de varias regiones, comprenda los dos niveles de redundancia de infraestructura en Azure:
| Level | Protege contra | Mecanismo | Example |
|---|---|---|---|
| Zonas de disponibilidad | Error de un único centro de datos dentro de una región | Separar físicamente los centros de datos con energía, refrigeración y redes independientes | Azure Firewall con redundancia de zona desplegado en tres zonas |
| Redundancia regional | Fallo de toda una región (desastre natural, corte generalizado) | Implementación de cargas de trabajo en dos o más regiones de Azure | Aplicación web activa-activa en el este de EE. UU. y el oeste de EE. UU. |
Comience con redundancia de zona. Las implementaciones con redundancia de zona protegen frente a los escenarios de error más comunes (problemas de un solo centro de datos) sin la complejidad del enrutamiento multiregión. Agregue redundancia regional cuando la empresa requiera protección contra interrupciones en toda la región o cuando necesite atender usuarios distribuidos geográficamente.
Referencia de servicios de red con redundancia de zona
En la tabla siguiente se muestran las opciones de implementación con redundancia de zona para los servicios de red principales. Implemente estos elementos en cada región donde ejecute cargas de trabajo:
| Servicio | Opción con redundancia entre zonas | Notes |
|---|---|---|
| Azure Firewall | Implementación en zonas de disponibilidad | Distribuye en todas las tres zonas de la región. |
| Balanceador de carga estándar | Front-end con redundancia de zona | Comportamiento predeterminado para la SKU estándar |
| Application Gateway v2 | Despliegue con redundancia de zona | Requiere la SKU Standard_v2 o WAF_v2 |
| VPN Gateway | Activa-activa con SKU con redundancia de zona | Use SKU con sufijo AZ (VpnGw1AZ, VpnGw2AZ, etc.) |
| Puerta de enlace de ExpressRoute | SKU con redundancia de zona | Usar ErGw1AZ, ErGw2AZ o ErGw3AZ |
| Azure Bastion | Redundancia de zona (versión preliminar) | SKU básicas, estándar y premium |
| Puerta de enlace NAT (StandardV2) | Zone-redundant | Se requiere la SKU StandardV2; la SKU Standard solo está disponible por zonas |
Cómo elegir un enfoque de enrutamiento de tráfico entre regiones
Use la tabla de decisión siguiente para seleccionar el servicio adecuado para enrutar el tráfico entre regiones:
| Sus necesidades | Servicio recomendado | Cómo funciona |
|---|---|---|
| Conmutación por error entre varias regiones o distribución de carga para cualquier protocolo (HTTP, TCP, UDP) | Administrador de tráfico de Azure | Devuelve la mejor dirección IP del punto de conexión a través de la resolución DNS. El cliente se conecta directamente al punto de conexión. La velocidad de conmutación por error depende del TTL de DNS (normalmente, entre 30 y 300 segundos). |
| Balanceo de carga global HTTP/HTTPS con CDN, WAF y recuperación rápida ante fallos | Azure Front Door (portal de entrada de Azure) | Termina las conexiones en los puntos de presencia (PoP) periféricos. Enruta las solicitudes al backend en buen estado más próximo. Proporciona conmutación por error a nivel de conexión (en segundos, sin depender del TTL del DNS). |
| Tráfico de back-end privado entre regiones (replicación, API internas) | Emparejamiento global de VNet | Conecta VNets entre regiones a través de la red global de Microsoft. La interconexión entre pares no es transitiva; cada relación de interconexión entre pares es explícita. Se aplican cargos por transferencia de datos por GB. |
| Conectividad de sitio a sitio local a través de Azure | Global Reach de ExpressRoute | Conecta dos circuitos ExpressRoute para que las ubicaciones locales se comuniquen a través de la red troncal de Microsoft sin atravesar enrutadores del concentrador. |
Sugerencia
Combina estos servicios. Por ejemplo, utilice Front Door para el tráfico HTTP de cara al usuario y Global VNet Peering para la replicación de backend entre distintas regiones.
Cómo elegir una topología de concentrador de varias regiones
Después de decidir extender la red entre regiones, elija un patrón de centro para administrar la conectividad entre regiones:
| Factor | Centro por región (tradicional) | WAN virtual multihub |
|---|---|---|
| Conectividad entre regiones | El cliente configura el emparejamiento de red virtual global entre centros regionales y administra las UDR. | Enrutamiento automático entre centros: todos los concentradores de Virtual WAN se interconectan de forma predeterminada |
| Management | Control total del cliente sobre el enrutamiento, las reglas de firewall y el emparejamiento | infraestructura de concentrador administrada por Microsoft con administración basada en directivas |
| Más adecuado para | Organizaciones que necesitan un control de enrutamiento granular, NVA personalizadas o que ya han invertido en hubs | Organizaciones con muchas regiones, más de 30 sitios de sucursal o preferencia para la infraestructura administrada |
| Tránsito global | Requiere un emparejamiento explícito y la configuración de UDR entre cada par de concentradores | Integrado: el tráfico entre dos concentradores cualesquiera se enruta automáticamente |
| Scaling | Añadir hubs y enlaces de peering manualmente (AVNM puede automatizarlo) | Agregar hubs mediante la configuración de Virtual WAN: las actualizaciones de enrutamiento se realizan automáticamente |
| Modelo de costo | Recursos de la VNet del hub (firewall, puerta de enlace, peering) facturados por separado | Precios unitarios de Virtual WAN más los recursos conectados |
Para consultar una comparación detallada de la topología hub-and-spoke frente a Virtual WAN en una sola región, consulte Topología hub-and-spoke y Virtual WAN.
Consideraciones de diseño
Enfoque de diseño multirregional de lift-and-shift
- Para cargas de trabajo heredadas que no pueden abarcar zonas o regiones, diseñe pensando en la recuperación ante desastres en lugar de en el modo activo-activo: replique con Azure Site Recovery a una región de recuperación.
- Cree un concentrador en la región de recuperación que replique el concentrador principal para que el tráfico de conmutación por error disponga de los mismos servicios compartidos.
- Utilice Azure Traffic Manager o la conmutación por error de DNS para redirigir a los usuarios durante una interrupción regional.
- Mantenga el espacio de direcciones de la región de recuperación sin solapamientos con la región principal para evitar conflictos durante la conmutación por error y cualquier emparejamiento posterior.
Moderniza el enfoque de diseño multirregional
- Implemente cargas de trabajo orientadas al cliente en modo activo-activo en dos regiones con SKU con redundancia de zona para lograr la máxima resiliencia.
- Asigna rangos de direcciones que no se solapen a las regiones principal y de respaldo, de modo que los enlaces active-active puedan utilizar posteriormente el emparejamiento de VNet globales sin necesidad de reasignar direcciones.
- Elija la capa de entrega por tipo de aplicación: Azure Front Door para aplicaciones web y Traffic Manager para aplicaciones que no son web, distribuyendo entre puntos de conexión públicos regionales.
- Proteja los puntos de conexión públicos de cada región con el firewall del concentrador (SNAT y DNAT), de modo que el tráfico entrante se inspeccione antes de llegar a los servidores back-end.
Enfoque de diseño multinube y multirregional
- Use Azure Virtual WAN para interconectar varias regiones de Azure, sucursales y extremos de la nube con enrutamiento automático de cualquier punto a cualquier otro.
- Planifique rangos de direcciones agregados y no superpuestos en distintas regiones y nubes para que el enrutamiento de tránsito siga siendo sencillo.
- Finalice las conexiones IPsec entre nubes en centros protegidos regionales y permita que Virtual WAN controle el enrutamiento entre centros.
- Distribuya la entrada pública entre regiones mediante Front Door o Traffic Manager y mantenga la inspección en cada firewall del centro regional.
Prerequisites
Antes de diseñar una red de varias regiones, asegúrese de que tiene:
- Implementó y probó una topología de una sola región. Comience con hub-and-spoke o Virtual WAN.
- Requisitos definidos de alta disponibilidad y recuperación ante desastres: RTO, objetivo de punto de recuperación (RPO) y mandatos de cumplimiento.
- Se creó un plan de direcciones IP sin solapamientos para todas las regiones. Consulte Planeamiento de direcciones IP.
- Se identificó qué cargas de trabajo solo necesitan redundancia regional frente a redundancia de zona.
Patrones de implementación activo-activo frente a activo-pasivo
El modelo de implementación de varias regiones determina cómo fluye el tráfico durante el funcionamiento normal y durante un error regional:
Active-active
Ambas regiones atienden el tráfico simultáneamente. Un equilibrador de carga global, como Traffic Manager o Front Door, distribuye las solicitudes entre regiones en función de la proximidad, el rendimiento o el peso.
Cuándo usar activo-activo:
- La aplicación puede controlar las solicitudes en cualquier región sin dependencias de estado específicas de la región.
- Necesitas el RTO más bajo posible (la conmutación por error es inmediata porque la región en buen estado ya administra el tráfico).
- Se quiere utilizar la capacidad en ambas regiones durante el funcionamiento normal (eficiencia de costes).
Consideraciones sobre redes:
- Ambas regiones deben tener una infraestructura de red idéntica, incluidos firewalls, puertas de enlace y equilibradores de carga.
- La replicación de datos entre regiones debe mantener ambas implementaciones actualizadas.
- El TTL de DNS y los intervalos de sondeo de estado determinan la rapidez con la que Traffic Manager redirige el tráfico. Front Door proporciona una conmutación por error más rápida a nivel de conexión.
Active-passive
Una región (principal) controla todo el tráfico. La región secundaria permanece lista, pero no atiende las solicitudes de usuario hasta un evento de conmutación por error.
Cuándo usar activo-pasivo:
- La aplicación tiene requisitos estrictos de región de escritura o no puede replicar fácilmente el estado.
- Las restricciones de costo impiden ejecutar la capacidad completa en dos regiones simultáneamente.
- Tu tolerancia al RTO permite el tiempo necesario para activar la región secundaria.
Consideraciones sobre redes:
- La infraestructura de red de la región pasiva puede usar niveles inferiores o una capacidad reducida hasta que se produzca la conmutación por error.
- La conmutación por error automatizada requiere pruebas de estado con umbrales adecuados (para evitar oscilaciones).
- Pruebe la conmutación por error con regularidad. Las configuraciones de red en la región pasiva pueden desincronizarse si no se validan.
- Mantenga sincronizadas las tablas de rutas y las reglas de NSG entre regiones. Utilice plantillas de infraestructura como código para garantizar que la región pasiva tenga el mismo nivel de seguridad que la región primaria.
- Aprovisione previamente las puertas de enlace de VPN o de ExpressRoute en la región pasiva. El aprovisionamiento de puerta de enlace puede tardar entre 20 y 45 minutos. Eso es demasiado lento para la mayoría de los objetivos de RTO.
Elección entre redes activas-activas y activas-pasivas
La elección entre redes activas y activas-pasivas afecta al tamaño de red, el costo y la complejidad operativa:
| Consideración | Active-active | Active-passive |
|---|---|---|
| Capacidad de la red | Capacidad completa en ambas regiones | Capacidad reducida en la región pasiva (escalar en caso de conmutación por error) |
| Aprovisionamiento de puerta de enlace | Siempre activo en ambas regiones | Preaprovisionado, pero puede utilizar niveles inferiores |
| Sincronización de datos entre regiones | Tráfico de replicación bidireccional y continuo | Replicación asíncrona unidireccional al sistema en espera |
| Reglas de firewall | Conjuntos de reglas idénticos, ambos aplicados activamente | Conjuntos de reglas idénticos, pero el conjunto pasivo rara vez se utiliza |
| Direccionamiento IP | Ambas regiones se anuncian al Load Balancer global | Solo la región principal se anuncia hasta la conmutación por error |
| Riesgo operativo | Menor: ambas rutas se ejercitan continuamente | Alta: la ruta pasiva puede desviarse o tener configuraciones no probadas |
Replicación y latencia de datos
La replicación entre regiones presenta la latencia de red que afecta al diseño de aplicaciones. Azure regiones dentro de la misma geografía suelen presentar una latencia de ida y vuelta de 1 a 10 ms para pares cercanos (por ejemplo, Este de EE. UU. a Este de EE. UU. 2) y 30–70 ms para pares lejanos (por ejemplo, Este de EE. UU. a Oeste de EE. UU.). Los pares de regiones transatlánticos o transpacíficos pueden superar los 100 ms.
Consideraciones clave de diseño:
- Topología de replicación: Elija replicación sincrónica solo para pares de regiones con baja latencia (< 10 ms). Use la replicación asincrónica para pares lejanos para evitar la degradación del rendimiento de la aplicación.
- Planificación del ancho de banda: Estime los requisitos de rendimiento de la replicación y tenga en cuenta los costes de transferencia de datos por GB del emparejamiento de VNet globales. La replicación de gran volumen entre regiones distantes puede generar cargos de salida significativos.
- Resolución de conflictos: Los patrones activos y activos con escrituras bidireccionales requieren estrategias de resolución de conflictos en la capa de aplicación o base de datos. La red proporciona conectividad, pero las aplicaciones deben controlar los conflictos de escritura.
- Puntos de conexión privados para la replicación de PaaS: Al replicar Azure SQL, Cosmos DB o Storage entre regiones, use puntos de conexión privados en cada región para mantener el tráfico de replicación en la red troncal de Microsoft y evitar la exposición pública a Internet.
Consideraciones sobre los costos
La red multiregión aumenta los costos a través de la infraestructura duplicada y la transferencia de datos entre regiones. Planee su presupuesto en torno a estos principales impulsores de costos:
- Transferencia de datos entre regiones: El emparejamiento global de redes virtuales y el tráfico entre hubs de Virtual WAN generan cargos por GB por los datos que cruzan los límites entre regiones. El tráfico intrarregional entre VNets emparejadas en la misma región no tiene coste adicional cuando es dentro de la misma zona, y se cobra a una tarifa inferior cuando es entre zonas.
- Dispositivos de red duplicados: Cada región requiere su propio firewall, equilibrador de carga y instancias de puerta de enlace. Las implementaciones activo-activo duplican estos costes. Las implementaciones activo-pasivo pueden reducir los costes utilizando niveles más pequeños en la región en espera y escalando al alza durante la conmutación por error.
- Tarifas globales de equilibrio de carga: Tanto Traffic Manager como Front Door cobran en función de las consultas o solicitudes DNS procesadas. Front Door cobra adicionalmente por la transferencia de datos desde los PoP periféricos hasta los backends.
- ExpressRoute y VPN Gateway: los diseños multiregión suelen requerir instancias de puerta de enlace en cada región. Los circuitos ExpressRoute que conectan varias regiones agregan tarifas mensuales de puertos y cargos de datos medidos por GB.
- Optimice con la localidad del tráfico: Diseñe los niveles de la aplicación para minimizar las llamadas entre regiones. Mantenga las réplicas de lectura ubicadas junto con los recursos de proceso en cada región para reducir el ancho de banda de replicación y las consultas sensibles a la latencia.
Consideraciones de seguridad
Una red de varias regiones presenta consideraciones de seguridad más allá de las implementaciones de una sola región:
- El tráfico permanece en la red troncal de Microsoft. Todo el tráfico entre regiones que circula a través del emparejamiento global de redes virtuales o de la conectividad entre hubs de Virtual WAN atraviesa la red troncal de Microsoft, no la Internet pública.
- Implemente firewalls con redundancia de zona en cada región. Cada centro regional necesita su propia instancia de firewall para la inspección del tráfico. Despliegue cortafuegos en varias zonas de disponibilidad para mantener la seguridad durante los fallos de zona.
- Front Door WAF proporciona seguridad perimetral. Cuando se usa Front Door, su Web Application Firewall integrado inspecciona el tráfico antes de llegar a cualquier implementación regional. Esto proporciona una primera capa de defensa en el perímetro de la red.
- Planifique cuidadosamente el failover de DNS. La conmutación por error de Traffic Manager depende del TTL del DNS. Las TTL más cortas permiten una conmutación por error más rápida, pero aumentan el volumen de consultas DNS. Front Door proporciona una conmutación por error a nivel de conexión que no depende de la caducidad de la caché DNS del cliente.
- El tráfico de Global Reach de ExpressRoute permanece privado. El tráfico entre sitios locales conectados a través de Global Reach nunca toca la red pública de Internet. Permanece en la red troncal de Microsoft entre circuitos.
- Proteger los canales de replicación entre regiones. El tráfico de replicación de backend a través de Global VNet Peering es privado de forma predeterminada, pero se deben aplicar grupos de seguridad de red y cifrado para los datos confidenciales en tránsito.
Artículos relacionados
Si el diseño de varias regiones implica escenarios específicos que se tratan en otra parte de esta guía, consulte:
- Topología hub-and-spoke: patrón de diseño de hub por región para implementaciones multirregionales.
- Virtual WAN: Virtual WAN patrón de varios concentradores con enrutamiento automático entre concentradores.
- Conectividad entre regiones: instrucciones detalladas sobre el emparejamiento, Global Reach y las opciones de conectividad entre centros.
- Redes virtuales y subredes: diseño y planeamiento de subredes de red virtual por región.
- Planeamiento de direcciones IP: espacios de direcciones no superpuestos entre regiones.
- Azure Firewall e inspección de tráfico: implementación de un firewall con redundancia por zona en cada centro regional.
Aprende más
Para obtener más información sobre los servicios y conceptos descritos en este artículo, consulte los siguientes recursos:
- Introducción a Traffic Manager
- Introducción a Azure Front Door
- Visión general del emparejamiento de redes virtuales
- ExpressRoute Global Reach
- Virtual WAN arquitectura de red de tránsito global
- Regiones y zonas de disponibilidad de Azure
Pasos siguientes
Sugerencia
¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.
Siguiente paso en su proceso de lift-and-shift:
Conectarse a la red local: después de planear la recuperación ante desastres, establezca conectividad VPN o ExpressRoute a un entorno local.
A continuación en su proceso de modernización:
Diseñe sus patrones de entrada de tráfico de internet: determine cómo llega el tráfico de los clientes a sus aplicaciones en sus regiones principales y de respaldo.
Próximo paso en su proceso de migración entre nubes:
Configurar túneles cifrados en otras nubes: después de planear varias regiones, configure la conectividad VPN entre nubes.