Blog de Amazon Web Services (AWS)
AWS Application Migration Service: Dónde comenzar
Por Dimas Cañas y Angélica Ortega, Partner Solutions Architects de AWS
AWS Application Migration Service (también conocido como AWS MGN) es un nuevo servicio lanzado por AWS que se basa en la estrategia de “Rehost”, parte del Framework de “las 6 R’s” , el cuál define las estrategias más comunes de migración.
Esta estrategia de “Rehost”, también conocida como “Lift & Shift”, tiene como objetivo alojar aplicaciones en AWS, sin cambios significativos o cambios mayores; así la migración de aplicaciones se realiza de manera rápida , efectiva en costos y alineada a los objetivos de negocio.
En esta publicación se explicará cómo usar AWS MNG desde la consola, se explicará su funcionamiento y configuración. Se usará como base un ejemplo con una aplicación de prueba tipo LAMP (con stack tecnológico Linux, Apache, MySQL y PHP) para tener una guía básica de instalación y el paso a paso de cómo utilizar AWS MNG.
A continuación, un ejemplo de la arquitectura general de este laboratorio en la figura 1.
Figura 1. Arquitectura de prueba
Requisitos
- Una cuenta de AWS: Si no tiene una cuenta de AWS, siga estas instrucciones para abrir una.
¿Cómo funciona?
AWS Application Migration Service (MGN) es un servicio de migración basado en CloudEndure, para utilizarlo requerimos instalar un agente de replicación de AWS, durante la instalación de este se pueden definir parámetros de replicación, así como configuraciones específicas para administrar el área de staging, tal como utiliza CloudEndure para hacer replicación de servidores. A continuación agregamos una imagen con la definición del funcionamiento descrita anteriormente en la figura 2.
Figura 2. Arquitectura Application Migration Service
Permisos e instalación
Como primer paso debe asegurar que la región en la que trabajará tiene habilitado este servicio, para obtener esta información puede referirse a el sitio oficial de Application Migration Service, considere que este servicio establecerá comunicación a través del puerto 443.
Empezando con AWS MGN
Comience el presente ejercicio práctico, en el cuál usará una aplicación de prueba LAMP. Para este fin se utilizará la aplicación disponible en la sección de “Application Framework” de la documentación de CloudFormation. Cómo puede observar en la Figura 3, es requerido ejecutar dicho stack de CloudFormation en la región de Oregon (us-west-2).
Figura 3. CloudFormation aplicación LAMP.
Antes de ejecutar el stack es necesario contar con un Key Pair para que sea asignado a los servidores a ser desplegados por el stack. Adicionalmente deberá proporcionar valores a los parámetros solicitados por el stack como se muestra en la figura 4.
Figura 4. Configuración del Stack.
Una vez finalizada la ejecución podrá acceder al enlace de la aplicación desplegada en la sección de “Outputs”, Figura 5.
Figura 5. Sección Outputs de Cloudformation.
Para poder observar el funcionamiento del Stack liberado, puede acceder al enlace marcado como WebsiteURL, se mostrará el sitio como en la figura 6.
Figura 6. Stack LAMP liberado
Ahora iniciemos con AWS Application Migration Service (MGN). Este ejercicio esta basado en la guía de inicio del servicio.
Paso 1: El primer paso de configuración para el servicio de migración de aplicaciones es crear la plantilla de configuración de replicación. Elija “Get Started” en la página de inicio. Se muestra como en la figura 7.
Figura 7. Guía de Inicio AWS Application Migration Service.
Se le pedirá automáticamente que cree la plantilla de Configuración de replicación la primera vez que inicie sesión en el Servicio de migración de aplicaciones. Esta plantilla determinará cómo funcionará la replicación de datos para cada servidor de origen recién agregado. En el contexto de esta prueba, puede utilizar los valores por defecto (Default VPC, Subnet, etc.), descrito en la figura 8.
Figura 8. Plantilla de configuración de replicación.
Si desea conocer en detalle cada uno de los parámetros de configuración puede seleccionar el enlace de “Info” en cada uno de ellos.
Una vez que haya configurado su plantilla, haga clic en el botón naranja “Create template”.
Paso 2: Agregue los servidores de origen al servicio de migración de aplicaciones, instalando el agente de replicación de AWS en ellos. El agente se puede instalar tanto en servidores Linux como Windows.
Es necesario que revise los requisitos de instalación, en este caso en particular debe:
- Generar Credenciales de AWS
- Instalar Python en el servidor origen (Servidor Web del Stack LAMP). Es requerido Python 2 (2.4 o superior) o Python 3 (3.0 o superior).
Una vez que atienda los requisitos de instalación, prosiga con la descarga del agente. El instalador del agente debe seguir el siguiente formato:
Reemplace <region> con la región de AWS en la cuál desea replicar (en este ejemplo: us-west-2). Este es un ejemplo del comando completo wget:
wget -O ./aws-replication-installer-init.py https://aws-application-migration-service-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
Luego ejecute el instalador:
sudo python3 aws-replication-installer-init.py
Le serán solicitadas las credenciales que creó en el punto a (aws-access-key-id, aws-secret-access-key), las credenciales creadas se tomarán de la descarga realizada y se mostrarán como en la figura 9.
Figura 9. Configuración de credenciales.
Una que instale el agente podrá ver en un par minutos, el servidor en la sección de “Source Servers”, figura 10.
Figura 10. Pantalla servidores fuente.
Debe esperar a que el mismo se encuentre en estado “Ready for testing” para poder avanzar con el siguiente paso.
Paso 3: Una vez que agregue sus servidores de origen a la consola, deberá configurar los ajustes de inicio para cada servidor. La configuración de lanzamiento es un conjunto de instrucciones que determinan cómo se lanzará una instancia en ambiente Test o Cutover, para cada servidor de origen en AWS. Debe configurar los ajustes de lanzamiento antes de lanzar las instancias.
Haga click en el servidor en la lista de “Source Servers” y luego seleccione la opción de “Launch Settings”, figura 11.
Figura 11. Launch Settings
Puede utilizar la configuración predeterminada o ajustar la configuración para adaptarla a sus necesidades. Aquí puede ver su configuración de lanzamiento general y la plantilla de lanzamiento de EC2. Haga clic en el botón Editar para editar su configuración de lanzamiento o Modificar para editar su plantilla de lanzamiento de EC2, figura 12.
Figura 12. Edición y modificación de configuraciones de lanzamiento.
En nuestro ejemplo, debe modificar el “EC2 Launch Template” para actualizar las opciones que permiten asignar una IP pública y para lanzar las instancias en el Security Group creado en el stack LAMP de nuestra aplicación de muestra (PHPHelloWorldSample-WebServerSecurityGroup*), como se muestra en las figuras 13 y 14. Esto permitirá acceder al nuevo servidor (migrado y lanzado), de manera pública y a través del protocolo http en el puerto 80. Nota: recordar que este ajuste obedece a un contexto de demostración o prueba, un ambiente productivo debe seguir las prácticas recomendadas.
Figura 13. Ajustar la IP y el grupo de seguridad.
Figura 14. Asignación del grupo de seguridad e IP pública.
Para crear una nueva versión de la configuración de lanzamiento, seleccione “Create template version”. Dicha nueva versión no quedará asignada como la versión por defecto, por lo cuál para efectos del ejercicio práctico, debe actualizarlo en la consola de EC2, figura 15.
Figura 15, Configurar versión de la plantilla.
Seleccione la versión que acaba de crear para ajustar la configuración de IP Pública y Grupo de Seguridad, figura 16.
Figura 16. Configurar versión default.
Paso 4: Una vez que haya agregado todos sus servidores de origen y haya configurado sus configuraciones de inicio, estará listo para lanzar una instancia de prueba. Es crucial probar la migración de sus servidores de origen a AWS antes de iniciar una transición. Es decir, debe verificar que sus servidores de origen funcionen correctamente dentro del entorno de AWS, figura 17 y 18.
Figura 17. Lanzamiento de instancias pruebas.
Figura 18. Botón de lanzamiento.
Una vez lanzado el servidor de pruebas, podrá ver en un par de minutos en su consola de EC2, dos servidores adicionales, el servidor de replicación, responsable de replicar el servidor origen y un servidor sin un nombre específico, que representa el servidor migrado, figura 19.
Figura 19. Instancias en EC2.
Proceda a acceder al nuevo servidor y utilice la información del dns público para probar que el servidor y la aplicación de prueba migrados se encuentra disponible, figura 20. Debe seguir el siguiente formato http://ec2-NEW-PUBLIC-IP.us-west-2.compute.amazonaws.com
Figura 20. Obtención de IP pública.
Paso 5: Una vez que ha probado este ambiente de prueba, y para hacer el lanzamiento del ambiente productivo o de transición (Cutover), seleccionar en el menú de “Test and Cutover”, la opción de “Mark as “Ready for cutover””. Podrá ver que en la opción de confirmación se pregunta si desea terminar de manera automática las instancias lanzadas en el proceso de prueba, figura 21.
Figura 21. Terminar instancias lanzadas.
Puede trasladar un servidor de origen a la vez, o trasladar simultáneamente varios servidores de origen. Para cada servidor de origen, se le informará sobre el éxito o el fracaso de la transición. Debe seleccionar en el menú “Test and Cutover”, la opción de “Launch cutover instances”, figura 22.
Figura 22. Opción “cutover”.
Una vez lanzado el servidor de transición, podrá ver en un par de minutos en su consola de EC2, el nuevo servidor (en este ejercicio práctico, sin un nombre específico). Proceda a acceder al nuevo servidor y utilice la información del dns público para probar que el servidor y la aplicación de prueba migrados se encuentra disponible. Debe seguir el siguiente formato http://ec2-NEW-PUBLIC-IP.us-west-2.compute.amazonaws.com
Si ha terminado por completo con su migración y realizó una transición exitosa, puede finalizar la transición. Esto cambiará el estado del ciclo de vida de la migración de sus servidores de origen a “Cutover Complete”, lo que indica que el cutover está completo y que la migración se ha realizado correctamente. Además, esto detendrá la replicación de datos y hará que se descarten todos los datos replicados. Además, se cancelarán todos los recursos de AWS utilizados para la replicación de datos. Debe seleccionar el servidor y luego en el menú “Test and Cutover”, y luego tomar la opción de “Finalize cutover”, figura 23.
Figura 23. Opción finalizar “Cutover.
Finalmente, para limpiar el ambiente creado durante este ejercicio práctico, sólo debe eliminar los recursos asociados al servidor de transición del paso anterior y eliminar el stack creado para la aplicación de prueba en CloudFormation, figura 24.
Figura 24. Borrado de stack en el servicio de Cloudformation.
NOTA. Por favor considerar que los pasos antes descritos son solo para fines de demostración, un entorno de producción debe seguir las mejores prácticas de seguridad.
Conclusión:
AWS Application Migration Service puede acelerar la migración de aplicaciones hacia AWS, a través del análisis de las mismas , mediante una estrategia de “Rehost” pudiendo así optimizar costos y tiempo de migración,ya que este ejercicio no requiere hacer cambios sustanciales en las aplicaciones; este servicio suma al conjunto de servicios ofrecidos para acelerar su jornada de adopción de nube en AWS dentro de la oferta de servicios de migración.
Recursos:
AWS Application Migration Service
Sobre los autores
Angélica Ortega es Arquitecta de Soluciones para Socios de Negocio (PSA) enfocada en atención a socios de Latinoamérica, es líder regional de programas como APN Immersion Day y APN Ambassador. Cuenta con 18 años de experiencia en el sector de Tecnologías de la Información. Ha sido Arquitecta de Soluciones, especialista en cloud, encargada de diseño de servicios administrados y desarrolladora de soluciones móviles.
Dimas Cañas es Arquitecto de Soluciones para socios de negocio en sector público de México. Cuenta con 18 años de experiencia en el sector de Tecnologías de la Información. Ha sido Arquitecto de Aplicaciones, Arquitecto de Software y Líder de Transformación Digital.
Sobre los revisores
Erico Penna es Arquitecto de Soluciones para socios de negocio especializado en migraciones, es miembro del la Comunidad Técnica de Campo (TFC).
Javier Huerta es Arquitecto de Soluciones especializado en Mejores Prácticas (Well-Architected) para Latinoamérica. Ha sido Arquitecto de Soluciones, Service Delivery Manager, Gerente de Cumplimiento Normativo, y Director de Innovación Tecnológica a lo largo de 25 años de carrera profesional. Es también miembro de la Comunidad Técnica de Campo (TFC) de Media y Entretenimiento. Por el momento, se encuentra pensando cuál será la siguiente solución que construirá en AWS.