Rehosting con Azure Migrate (Lift and Shift)

Rehost, comúnmente denominado Lift and Shift, es la estrategia de migración que consiste en trasladar una máquina virtual del entorno local a Azure sin modificar el sistema operativo, los binarios de la aplicación ni los datos. La herramienta Migration and Modernisation de Azure Migrate (anteriormente Server Migration) automatiza este proceso replicando los datos de los discos en Azure y realizando después el cambio con un tiempo de inactividad mínimo. Lift and Shift es ideal para aplicaciones que no se pueden refactorizar fácilmente o que tienen plazos de migración ajustados.

Antes de iniciar la replicación, debe: completar la detección y la evaluación para disponer de recomendaciones de SKU de máquinas virtuales de destino, crear los recursos de Azure de destino (grupo de recursos, red virtual y subred) y asegurarse de que el dispositivo de Azure Migrate funciona correctamente. En el caso de orígenes de VMware, el dispositivo debe tener permisos de lectura en vCenter y la máquina virtual invitada debe ser accesible por red desde el dispositivo. Descargue y registre el software Replication Provider si va a migrar desde Hyper-V o servidores físicos.

La replicación copia todos los datos de los discos de la máquina virtual de origen en una cuenta de almacenamiento de caché administrada por Azure y, a continuación, prepara los datos de forma asíncrona en Azure. En el portal de Azure Migrate, vaya a Replicate, seleccione las máquinas virtuales de origen, asígnelas al SKU de máquina virtual de Azure recomendado y elija la red virtual de destino. El tiempo de la replicación inicial depende del tamaño del disco y del ancho de banda: un disco de 100 GB mediante una conexión de 100 Mbps tarda aproximadamente 2 horas en realizar la sincronización inicial.

Después de copiar la imagen inicial del disco, Azure Migrate cambia a la replicación delta: solo se envían los bloques de disco modificados, lo que mantiene la copia de Azure sincronizada casi en tiempo real con el origen local. La máquina virtual sigue ejecutándose en el entorno local durante esta fase. Puede supervisar el estado de la replicación, el retraso del RPO y las tasas de transferencia de datos en el portal. Normalmente, la replicación delta se estabiliza con solo unos minutos de retraso en las 24 horas posteriores a la finalización de la sincronización inicial.

Antes de cambiar el tráfico de producción, ejecute siempre una migración de prueba. Esta operación inicia la máquina virtual replicada en Azure dentro de una red virtual de prueba aislada que no tiene conectividad con los sistemas de producción. Compruebe que el sistema operativo se inicia, que los servicios arrancan y que la aplicación funciona según lo esperado. Las migraciones de prueba no interrumpen la replicación local: la máquina virtual de origen sigue ejecutándose. Después de la prueba, elimine los recursos de prueba en el portal para evitar cargos innecesarios.

El cambio es el paso final que traslada el tráfico de producción del entorno local a Azure. Durante el cambio, la máquina virtual de origen se detiene (o usted la apaga manualmente), se aplican los cambios delta restantes a la réplica de Azure y se inicia la nueva máquina virtual de Azure. Como se trata de una migración a nivel de almacenamiento, el cambio suele ser muy rápido: menos de 10 minutos para la mayoría de las máquinas virtuales. Programe el cambio durante una ventana de mantenimiento y comuníquelo previamente a las partes interesadas de la aplicación.

En el portal de Azure Migrate, haga clic en Migrate para el servidor seleccionado. Se le preguntará si desea apagar la máquina virtual local antes de la migración (se recomienda para evitar la pérdida de datos). Azure aplica el delta final, crea la máquina virtual de Azure y marca la migración como completada. A continuación, debe actualizar los registros DNS, los backends del equilibrador de carga o las cadenas de conexión de la aplicación para que apunten a la nueva IP privada o FQDN de Azure, de modo que los clientes empiecen a utilizar la máquina virtual de Azure.

Después del cambio, realice estas comprobaciones posteriores a la migración: estado de la aplicación (cargue todas las páginas de la aplicación y ejecute pruebas de humo), conectividad (compruebe que la máquina virtual de Azure puede acceder a las bases de datos y servicios dependientes), supervisión (instale el agente de Azure Monitor y habilite los diagnósticos) y copias de seguridad (inscriba la máquina virtual en Azure Backup). Si detecta problemas, puede reiniciar la máquina virtual de origen local, que seguirá intacta hasta que la retire explícitamente.

Una vez que la máquina virtual migrada sea estable en Azure y las partes interesadas hayan dado su aprobación, puede retirar la máquina virtual de origen local. En Azure Migrate, seleccione Complete Migration para cerrar la replicación. Esto no apaga automáticamente la máquina virtual local: debe apagarla y recuperar el hardware mediante el proceso habitual de gestión de activos de TI. La retirada reduce los costes de infraestructura local y le acerca a un modelo operativo exclusivamente en la nube.

Para migraciones grandes que impliquen cientos de máquinas virtuales, Azure Migrate admite operaciones masivas mediante la importación de CSV. Prepare un CSV que incluya cada máquina virtual de origen, su SKU de destino, el grupo de recursos de destino y la red virtual; después, cárguelo para iniciar la replicación de todas las máquinas virtuales simultáneamente. Los grupos de migración permiten secuenciar la replicación y el cambio para que las capas de aplicación dependientes (base de datos, aplicación y web) se migren en el orden correcto dentro de la misma ventana de mantenimiento.

Preste atención a estos problemas habituales de Lift and Shift: el cifrado del disco de arranque en máquinas virtuales Linux puede impedir que Azure las inicie (use Azure Disk Encryption después de la migración); las direcciones IP estáticas codificadas en las configuraciones de las aplicaciones deben actualizarse a las IP privadas o los nombres DNS de Azure; las reglas de firewall locales que hagan referencia a la IP del servidor pueden tener que replicarse en un NSG de Azure; y la configuración de zona horaria en máquinas virtuales Windows puede provocar cambios en el comportamiento de las aplicaciones en el entorno UTC de Azure.

Ponga a prueba su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que el flujo de migración Rehost pasa de la replicación a la sincronización delta, la migración de prueba y el cambio; la migración de prueba valida la máquina virtual en una red aislada antes de ponerla en producción; y los pasos posteriores a la migración (supervisión, copias de seguridad y actualización de DNS) son esenciales antes de retirar los recursos locales. A continuación, veremos las prácticas recomendadas para migrar bases de datos a Azure.