Blog de Amazon Web Services (AWS)

Migración de máquinas virtuales (VMs) de VMWare a Amazon EC2 con el Agente de Réplica de AWS Application Migration Service

Por Philippe Wanner, Arquitecto de Soluciones Especialista Sénior en AWS y Simon Vaillancourt, Arquitecto de Soluciones Especialista Sénior en Amazon Web Services (AWS).

Traducción del blog original Migrate VMware virtual machines (VMs) to Amazon EC2 with the AWS Application Migration Service Replication Agent

Introducción

En este blog post, se presenta una guía paso a paso para migrar máquinas virtuales (VM) de VMware a Amazon Elastic Compute Cloud (Amazon EC2) utilizando el servicio AWS Application Migration Service. Además, se muestra cómo aplicar un post-launch action script personalizado, que permite automatizar y ejecutar tareas sobre un servidor después de lanzarse en AWS, para eliminar las herramientas propietarias de VMware de las VMs migradas.

La migración de cargas de trabajo VMware on-premises a Amazon EC2 puede proporcionar beneficios significativos, incluyendo mayor escalabilidad, mejor rendimiento y reducción de costes operativos. Application Migration Sevice simplifica este proceso al ofrecer una solución fluida y automatizada de réplica a nivel de bloque de volúmen para migrar VMs de VMware a instancias de Amazon EC2. Las VMs migradas pueden lanzarse y probarse en Amazon EC2 mientras continúa la replicación del servidor original. Esta solución utiliza la opción de replicación basada en agentes, ya que proporciona réplica continua de datos y reduce la ventana de cutover/ventana de corte, durante la que se lanzan las instancias EC2 con la información más actualizada de la VM de origen.

Arquitectura de la solución

Esta solución (Figura 1) sigue las directrices de la documentación, de configuración de red para Application Migration Service, configurando la subred dedicada para el servicio, denominada Staging Area. Sirve como área de preparación para la replicación de datos desde los servidores de origen. Las instancias de prueba y de transición se lanzan en otra subred dedicada, denominada Migrated Resources.

Los Agentes de Replicación de AWS instalados en las VMs de VMware inician el proceso de sincronización y comienzan la réplica de datos en el Staging Area. La réplica es gestionada por servidores de replicación basados en la configuración de replicación predefinida. Cuando los volúmenes conectados a los servidores de origen son replicados, el servidor se marca como Ready for Testing (Listo para Pruebas). Sobre la configuración de lanzamiento, las respectivas instancias de prueba o de transición se lanzan en el área de Migrated Resources.

Esta solución aprovecha las post-launch actions (acciones posteriores al lanzamiento de la instancia EC2) del Servicio de Migración de Aplicaciones para instalar el agente de AWS Systems Manager (AWS SSM) en cada instancia de prueba (test instance) o de transición (cutover instanwice) lanzada. El agente de AWS SSM permite la ejecución de scripts personalizados, como la eliminación de las herramientas propietarias de VMware.

Figura 1 – A la izquierda, el entorno VMware con los Agentes de Replicación de AWS instalados. A la derecha, la cuenta de AWS con sus dos subredes dedicadas: Staging Area (Zona de Preparación) y Migrated Resources (Zona de Recursos Migrados).

Para fines de demostración, esta solución utiliza un conjunto de máquinas virtuales Linux (RHEL 9) y Windows Server 2019.

Implementación

Paso 1 – Requisitos previos

Para esta guía, necesitarás:

  1. Un usuario de AWS con los permisos requeridos, así como la configuración de los permisos necesarios e inicializción del Application Migration Service.
  2. Configuración de red tal y como se define en requisitos de configuración de red
  3. Un sistema operativo de servidor de origen compatible. Para más información sobre sistemas operativos compatibles, consulte Sistemas Operativos compatibles.
  4. Credenciales de máquina virtual de origen con permisos para descargar e instalar el Agente de Replicación de AWS.
  5. Identificar o crear una subred de Amazon Virtual Private Cloud (Amazon VPC) para usar en sus instancias de prueba y de transición junto con los respectivos grupos de seguridad de Amazon EC2.

Paso 2 – Crear los VPC endpoints

La zona de preparación y la zona de recursos migrados pueden ejecutarse en una subred privada o pública. En este escenario, ambas subredes son privadas. Sin acceso público a ningún punto de enlace HTTPS, las instancias lanzadas no pueden conectarse a internet y, por lo tanto, no pueden ejecutar la plantilla posterior al lanzamiento. Para permitir la instalación del Agente SSM y la ejecución de las post-launch actions (acciones posteriores al lanzamiento de la instancia EC2), es necesario crear tres VPC Endpoints (punto de enlace):

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ec2messages
com.amazonaws.<region>.ssmmessages

1. Para cada punto de enlace a crear, abre el servicio de Amazon VPC en la consola y selecciona: Endpoints (Puntos de enlace), luego selecciona: Create Endpoint (Crear punto de enlace) en la esquina superior derecha (Figura 2).

Figura 2 – En la sección Endpoints (Puntos de conexión) de la consola del servicio Amazon VPC, seleccione Create endpoint (Crear punto de enlace).

Figura 2 – En la sección Endpoints (Puntos de conexión) de la consola del servicio Amazon VPC, seleccione Create endpoint (Crear punto de enlace).

2. Selecciona AWS services (Servicios de AWS) y crea el primer punto de enlace (Figura 3) amazonaws.<región>.ssm. Reemplaza <región> con la Región de AWS. Selecciona la VPC en la que se va a crear el punto de conexión. El grupo de seguridad adjunto al punto de conexión de VPC debe permitir conexiones entrantes en el puerto 443 desde la subred privada de la instancia gestionada. Finalmente, selecciona Create Endpoint (Crear punto de conexión) al final de la página.

Figura 3 – Crear los VPC Endpoint desde la consola del servicio Amazon VPC.

3. Cuando los tres VPC endpoints estén creados, verás el siguiente resultado (Figura 4).

Figura 4 – Los tres VPC Endpoints se han creado correcamente para permitir la instalación del agente SSM.

Paso 3 – Post-launch actions (Acciones posteriores al lanzamiento) para desinstalar las VMware Tools de Windows y Linux

Esta sección introduce la creación de los post-launch settings customizados (configuraciones personalizadas posteriores al lanzamiento) para automatizar la eliminación de las VMware Tools después de lanzar el servidor de origen replicado en AWS. Los cambios en las post-launch templates (plantilla posterior al lanzamiento) solo se aplicarán a los servidores de origen recién añadidos. Para los servidores de origen ya existentes, puedes modificar la post-launch template a nivel del servidor de origen.

1. Accede a la plantilla seleccionando: Post-Launch template (Plantilla posterior al lanzamiento) en el panel izquierdo. Edita la configuración de las post-launch actions (acciones posteriores al lanzamiento) y activa Systems Manager agent installation on launched Test and cutover instances (recommended). Para finalizar, selecciona Save template (Guardar plantilla) (Figura 5).

Figura 5 – Habilitar la instalación del agente SSM para test servers (servidores de prueba) y cutover launched servers (servidores de transición lanzados).

2. Para eliminar las VMWare Tools, creamos una custom action (acción personalizada). Selecciona Create action (Crear acción) (Figura 6).

Figura 6 – Seleccione Create action en la esquina superior derecha.

3. Añade la siguiente información en los action settings (Figura 7). Los post-launch scripts en Windows se ejecutan bajo el contexto de Servicio Local.

  1. Action Settings
    1. Action Name: CleanUpVMwareTools-Windows.
    2. Seleccione la opción Activate this action (Activar esta acción).
    3. Nombre del documento de Systems Manager: AWS-RunPowerShellScript.
    4. Descripción: Run a PowerShell script to clean Windows images from VMware tools.
    5. Sistemas operativos: Windows
  1. Action Parameters (Parámetros de la acción):
    El siguiente script puede utilizarse para desinstalar las VMTools después de la migración de Windows Server 2019.

    1. Comandos: 
      Remove-Item –path .\VMware –recurse 
$regpath = “HKLM:\Software\Microsoft\Windows\CurrentVersion\uninstall”
Get-childItem $regpath | % { 
   $keypath = $_.pschildname 
   $key = Get-Itemproperty $regpath\$keypath 
   if ($key.DisplayName -match “VMware Tools”) { 
      $VMwareToolsGUID = $keypath 
   } 
   Msiexec.exe /x $VMwareToolsGUID /qn /norestart 
}
    1. WorkingDirectory: C:\Program Files\
    2. executionTimeout: 300

      Figura 7 – Script de PowerShell para eliminar herramientas VMware de las instancias Windows replicadas y lanzadas.

4. Repite los pasos anteriores para la instancia Linux (Figura 8). Los Post-launch scripts en Linux se ejecutan como usuario root. Consulte Desinstalación de VMware Tools para Sistemas Operativos diferentes a RedHat Linux.

  1. Action settings:
    1. Action Name: CleanUpVMwareTools-Linux.
    2. Seleccione la opción, Activate this action (Activar esta acción).
    3. Nombre del documento de Systems Manager: AWS-RunShellScript
    4. Descripción: Run a Shell script to clean Linux images from VMware tools.
    5. Sistemas operativos: Linux.

      Figura 8 – Script de Shell para eliminar las VMware Tools de las instancias Linux replicadas y lanzadas.
  2. Action parameters
    1. commands: 
      rm -r ./VMware
    2. executionTimeout: 300

La post-launch template (Figura 9) mostrará las dos acciones recién creadas. Valida que estén configuradas como Active (Activa).

Figura 9 – Verifica que la instalación del Agente SSM y las dos post-launch actions recién creadas estén habilitadas.

Paso 4 – Añadir servidores de origen e instalar el agente en las VMs

Cada vez que se añade un servidor de origen al Application Migration Service, sus Replication Settings, Launch Settings y Post-launch settings se inicializan según las plantillas predeterminadas.

Una vez que los servidores de origen se añaden al Application Migration Service, puedes monitorizarlos e interactuar con ellos desde la página de Source Servers. En esta página, puedes ver todos sus servidores de origen, supervisar su ciclo de vida de migración, estado de replicación de datos, ver el siguiente paso en el proceso de migración para cada servidor y ordenar los servidores por diversas categorías.

Para añadir un servidor de origen Windows, selecciona Add server en la página Source servers.

Utiliza las opciones de la Figura 10 para crear el comando de instalación, añadiendo su IAM Access Key e IAM secret Access key. Copia el comando resultante y descarga el instalador.

Figura 10 – Comandos de instalación del Agente de Replicación de AWS.

Una vez que el instalador se ha descargado, ejecuta el comando en PowerShell. Se necesita ejecutar el archivo instalador del agente con permisos de administrador en cada servidor Windows (Figura 11).

Figura 11 – Ejecute los comandos necesarios para instalar el agente en los servidores de origen Windows.

Apunta el nombre de host y ve a la consola del Application Migration Service.

Una vez que el AWS Replication Agent esté instalado, el servidor se añadirá a la consola del Application Migration Service bajo Source Servers, donde comenzará el proceso de sincronización inicial.

Paso 5 – Lanzamiento de una test instance (instancia de prueba)

Probar la migración de los servidores de origen a AWS es esencial antes de lanzar el cutover (transición) para garantizar el funcionamiento adecuado del servidor de origen dentro del entorno de AWS.

Antes de lanzar una instancia de prueba, asegúrate de que los servidores de origen estén listos para las pruebas. Busca el siguiente estado en la página Source Servers.

  1. En la columna Migration lifecycle, el estado del servidor debe indicar Ready for testing.
  2. En la columna Data replication status, el estado del servidor debe ser Healthy.
  3. En la columna Next step, el estado del servidor debe ser Launch test instance.

Para lanzar una instancia de prueba para uno o más servidores de origen:

  1. Ve a la página Source servers.
  2. Marca la casilla junto a cada servidor que desee probar.
  3. Seleccione el menú Test and cutover.
  4. En Testing, selecciona Launch test instances para iniciar el lanzamiento de instancia(s) de prueba para el(los) servidor(es) de origen seleccionado(s) (Figura 12).

 Figura 12 – Selecciona Launch test instances del menú desplegable Test and cutover.

1. Una vez que aparezca el diálogo Launch test instances for X servers, selecciona Launch para comenzar la prueba.

2. La consola del AWS Application Migration Service mostrará Launch job started cuando la prueba haya comenzado. Elije View job details en el diálogo para ver el trabajo específico para el lanzamiento de prueba en Launch history.

3. Puedes confirmar que se ha iniciado el lanzamiento de la instancia de prueba, observando varios indicadores en la página Source servers (Figura 13).

  1. En la columna Alerts, verá el estado Launched, que indica el lanzamiento de una instancia de prueba para este servidor.
  2. En la columna Migration lifecycle, verás un estado de Test in progress.
  3. La columna Next step, mostrará Complete testing y marcado como Ready for cutover.

Figura 13 – Marca el servidor como Ready for cutover cuando sus pruebas estén completadas.

Una vez que se lancen sus instancias de prueba, accede a éstas. Puedes usar AWS SSM Session Manager o AWS SSM Fleet Manager para iniciar sesión en esas instancias. Esto se hace para verificar el funcionamiento correcto, evaluar la conectividad y realizar las pruebas necesaria para validar su aplicación.

Cuando las pruebas estén completadas y esté preparado para la fase de cutover (transición), puedes concluir la prueba. Para hacerlo, cambia el estado del ciclo de vida de migración de sus servidores de origen a Ready for cutover. Esto indica la finalización de todas las pruebas y la preparación para la transición. Eventualmente, finaliza el ciclo de vida test in progress (prueba en progreso) seleccionando Terminate test launched instances.

Verifica las post-launch actions.

  1. Selecciona Source servers y abre Post-launch settings.
  2. Para tener visibilidad de las acciones que se activarán, filtra por active. Se activarán las siguientes acciones (Figura 14).

SSM agent
CleanUpVMwareTools-Linux

Figura 14 – Validar las post-launch actions que se ejecutarán.

Cuando se lance la instancia, el estado de ejecución de la instalación del Agente SSM y la desinstalación de las VMWareTools puede verse bajo la pestaña Migration dashboard (Figura 15).

Figura 15 – Valide que todas las acciones se completen con éxito.

Paso 6 – Lanzamiento de una instancia de transición

  1. Selecciona la casilla junto a cada servidor de origen con una instancia de prueba lanzada para la cual desee concluir la prueba.
  2. Selecciona el menú Test and cutover (Figura 16).
  3. Bajo la sección Testing, selecciona la opción Ready for cutover.

Figura 16 – Marca como Ready for cutover para lanzar una instancia de transición.

En el diálogo Mark X servers as Ready for cutover, puedes elegir distintas opciones respecto a la terminación de las instancias de prueba. Se recomienda que termines estas instancias porque incurrirás en cargos por ellas, incluso si ya no las necesitas. Para proceder con la terminación, elije Yes, terminate launched instances (recommended) y después selecciona Continue.

La consola del Application Migration Service confirmará que los servidores fueron marcados como listos para la transición.

Antes de proceder con el lanzamiento de una instancia de transición, confirma la preparación de tus servidores de origen para la transición verificando los siguientes estados en la página Source servers (Servidores de origen) (Figura 17):

  1. Migration lifecycle status es Ready for cutover.
  2. Data replication status es Healthy.
  3. El siguiente paso muestra Terminate launched instance; Launch cutover instance si no ha terminado su instancia de prueba más reciente. Alternativamente, muestra Launch cutover instance si ha terminado la última instancia de prueba.

Figura 17 – Validar que el estado de migración es Ready for cutover (Listo para transición), el estado de replicación de datos es Healthy (Saludable).

Para iniciar una instancia de transición para uno o más servidores de origen:

  1. Visita la página Source servers y selecciona cada servidor que quieras transferir.
  2. Selecciona el menú Test and cutover
  3. En Cutover (Figura 18), seleccione Launch cutover instances.
  4. Aparece un diálogo emergente que muestra las instancias de transición que serán lanzadas con sus respectivos nombres. Confirma seleccionando Launch.

Figura 18 – Selecciona Launch cutover instances en el menú Test and cutover.

En la página Source servers (Figura 19), la columna Migration lifecycle muestra Cutover in progress y la columna Next step indica Finalize cutover.

Figura 19 – El ciclo de vida de la migración ha cambiado de Ready for cutover a Cutover in progress.

Selecciona tu servidor de origen para ver los detalles del trabajo (Figura 20).

Figura 20 – El ciclo de vida actual es Cutover in progress, lo que significa que las instancias de transición se están lanzando.

Después de lanzar sus instancias de transición, conéctate a ellas a través de la consola de Amazon EC2. Alternativamente, puedes conectarte a la instancia con AWS SSM Session Manager o Fleet Manager. Este paso es esencial para verificar que funcionen correctamente, confirmar la conectividad y realizar pruebas de validación para su aplicación.

Cuando hayas completado su migración, finaliza la transición (Figura 21):

  1. Elija cada servidor de origen que desee transferir.
  2. Selecciona: Finalize cutover.

Figura 21 – Selecciona Finalize cutover para detener la replicación de datos.

En el diálogo Finalize cutover for X servers, selecciona: Finalize para iniciar la transición. Esta acción actualizará el Migration lifecycle de tus servidores de origen a: Cutover complete, indicando una transición y migración exitosas. También detendrá la replicación de datos y descartará los volúmenes AWS EBS asociados y los servidores de replicación de Amazon EC2. La consola del Servicio Application Migration Service mostrará Cutover finalized cuando la transición se haya completado con éxito.

Limpieza

Para evitar cargos no deseados, asegúrate de limpiar los recursos no necesarios, incluyendo:

  • Instancias Amazon EC2
  • Desconectar cualquier servidor de origen del Servicio de Migración de Aplicaciones
  • Volúmenes EBS adjuntos a las instancias EC2 asociadas con sus pruebas
  • VPC endpoints

Conclusiones

Este blog post muestra los pasos necesarios para ejecutar una migración bajo demanda de una VM de VMware a Amazon EC2. El principal beneficio de este proceso es la automatización, que reduce significativamente los errores humanos y acelera la migración. Las post-launch actions limpian las imágenes de las herramientas VMware. Application Migration Service sigue siendo efectivo a nivel de coste, lo que lo convierte en una solución muy atractiva para migraciones, independientemente de si el entorno VMware está en instalaciones locales o en la nube.

Para recursos adicionales, consulta los siguientes temas en la Guía del usuario del Application Migration Service:

Autores

Philippe Wanner es Arquitecto de Soluciones Especialista Sénior en AWS. Su función es difundir las mejores prácticas de migración y modernización para grandes organizaciones. Actualmente, se centra en un área multidisciplinar relacionada con sistemas distribuidos, arquitectura sin servidor y transformación empresarial.
Simon Vaillancourt es Arquitecto de Soluciones Especialista Sénior en Amazon Web Services (AWS). Su función es asesorar a organizaciones sobre las mejores prácticas y estrategias de migración y modernización en el sector público canadiense. A lo largo de su carrera, ha desarrollado una amplia experiencia en la implementación y migración de grandes centros de datos e infraestructura, tanto desde la perspectiva del cliente como del proveedor, tanto en los sectores público como privado.