Migración de una carga de trabajo en la nube a otra región
El paso migrar de reubicación es donde se mueve la carga de trabajo a la nueva región. En función de su carga de trabajo, es posible que tenga algunos requisitos técnicos para prepararse, pero la estrategia de reubicación de la carga de trabajo debe estar clara. Debe estar listo para ejecutar la reubicación.
Preparación
Antes de iniciar la reubicación de la carga de trabajo, es necesario preparar la región de destino. Según sea necesario, siga estos pasos para preparar el entorno de carga de trabajo antes de la reubicación. Al hacerlo, se asegurará de que tiene redes regionales principales en su lugar, como un centro regional y, si es necesario, la conectividad entre locales.
Establezca una zona de aterrizaje. Al planear el traslado, evalúe si amplía el ámbito de la zona de aterrizaje de Azure. Si es necesaria la expansión, consulte la guía de la zona de aterrizaje de Azure como paso fundamental. Este paso garantiza que el enfoque se alinee con los procedimientos recomendados establecidos. Para más información, consulte Incorporación de una nueva región a una zona de aterrizaje de Azure existente. Entre las consideraciones importantes para configurar la nueva zona de aterrizaje se incluyen:
- Redes: evalúe la estructura de red, las rutas de enrutamiento y los requisitos de conectividad para la zona de aterrizaje en la nueva región.
- Integración: determine si es necesario integrar la nueva zona de aterrizaje con la de la región de origen.
- Reubicación selectiva de recursos: decida si todos los recursos se mueven a la nueva región. Si algunos recursos permanecen en la ubicación original, planee una topología de red entre regiones sostenible para administrar estos recursos distribuidos de forma eficaz.
Cree nuevas suscripciones solo si es necesario. Cree solo nuevas suscripciones si necesita reestructurar los servicios y los recursos implicados. Intente mantener la carga de trabajo en su suscripción existente, si es posible, ya que la creación de una nueva suscripción agrega complejidad. Las suscripciones sirven como límites para los presupuestos, las directivas y los controles de acceso basados en roles (RBAC). Para cualquier nueva suscripción, debe validar presupuestos, directivas y RBAC. Si no mueve todos los recursos de una suscripción, debe volver a definir el ámbito de las directivas de identidad y seguridad para que coincidan con la agrupación más pequeña de recursos. Para crear una nueva suscripción, debe crear, definir el ámbito e implementar las directivas de Azure y los roles RBAC necesarios en la suscripción de destino. El objetivo es mantener la posición de gobernanza y seguridad.
Configure un nuevo nombre de dominio si es necesario. Cuando haya un cambio en el dominio personalizado de la carga de trabajo, debe configurar un nuevo nombre de dominio. Cree el nuevo nombre de host, asígnelo a su aplicación o servicio y, a continuación, valide la resolución de nombres. También puede planear reducir y configurar el período de vida (TTL) y establecerlo en la fase de transición para la expiración automática. Para obtener más información, consulte Adición del dominio personalizado y Asignación del nombre DNS al plan de App Service.
Cree nuevos certificados SSL/TLS si es necesario. Debe crear nuevos certificados SSL/TLS (X.509) para cualquier nuevo nombre de dominio. Estos certificados habilitan el cifrado de claves pública-privada y la comunicación de red segura (HTTPS). Use Azure Key Vault para crear o importar certificados X.509. Para más información, consulte certificados Azure Key Vault y métodos de creación de certificados
Reubicar Azure Key Vault. Debe reubicar Azure Key Vault antes de mover la carga de trabajo. Debe tener un almacén de claves por entorno de aplicación y su almacén de claves no debe compartir secretos entre regiones para garantizar la confidencialidad. Es posible que tenga que crear un nuevo almacén de claves en la nueva región de destino para alinearse con esta guía.
Cree un área de trabajo de Log Analytics. Debe tener un área de trabajo de Log Analytics independiente para cada región. Cree una nueva área de trabajo en la región de destino. Dado que no se puede mover un área de trabajo de Log Analytics a otra región, debe crear un área de trabajo de Log Analytics en la región de destino. Hay dos opciones para conservar los datos en el área de trabajo original. Puede mantener el área de trabajo actual hasta que no necesite los datos, tratando los datos como de solo lectura. También puede exportar los datos del área de trabajo a una cuenta de almacenamiento en la nueva región de Azure de destino.
Migrar servicios
Puede empezar a migrar los servicios de su carga de trabajo. Para su ejecución, siga las instrucciones disponibles para la automatización de reubicación seleccionada. Azure Resource Mover y Azure Site Recovery tienen tutoriales paso a paso que deben seguirse para la reubicación del servicio. Para más información, vea:
Puede crear plantillas o scripts de infraestructura como código para los recursos que no se pueden mover. También puede ejecutar implementaciones manualmente en Azure Portal. Los pasos específicos que siga dependen de los servicios de Azure que use y su configuración. Para más información, consulte información general de infraestructura como código.
Migración de los datos
Esta fase solo es relevante cuando la carga de trabajo requiere la migración de datos. Realice la migración de datos con la automatización elegida. Antes de la transición a la carga de trabajo en la región de destino, debe asegurarse de que los datos relacionados estén sincronizados con la región de origen. La coherencia de los datos es un aspecto importante que requiere cuidado. Estas son las instrucciones para migrar datos de carga de trabajo.
Migrar los datos de la región de origen. El enfoque para migrar datos de región de origen debe seguir el método de reubicación para el servicio de carga de trabajo. Los métodos calientes, fríos e intermedios tienen diferentes procesos para administrar los datos en la región de origen.
Sincronizar datos. La técnica de sincronización depende de la arquitectura de la carga de trabajo y de la demanda de la aplicación. Por ejemplo, en una sincronización a petición, los cambios se extraen cuando se accede a los datos por primera vez. La extracción y combinación de cambios solo se produce en los casos en los que hay una diferencia entre el último y el acceso actual a la aplicación.
Solucionar los conflictos de sincronización. Asegúrese de que los datos de la ubicación de origen y destino estén sincronizados y resuelvan los conflictos de datos. Solo quiere que los usuarios intenten acceder a los datos que están disponibles. Por ejemplo, Azure Cosmos DB puede serializar escrituras simultáneas para garantizar la coherencia de los datos.
Actualización de cadenas de conexión
La configuración de la cadena de conexión depende del servicio al que se conecta la aplicación. Puede buscar "cadena de conexión" en nuestra página de documentación para encontrar la guía específica del servicio y usarla para actualizar la cadena de conexión. Para más información, consulte la documentación técnica.
Identidades administradas
Las identidades administradas asignadas por el sistema tienen un ciclo de vida enlazado al recurso de Azure. Por lo tanto, la estrategia de reubicación del recurso de Azure determina cómo se controla la identidad administrada asignada por el sistema. Si se crea una nueva instancia del recurso en el destino, debe conceder a la nueva identidad administrada asignada por el sistema los mismos permisos que la identidad administrada asignada por el sistema en la región de origen.
Por otro lado, la identidad administrada asignada por el usuario tiene un ciclo de vida independiente y puede asignar la identidad administrada asignada por el usuario al nuevo recurso de la región de destino. Para más información, consulte Introducción a la identidad administrada.
Pasos siguientes
Ha migrado los datos y los servicios de carga de trabajo. Ahora debe completar la reubicación con una transición.