Blog de Amazon Web Services (AWS)
Cómo simplificar y organizar migraciones a escala con las características de AWS Application Migration Service (MGN) – Parte 2
Requerimientos:
- Una cuenta de AWS: Si no tiene una cuenta de AWS, siga estas instrucciones para abrir una.
- Servidor(es) de origen: Uno o más servidores de origen para replicación a través de AWS MGN. Puede lanzar una instancia de Amazon EC2 para sus pruebas.
- Conectividad de red: La lista completa de requisitos de red se puede encontrar en la documentación de AWS MGN. En resumen, se requieren los siguientes:
- Comunicación a través del protocolo TCP en el puerto 443:
- Entre el (los) servidor(es) de origen y AWS MGN;
- Entre el (los) servidor(es) de origen y los buckets determinados de S3;
- Entre el (los) servidor(es) de replicación en el área de Staging y AWS MGN;
- Entre el (los) servidor(es) de replicación en el área de Staging y los buckets determinados de S3.
- Comunicación a través del protocolo TCP en el puerto 1500:
- Entre el (los) servidor(es) de origen y los servidores de replicación en el área de Staging.
- Comunicación a través del protocolo TCP en el puerto 443:
Iniciación de AWS MGN
Si está utilizando AWS MGN por primera vez, es necesario inicializar el servicio y esto se puede hacer fácilmente desde la consola a través de los siguientes pasos:
- Inicie sesión en la consola de AWS, busque “AWS Application Migration Service” y acceda al servicio. Haga clic en “Get Started«:
- Haga clic en “Set up service”:
- Después de eso, se crearán los roles necesarios en segundo plano para el uso de AWS MGN y se le redirigirá a la pantalla principal, como se muestra a continuación:
Usuario de IAM para la instalación del agente
AWS MGN tiene dos métodos para migrar cargas de trabajo a AWS: instalando un agente en el servidor de origen (basado en agente) y sin instalación de agente (sin agente) que está disponible para entornos VMware con vCenter. Este artículo se centra en la migración con la instalación de agentes. Para obtener más información sobre la migración “sin agente”, consulta esta documentación.
Para instalar el agente en el servidor de origen, es necesario generar las credenciales de AWS adecuadas, las cuales pueden ser temporales o permanentes. Para las migraciones “sin agente”, solo se admiten las credenciales permanentes. Para las credenciales temporales, cree un rol de IAM con la política AWSApplicationMigrationAgentInstallationPolicy para posteriormente solicitar estas credenciales a través de AWS STS en el momento de instalar el agente. Para credenciales permanentes, cree un usuario de IAM como “mgn-agent-installer” con la misma política mencionada anteriormente y guarde el Access Key ID y la Secret Access Key. Este usuario no necesita tener acceso a la consola de AWS.
| Consejo #1: Usa privilegios mínimos y credenciales temporales siempre que sea posible. La política de IAM anterior es suficiente para las actividades migratorias. Si se crea un usuario de IAM, no proporcione acceso a la consola de AWS y utilice únicamente la política de IAM mencionada. No distribuya el Access Key ID y la Secret Access Key |
Definindo um modelo de replicação (Replication Template)
El Replication Template determina cómo funcionará la replicación de datos para cada nuevo servidor agregado a AWS MGN. Además de este Template, es posible modificar la configuración de replicación individualmente o para un grupo de servidores.
Para modificar la configuración de replicación, vaya a “Replication Template” y haga clic en “Edit”. Elija la subred en la que AWS MGN creará los servidores para la replicación y su tamaño:
En la misma pantalla, también existe la opción de elegir el tipo de volumen de EBS que utilizarán los servidores de replicación en situaciones en las que los discos sean mayores de 500 GiB y el tipo de cifrado. Puede utilizar la clave estándar de EBS o apuntar a una llave manejada por usted como cliente (customer-managed key or CMK):
Además, es posible elegir cómo fluirán los datos entre los servidores de origen y los servidores de replicación. Hay tres opciones posibles y en todas ellas la comunicación se cifra mediante TLS 1.2 (PFS, ECDHE):
- Create public IP: Los servidores de replicación tendrán IPs públicas. La comunicación con AWS MGN y con los servidores de origen para la replicación de datos se llevará a cabo a través de Internet;
- Use private IP for data replication (VPN, DirectConnect, VPC peering, etc.): utilizar esta opción para que la comunicación entre los servidores de replicación para AWS MGN y los servidores de origen se lleve a cabo a través de redes privadas cuya conexión se establezca a través de una VPN, Direct Connect, VPC Peering, Transit Gateway, VPC Endpoints, etc.;
- Create public IP, and use Private IP for data replication (VPN, DirectConnect, VPC peering, etc.): use esta opción solo para que los datos se repliquen a través de redes privadas. La comunicación entre los servidores de replicación y la AWS MGN se establece a través de una IP pública.
| Consejo #2: Utilice una subred separada para los servidores de replicación de AWS MGN. Utilice la siguiente fórmula para dimensionar esta subred: (# total de discos a migrar/15 = # de servidores de replicación). Mantenga el espacio para posibles servidores de replicación dedicados y servidores de conversión. Si se utilizan IPs públicas, solicite su incremento con anticipación. |
Configurar un formato/modelo de lanzamiento (Launch Template)
El panel de configuración general para iniciar instancias (General launch settings) muestra los parámetros que no están controlados por el EC2 Launch Template. Para modificar estos ajustes, vaya a “Settings” > “Launch template” y haga clic en el botón “Edit”.
EL Default EC2 Launch Template se utiliza cuando se inicia una instancia de prueba o migración a este servidor. Esta plantilla se crea automáticamente cuando agrega un servidor de origen a AWS MGN. En la misma pantalla es posible ver o cambiar estos elementos:
| Consejo #3: Utilice la función de “right-sizing” de AWS MGN para que coincida mejor con el tamaño inicial de sus instancias EC2 después de la migración. |
Elimine las acciones manuales con una plantilla posterior al lanzamiento (Post-Launch Template)
Para poder utilizar el Post-Launch Template, primero debe habilitar las acciones posteriores al lanzamiento (Post-launch actions). Ve a “Settings” > “Post-launch template” > “Post-launch actions settings” y elige “Edit”. Para habilitar esta funcionalidad, debe permitir que MGN instale el Agente de Systems Manager (SSM Agent) en sus servidores. Esto permitirá a la MGN realizar acciones después de que se lanzan las instancias EC2. Active la opción “Install the Systems Manager agent and allow executing actions on launched servers” y elija “Save template”.
Use esta configuración para elegir si desea realizar las acciones posteriores a la versión solo en sus instancias de migración final (cutover) o en ambas, instancias de prueba y migración final.
AWS MGN tiene varias “Post-launch actions” que le permiten simplificar el proceso de migración. Por ejemplo, es posible unirse a un dominio, instalar el agente de CloudWatch, crear una imagen de servidor (AMI), convertir un CentOS a Rocky Linux y actualizar un Windows Server a una versión más reciente. Para activar un Post-launch Action, seleccione una de las tarjetas en “Post-launch template” y haga clic en “Edit”. En el siguiente ejemplo, crearemos una AMI para la instancia EC2 a partir de esta acción (“Create AMI from instance”):
En “Edit action”, adicione un nombre en el campo “Action name”, seleccione la casilla de verificación “Activate this action” y haga clic en “Save action”.
Después de eso, este Post-launch action debe aparecer como “Active”:
| Consejo #4: Utilice las opciones de Post-launch para ayudar a modernizar sus cargas de trabajo. Desplegar tanto en los servidores de prueba como en los servidores de cutover para que las pruebas sean lo más confiables posible. Ten en cuenta que algunas acciones cuando se realizan en test y cutover pueden generar recursos duplicados (ejemplo: generar una AMI). |
Inicio de la replicación de datos en los servidores de origen
AWS MGN también muestra las instrucciones necesarias para instalar el agente en los servidores de origen. Para ver las instrucciones, seleccione “Add server” en la pantalla “Source servers”:
En los ejemplos siguientes, reemplace [Región de AWS] por la región de destino de la migración, como us-east-1 o us-west-1, por ejemplo. También reemplace [IAM Access Key ID] y [IAM Secret Access Key] por la información correspondiente generada en el momento en que se creó el usuario.
Ejecute los siguientes comandos para descargar e instalar el agente según el sistema operativo.
Linux
Download:
wget -O ./aws-replication-installer-init.py https://aws-application-migration-service-[Região AWS].s3.us-east-1.amazonaws.com/latest/linux/aws-replication-installer-init.py
Instalación:
sudo python3 aws-replication-installer-init.py --region [Região AWS] --aws-access-key-id [IAM Access Key ID] --aws-secret-access-key [IAM Secret Access Key] --no-prompt
Windows:
Download:
La lista de URLs para descargar el agente para máquinas Windows se puede encontrar aquí.
Instalación en máquinas Windows (excepto 2003, 2003 R2 y 2008):
.\AwsReplicationWindowsInstaller.exe --region [Região AWS] --aws-access-key-id [IAM Access Key ID] --aws-secret-access-key [IAM Secret Access Key] --no-prompt
Instalación en máquinas con Windows Server 2003, Windows Server 2003 R2 o Windows Server 2008:
.\AwsReplicationWindowsLegacyInstaller.exe --region [Região AWS] --aws-access-key-id [IAM Access Key ID] --aws-secret-access-key [IAM Secret Access Key] --no-prompt
Después de unos minutos, AWS MGN creará los servidores de replicación y el estado de migración aparecerá en la consola:
AWS MGN admite 150 servidores de origen por región de forma predeterminada, pero este límite se puede cambiar. Si su migración tiene un número mucho mayor de servidores, considera usar Cloud Migration Factory. Puede ver las métricas de migración de todos los servidores de origen en la consola y filtrarlos según su estado, estado de replicación y ciclo de vida de migración:
Conclusión
Las funcionalidades de “Post-launch actions” permiten la automatización de diversas actividades, eliminando la ejecución manual de pasos que consumen mucho tiempo y son propensos a errores. En el último artículo (Parte 3), demostraremos cómo organizar nuestra migración con las funcionalidades Applications y Waves. ¡Hasta la próxima vez!
Este artículo fue traducido del Blog de AWS en Portugués.
Acerca de los Autores
Juliano Fernandes Baeta es Arquitecto de Soluciones para socios globales en Estados Unidos y América Latina. Su misión es ayudar a los clientes y a las empresas de integración de sistemas a crear soluciones seguras, eficaces y resilientes en AWS.
Thiago Mantovani se encuentra en Brasil y es un Arquitecto de soluciones de AWS especializado en migraciones. Su objetivo principal es ayudar a clientes de diversos segmentos en América Latina en su viaje hacia la nube de una manera resiliente y escalable. Fuera del trabajo, le encanta divertirse con su familia y es un gran fanático de los deportes y practicante.
Pedro Calixto es un Arquitecto de Soluciones especializado en migraciones en AWS. Pedro forma parte del equipo de Aceleración de la Nube para América Latina. Su enfoque es ayudar a las empresas a superar los resultados comerciales al acelerar la migración y modernización de las cargas de trabajo a AWS de manera escalable.
Revisor
Luis Alberto es un profesional con más de 28 años de trayectoria en tecnología. Está localizado en Colombia y es arquitecto de Soluciones, especialista en temas de migración a AWS para clientes de diferentes industrias en Latinoamérica. Está enfocado en apoyar a sus clientes en la adopción de herramientas que los ayudan a acelerar su migración a AWS.