Traslado de recursos de Azure entre regiones

Microsoft Entra
Azure ExpressRoute
Azure Load Balancer
Azure VPN Gateway

Esta solución mueve recursos de Azure entre regiones de forma eficaz, segura y sin problemas. Consulte los pasos clave, las consideraciones y las estrategias para planear y llevar a cabo un movimiento.

Architecture

Diagrama que muestra el flujo de datos de la solución de traslado de recursos de Azure entre regiones.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

  • Red del centro de datos local: una red de área local privada que se ejecuta dentro de una organización para admitir los recursos locales.

  • Circuito ExpressRoute: Las conexiones de ExpressRoute utilizan una conexión privada y dedicada a través de un proveedor de conectividad de terceros. La conexión privada amplía una red local a Azure.

  • Enrutadores perimetrales locales: enrutadores que conectan la red local al circuito administrado por el proveedor externo. En función de cómo haya aprovisionado la conexión, es posible que tenga que proporcionar las direcciones IP públicas que los enrutadores usan.

  • Enrutadores perimetrales de Microsoft: Dos enrutadores en una configuración de alta disponibilidad activa/activa. Estos enrutadores permiten a un proveedor de conectividad externo conectar sus circuitos directamente a su centro de datos. En función de cómo haya aprovisionado la conexión, es posible que tenga que proporcionar las direcciones IP públicas que los enrutadores usan.

  • VPN Gateway: al usar el servicio de puerta de enlace de VPN, puede conectar la red virtual a la red local.

  • Subred de Active Directory: La mayoría de las organizaciones empresariales tienen un entorno de Active Directory Domain Services (AD DS) en su centro de datos local. Para facilitar la administración de los recursos que se han migrado a Azure desde la red local que depende de AD DS, considere la posibilidad de hospedar controladores de dominio de AD DS en Azure en un centro de red virtual (VNET) central al que puedan tener acceso las cargas de trabajo dependientes.

  • Emparejamiento de VNET: varias redes virtuales con emparejamiento entre ellas. El emparejamiento de VNET permite agrupar aplicaciones en las redes virtuales correspondientes, y proporciona una conexión de alto ancho de banda y baja latencia.

  • Aplicaciones web de varios niveles que se ejecutan en el entorno de nube: esta arquitectura de ejemplo se aplica a muchos sectores que necesitan implementar aplicaciones resistentes de niveles capas en la nube. En este escenario, la aplicación consta de tres niveles:

    • Nivel web: el nivel superior, incluida la interfaz de usuario. Este nivel analiza las interacciones del usuario y pasa las acciones al siguiente nivel para su procesamiento.
    • Nivel de negocio o aplicación: procesa las interacciones de usuario y toma decisiones lógicas sobre los pasos siguientes. Este nivel conecta el nivel web con el nivel de datos.
    • Capa de datos: almacena los datos de la aplicación. En este caso, una base de datos SQL almacena los datos.

  • Equilibrador de carga interno: el tráfico de red de la puerta de enlace VPN se enruta a la aplicación en la nube a través de un punto de conexión de equilibrador de carga interno (ILB), que se encuentra en la subred de los niveles de la aplicación.

  • Recursos de plataforma como servicio (PaaS) : en este entorno de ejemplo, hay algunos servicios PaaS, como Azure IoT Hub, Azure Key Vault y Azure App Service.

Componentes

La arquitectura de ejemplo utiliza los siguientes componentes:

Detalles del escenario

Dado el crecimiento de Microsoft Azure y su evolución en el conjunto de regiones en todo el mundo, los clientes tienen la necesidad de mover las implementaciones de una región a otra. Mover las aplicaciones entre regiones es una actividad que exige un plan bien pensado, para asegurarse de mover todos los recursos sin problemas y que las aplicaciones estén en funcionamiento en la nueva región con un tiempo de inactividad mínimo.

Las recomendaciones y la arquitectura de este ejemplo ofrecen instrucciones sobre cómo mover recursos de Azure entre regiones de forma eficaz, segura y sin problemas.

Posibles casos de uso

Algunas de las principales razones para mover recursos a otra región incluyen los siguientes casos:

  • Alineación con el lanzamiento de una región: mueva los recursos a una región de Azure que acaba de incorporar y que no estaba disponible previamente.
  • Alineación con servicios o características: mueva recursos para aprovechar las ventajas de los servicios o las características que están disponibles en una región específica.
  • Respuesta a desarrollos empresariales: mueva recursos a una región en respuesta a cambios empresariales, como fusiones o adquisiciones.
  • Alineación para proximidad: mueva recursos a una región que sea local para la empresa.

Pasos para mover recursos entre regiones

Puesto que los requisitos pueden diferir de la arquitectura de ejemplo, use las siguientes recomendaciones como punto de partida:

  1. Comprobar los requisitos previos para el traslado.

    • Tiempo de inactividad planeado: planifique el traslado de región como una actividad de mantenimiento con tiempo de inactividad programado para minimizar el impacto a los clientes.

    • Límites y cuotas de suscripción de Azure: asegúrese de que su suscripción tenga suficientes recursos para admitir el tipo de recurso específico. Por ejemplo, asegúrese de que la región de destino admita máquinas virtuales con tamaños que coincidan con las máquinas virtuales de la región de origen. Si es preciso, póngase en contacto con el soporte técnico para habilitar la cuota necesaria. Para obtener más información, consulte Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

    • Permisos de cuenta: si ha creado una cuenta de Azure gratis, ya es el administrador de la suscripción. Si no es el administrador de la suscripción, solicite al administrador que le asigne los permisos que necesita para mover los recursos. Compruebe que la suscripción de Azure le permite crear el recurso necesario en la región de destino.

    • Identificación de recursos: identifique y clasifique los recursos en función del tipo de recurso necesario para exportar una plantilla de Azure Resource Manager o para iniciar la replicación mediante diversas tecnologías. Para cada uno de los tipos de recursos que quiera mover, los pasos pueden ser diferentes. Consulte Movimiento de recursos de Azure entre regiones para conocer los pasos correspondientes para cada uno de los tipos de recursos.

  2. Mover los componentes de red.

    • Grupos de seguridad de red: no puede mover grupos de seguridad de red de una región a otra. Sin embargo, puede usar una plantilla de Resource Manager para exportar las reglas de seguridad y configuración existentes de un grupo de seguridad de red. Después, para preparar el recurso en otra región, puede exportar el grupo a una plantilla, modificar los parámetros para que coincidan con la región de destino y, a continuación, implementar la plantilla en la nueva región.

    • Red virtual: Puede usar una plantilla de Azure Resource Manager para completar el traslado de la red virtual a otra región. Exporte la red virtual a una plantilla, modifique los parámetros para que coincidan con la región de destino y, a continuación, implemente la plantilla en la región nueva.

    • Emparejamiento de redes virtuales: el emparejamiento de VNET no se volverá a crear, y se producirá un error en las redes del mismo nivel si todavía están presentes en la plantilla. Antes de exportar la plantilla, quite las redes virtuales del mismo nivel. Podrá restablecerlos después de mover la red virtual.

    • Direcciones IP públicas: dado que las direcciones IP públicas de Azure son específicas de la región, no puede moverlas de una región a otra. Sin embargo, puede usar una plantilla de Resource Manager para exportar las reglas de seguridad y configuración existentes de un grupo de seguridad de red. Después, para preparar el recurso en otra región, puede exportar el grupo a una plantilla, modificar los parámetros para que coincidan con la región de destino y, a continuación, implementar la plantilla en la nueva región.

  3. Mover los componentes de aplicación.

  4. Mover servicios PaaS: los servicios PaaS tienen sus propios pasos específicos para orquestar el movimiento. Para obtener la información más reciente sobre la lista de servicios admitidos, consulte Compatibilidad con el movimiento de recursos de Azure entre regiones.

  5. Mover la infraestructura local: para asegurarse de que la región de origen completa se recree en la región de destino, vuelva a establecer y configure los componentes locales tal como estaban antes y conéctelos a la red de Azure.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Tenga en cuenta los siguientes puntos al mover entre regiones:

  • El plan de migración entre regiones debe tener en cuenta una infraestructura compleja. Los entornos de infraestructura modernos suelen ir de la infraestructura local a la nube. Algunos incluso tienen un nivel de complejidad adicional, con una estrategia multinube que contiene implementaciones públicas o privadas.

  • Mueva los tipos de recursos juntos. Al combinar el movimiento de tipos de recursos similares (por ejemplo, 50 máquinas virtuales o 20 bases de datos SQL), puede planear el paso de preparación del movimiento más fácilmente y asegurarse de que las operaciones de ejecución prolongada se completan juntas, lo que ayuda a reducir el tiempo de inactividad.

  • Mueva juntos todos los recursos dentro de una aplicación. Puede seleccionar los recursos de una aplicación e intentar moverlos juntos en un conjunto para asegurarse de poder trasladar la aplicación a la región de destino de manera orquestada.

  • Asegúrese de que cubre sus necesidades de capacidad. La posibilidad de comprobar la capacidad o la cuota está disponible en la región de destino para admitir el crecimiento empresarial actual y potencial antes del movimiento real.

  • Debe haber un impacto mínimo o nulo en la infraestructura o las aplicaciones críticas para la empresa actuales en la región de origen mientras el movimiento está en curso.

  • Para garantizar la continuidad empresarial, debe tener un entorno funcional en funcionamiento en la región de destino con el menor tiempo de inactividad posible.

  • La posibilidad de validar la migración antes de la confirmación final en el lado de destino es fundamental, en especial si se admiten cargas de trabajo de nivel 0 y nivel 1 en el sector de servicios financieros (FSI) o en el vertical de asistencia sanitaria.

  • Asegúrese de realizar la diligencia debida; para ello, pruebe y valide las configuraciones originales, la conectividad, la adecuada configuración de seguridad, las directivas, la replicación de datos y las conexiones de bases de datos antes de confirmar el movimiento a la región de destino.

  • Después de mover los recursos al destino, realice los cambios finales siguientes para asegurarse de que la configuración final esté en funcionamiento:

    • Cambie la configuración de DNS para que apunte a una nueva dirección IP.
    • Elimine los recursos de la región de origen para evitar una doble facturación y evitar problemas debido a la existencia de dos conjuntos de datos independientes con un ámbito y configuración superpuestos.
    • Elimine los recursos auxiliares creados para el movimiento. Por ejemplo, elimine las cuentas de almacenamiento que se usaron para la transferencia intermedia.

Pasos siguientes