Regiones de la zona de aterrizaje
En este artículo se explica cómo las zonas de aterrizaje usan regiones de Azure. La arquitectura de la zona de aterrizaje de Azure es independiente de la región, pero debe especificar regiones de Azure para poder implementarla. En la siguiente guía se describe cómo agregar una región a una zona de aterrizaje existente y también proporciona algunas consideraciones para cuando migre sus activos de Azure a otra región.
En algunas situaciones, debe implementar aplicaciones en varias regiones de Azure para admitir los requisitos empresariales de alta disponibilidad y recuperación ante desastres. Es posible que no tenga una necesidad inmediata de contar con aplicaciones de varias regiones, pero debe diseñar la plataforma de zona de aterrizaje de Azure de modo que admita varias regiones, especialmente para los servicios de conectividad, identidad y administración. Asegúrese de que puede habilitar y admitir rápidamente zonas de aterrizaje de aplicaciones de varias regiones.
Para más información, consulte Seleccionar regiones de Azure.
Zonas de aterrizaje y regiones de Azure
Las zonas de aterrizaje de Azure constan de un conjunto de recursos y configuraciones. Algunos de estos elementos, como grupos de administración, directivas y asignaciones de roles, se almacenan en un nivel de inquilino o grupo de administración dentro de la arquitectura de la zona de aterrizaje de Azure. Estos recursos no se implementan en una región determinada y, en su lugar, se implementan a nivel global. Aun así, debe especificar una región de implementación, porque Azure realiza un seguimiento de algunos de los metadatos de recursos en un almacén de metadatos regionales.
Otros recursos se implementan regionalmente. En función de su propia configuración de zona de aterrizaje, es posible que tenga algunos o todos los siguientes recursos implementados regionalmente:
- Un área de trabajo de registros de Azure Monitor, incluidas las soluciones seleccionadas
- Una cuenta de Azure Automation
- Grupos de recursos, para los demás recursos
Si implementa una topología de redes, también deberá seleccionar una región de Azure en la que implementar los recursos de redes. Esta región puede ser diferente de la región que se usa para los recursos enumerados en la lista anterior. Según la topología que seleccione, los recursos de redes que implemente pueden incluir:
- Azure Virtual WAN, incluido el centro de Virtual WAN
- Redes virtuales de Azure
- VPN Gateway
- Puerta de enlace de Azure ExpressRoute
- Azure Firewall
- Planes de Azure DDoS Protection
- Zonas DNS privadas de Azure, incluidas zonas para Azure Private Link
- Grupos de recursos, para contener los recursos mostrados anteriormente
Nota:
Para reducir el efecto de las interrupciones regionales, se recomienda ubicar recursos en la misma región que el grupo de recursos. Para obtener más información, consulte Alineación de la ubicación del grupo de recursos.
Añadir una nueva región a una zona de aterrizaje existente
Debe plantearse una estrategia de varias regiones, ya sea desde el inicio del recorrido de la nube o expandiéndose a más regiones de Azure cuando complete la implementación inicial de la arquitectura de la zona de aterrizaje de Azure. Por ejemplo, si usa Azure Site Recovery a fin de habilitar la recuperación ante desastres para las máquinas virtuales, es posible que quiera replicarlas en otra región de Azure. Para agregar regiones de Azure en la arquitectura de zona de aterrizaje de Azure, tenga en cuenta las siguientes recomendaciones:
| Área | Recomendación |
|---|---|
| Grupos de administración | No es necesaria ninguna acción. Los grupos de administración no están vinculados a una región. No debe crear una estructura de grupo de administración basada en regiones. |
| Suscripciones | Las suscripciones no están vinculadas a una región. |
| Azure Policy | Realice cambios en Azure Policy si asignó directivas para denegar la implementación de recursos en todas las regiones especificando una lista de regiones de Azure "permitidas". Actualice estas asignaciones para permitir implementaciones de recursos en la nueva región que quiere habilitar. |
| Control de acceso basado en rol (RBAC) | No es necesaria ninguna acción. RBAC de Azure no está asociado a ninguna región. |
| Supervisión y registro | Decida si va a usar una única área de trabajo de registros de Azure Monitor para todas las regiones o va a crear varias áreas de trabajo para cubrir distintas regiones geográficas. Cada planteamiento tiene ventajas e inconvenientes, incluidos posibles cargos de red entre regiones. Para saber más, consulte Diseño de una arquitectura de área de trabajo de Log Analytics. |
| Redes | Si implementa una topología de redes, Virtual WAN o de tipo radial tradicional, expanda las redes a la nueva región de Azure. Cree otro centro de redes mediante la implementación de los recursos de red necesarios en la suscripción de conectividad existente en la nueva región de Azure. Azure Virtual Network Manager puede facilitar la expansión y administración de redes virtuales a escala en varias regiones. Desde una perspectiva de Sistema de nombres de dominio (DNS), es posible que también quiera implementar reenviadores, si los usa, en la nueva región de Azure. Use reenviadores para las redes virtuales de tipo spoke en la nueva región con fines de resolución. Las zonas de Azure DNS son recursos globales y no están vinculados a una sola región de Azure, por lo que no requieren ninguna acción. |
| Identidad | Si ha implementado Active Directory Domain Services o Microsoft Entra Domain Services en la suscripción o radio de identidad, expanda el servicio en la nueva región de Azure. |
Nota:
También puede usar zonas de disponibilidad para lograr una alta disponibilidad dentro de una región. Compruebe si las regiones de Azure admiten zonas de disponibilidad y cómo los servicios que usa admiten zonas de disponibilidad.
Microsoft Cloud for Sovereignty tiene directrices para restringir los servicios y las regiones. Puede utilizar estas directrices para imponer la configuración del servicio y ayudar a los clientes a satisfacer sus necesidades de residencia de datos.
Enfoque de alto nivel
Al expandir una zona de aterrizaje de Azure a una nueva región, considere la posibilidad de seguir los pasos descritos en estas secciones. Antes de empezar, debe decidir en una nueva región de Azure o en varias regiones de Azure para expandirse.
Redes
Arquitectura radial tradicional
Sugerencia
Vea una arquitectura radial tradicional.
Decida si necesita una nueva suscripción de zona de aterrizaje de la plataforma. Se recomienda que la mayoría de los clientes usen sus suscripciones de conectividad existentes, incluso cuando usan varias regiones.
En la suscripción, cree un nuevo grupo de recursos en la nueva región de destino.
Cree un centro de conectividad Virtual Network en la nueva región de destino.
Si procede, implemente Azure Firewall o aplicaciones virtuales de red (NVA) en el nuevo centro de conectividad Virtual Network.
Si procede, implemente puertas de enlace de Virtual Network para la conectividad VPN o ExpressRoute y establezca conexiones. Asegúrese de que los circuitos ExpressRoute y las ubicaciones locales siguen las recomendaciones de resistencia de Microsoft. Para obtener más información, consulte Diseño para la recuperación ante desastres con el emparejamiento privado de ExpressRoute.
Establezca el emparejamiento de red virtual entre el nuevo centro de conectividad de red virtual y los demás centros de conectividad de redes virtuales.
Cree y configure cualquier enrutamiento necesario, como Azure Route Server o rutas definidas por el usuario.
Si procede, implemente reenviadores DNS para la nueva región de destino y vincúlelos a cualquier zona DNS privada para habilitar la resolución de nombres.
- Algunos clientes pueden configurar su resolución de nombres en sus controladores de dominio de Windows Server Active Directory en la suscripción de la zona de aterrizaje de la plataforma de identidad.
Para hospedar las cargas de trabajo, luego puede usar el emparejamiento de red virtual para conectar radios de zona de aterrizaje de aplicaciones con la nueva red virtual de centro en la nueva región.
Sugerencia
Virtual Network Manager puede facilitar la expansión y administración de redes virtuales a gran escala en varias regiones.
Arquitectura de Virtual WAN
Sugerencia
Vea una Arquitectura de Virtual WAN.
En el Virtual WAN existente, cree un centro virtual en la nueva región de destino.
Implemente Azure Firewall u otras aplicaciones virtuales de red (NVA) admitidas en el nuevo centro virtual. Configure directivas de intención y enrutamiento de Virtual WAN para enrutar el tráfico mediante el nuevo centro virtual protegido.
Si procede, implemente puertas de enlace de Virtual Network para la conectividad VPN o ExpressRoute en el nuevo centro virtual y establezca conexiones. Asegúrese de que los circuitos ExpressRoute y las ubicaciones locales siguen las recomendaciones de resistencia de Microsoft. Para obtener más información, consulte Diseño para la recuperación ante desastres con el emparejamiento privado de ExpressRoute.
Cree y configure cualquier otro enrutamiento que necesite, como las rutas estáticas del centro virtual.
Si procede, implemente reenviadores DNS para la nueva región de destino y vínculo a cualquier zona DNS privada para habilitar la resolución.
Algunos clientes pueden configurar su resolución de nombres en sus controladores de Dominio de Active Directory en la suscripción de la zona de aterrizaje de la plataforma de identidad.
En implementaciones de Virtual WAN, esto debe estar en una red virtual de radios conectada al centro virtual mediante una conexión de red virtual, según el patrón de extensión de centro de conectividad virtual.
Para hospedar las cargas de trabajo, luego puede usar el emparejamiento de red virtual para conectar radios de zona de aterrizaje de aplicaciones con la nueva red virtual de centro en la nueva región.
Identidad
Sugerencia
Revise el área de diseño de la zona de aterrizaje de Azure para la administración de identidades y acceso.
Decida si necesita una nueva suscripción de zona de aterrizaje de la plataforma. Se recomienda que la mayoría de los clientes usen sus suscripciones de identidad existentes, incluso cuando usan varias regiones.
Creación de un nuevo grupo de recursos en la nueva región de destino.
Creación de un Virtual Network en la nueva región de destino.
Establecimiento del emparejamiento de red virtual con el centro de conectividad regional de red virtual recién creado en la suscripción de conectividad.
Implementación de cargas de trabajo de identidad, como máquinas virtuales del controlador de dominio de Active Directory en nuevas redes virtuales.
Es posible que tenga que realizar una configuración adicional de las cargas de trabajo una vez aprovisionadas, como los siguiente pasos de configuración:
Promocionar las máquinas virtuales del controlador de dominio de Active Directory al dominio de Active Directory existente.
Crear nuevos sitios y subredes de Active Directory.
Configurar las opciones del servidor DNS, como reenviadores condicionales.
Trasladar sus activos de Azure a una nueva región
En ocasiones, puede que tenga que mover todos sus activos de Azure a otra región. Pongamos un ejemplo: ha implementado la zona de aterrizaje y las cargas de trabajo en una región de Azure en un país o región vecinos y, después, se establece una nueva región de Azure en su país o región principal. En ese caso, podría mover todas las cargas de trabajo a la nueva región para mejorar la latencia de comunicación o cumplir los requisitos de residencia de datos.
Nota:
En este artículo se proporciona información sobre cómo migrar los componentes de la zona de aterrizaje de sus activos. Para obtener más información, vea Reubicación de cargas de trabajo en la nube.
Configuración de la zona de aterrizaje global
Cuando se mueven regiones, no suele ser necesario modificar la mayoría de las configuraciones de la zona de aterrizaje implementadas globalmente. De todas formas, compruebe si hay asignaciones de directiva que restrinjan las implementaciones de regiones y actualice la directiva para permitir las implementaciones en la nueva región.
Recursos de la zona de aterrizaje regional
Los recursos de zona de aterrizaje específicos de la región suelen requerir más reflexión, ya que algunos recursos de Azure no se pueden mover entre regiones. Este es un planteamiento a tener en cuenta:
Agregue la región de destino como una región adicional a la zona de aterrizaje: para obtener más información, vea Incorporación de una nueva región a una zona de aterrizaje existente.
Implemente componentes centralizados en la región de destino: por ejemplo, implemente una nueva área de trabajo de registros de Azure Monitor en la región de destino para que las cargas de trabajo puedan empezar a usar el nuevo componente después de migrar la carga de trabajo.
Migre las cargas de trabajo de la región de origen a la de destino: durante el proceso de migración de la carga de trabajo, vuelva a configurar los recursos para usar los componentes de red de la región de destino, los componentes de identidad, el área de trabajo de registros de Azure Monitor y otros recursos regionales.
Retire los recursos de la región de origen una vez completada la migración.
Tenga en cuenta las recomendaciones siguientes al migrar recursos de zona de aterrizaje entre regiones:
Use una infraestructura como código: use Bicep, plantillas de Azure Resource Manager (plantillas de ARM), Terraform, scripts o un enfoque similar para exportar y volver a importar las configuraciones complejas, como las reglas para Azure Firewall.
Automation: use scripts para migrar recursos de Automation entre regiones.
ExpressRoute: plantéese si puede usar la SKU de ExpressRoute Local en la región de destino. Si los entornos locales están dentro de la misma área metropolitana que la región de Azure, ExpressRoute Local puede proporcionar una opción de menor coste en comparación con otras SKU de ExpressRoute.