Como simplificar e organizar migrações em escala com as funcionalidades do AWS Application Migration Service (MGN) – Parte 2

Esta série de três artigos visa mostrar algumas sugestões para ajudar a organizar migrações em escala para a AWS ao longo de um “passo-a-passo” utilizando as funcionalidades do AWS Application Migration Service (MGN). No primeiro post, mostramos diversos motivadores para migrar para a nuvem, diferentes estratégias e como o AWS MGN se encaixa na estratégia de Rehost. O foco desta seção será a inicialização do serviço, a definição de algumas configurações base para a migração e o início da réplica de dados através do AWS MGN.

Requisitos:

Para este “passo-a-passo”, os itens a seguir são necessários:

Uma conta AWS: Se você não tem uma conta na AWS, siga estas instruções para abrir uma.
Servidor(es) de Origem: Um ou mais servidores de origem para réplica através do AWS MGN. Você pode iniciar uma instância Amazon EC2 para seus testes.
Conectividade de rede: A lista completa de requerimentos de rede está presente na documentação do AWS MGN. Em resumo, o seguinte é necessário:
- Comunicação através do protocolo TCP na porta 443:
  - Entre o(s) servidor(es) de origem e o AWS MGN;
  - Entre o(s) servidor(es) de origem e determinados buckets S3;
  - Entre o(s) servidor(es) de replicação na área de Staging e o AWS MGN;
  - Entre o(s) servidor(es) de replicação na área de Staging e determinados buckets S3.
- Comunicação através do protocolo TCP na porta 1500:
  - Entre o(s) servidor(es) de origem e o(s) servidor(es) de replicação na área de Staging.

Inicialização do AWS MGN

Caso esteja utilizando o AWS MGN pela primeira vez, é necessário inicializar o serviço e isto pode ser feito facilmente pela console através dos seguintes passos:

Realize login na console da AWS, procure por “AWS Application Migration Service” e acesse o serviço. Clique em “Get Started”:
Clique em “Set up service”:
Depois disto, as roles necessárias serão criadas em background para a utilização do AWS MGN e você será redirecionado para a tela principal, conforme abaixo:

Usuário IAM para a instalação do agente

O AWS MGN possui dois métodos para a migração de ambientes para a AWS: através da instalação de um agente no servidor de origem (agent-based) e sem instalação de agente (agentless), a qual está disponível para ambientes VMware com vCenter. Este artigo é focado na migração com instalação de agentes. Para mais informações sobre migração “agentless”, verifique esta documentação.

Para a instalação do agente no servidor de origem, é necessário gerar as devidas credenciais AWS as quais podem ser temporárias ou permanentes. Para migrações “agentless”, somente credenciais permanentes são suportadas. Para credenciais temporárias, crie uma Role IAM com a policy AWSApplicationMigrationAgentInstallationPolicy para posteriormente requisitar estas credenciais através do AWS STS no momento da instalação do agente. Para credenciais permanentes, crie um usuário IAM como por exemplo “mgn-agent-installer” com a mesma policy citada anteriormente e guarde o Access Key ID e Secret Access Key. Este usuário não necessita ter acesso a console AWS.

Dica #1: Utilize privilégios mínimos e credenciais temporárias sempre que possível. A policy IAM citada é suficiente para as atividades de migração. Caso um usuário IAM seja criado, não forneça acesso à console AWS e utilize somente a policy IAM mencionada. Não distribua o Access Key ID e Secret Access Key.

Definindo um modelo de replicação (Replication Template)

O Replication Template determina como a replicação de dados funcionará para cada novo servidor adicionado ao AWS MGN. Além deste Template, é possível modificar as configurações de replicação individualmente ou para um grupo de servidores.

Para modificar as configurações de replicação, acesse “Replication Template” e clique em “Edit”. Escolha a sub-rede a qual o AWS MGN criará os servidores para replicação e o tamanho dos mesmos:

Na mesma tela também há a opção de escolher o tipo de volume EBS que será usado pelos servidores de replicação em situações cujos discos sejam maiores que 500 GiB e o tipo de criptografia. Você pode utilizar a chave padrão do EBS ou apontar para uma customer-managed key (CMK):

Além disto, é possível escolher como os dados fluirão entre os servidores de origem e os servidores de replicação. Há três opções possíveis e em todas elas a comunicação é criptografada utilizando TLS 1.2 (PFS, ECDHE):

Create public IP: os servidores de replicação terão IPs públicos. A comunicação com o AWS MGN e com os servidores de origem para a replicação de dados será realizada através da internet;
Use private IP for data replication (VPN, DirectConnect, VPC peering, etc.): use esta opção para que a comunicação entre os servidores de replicação para o AWS MGN e os servidores de origem seja realizada através de redes privadas cuja conexão esteja estabelecida através de uma 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 opção somente para que a replicação dos dados seja feita através de redes privadas. A comunicação dos servidores de replicação e o AWS MGN é estabelecida através de um IP público.

Dica #2: Utilize uma sub-rede à parte para os servidores de replicação do AWS MGN. Utilize a seguinte fórmula para dimensionar esta sub-rede: (# total de discos a migrar / 15 = # de servidores de replicação). Mantenha um espaço para possíveis servidores de replicação dedicados e servidores de conversão. Em caso de utilização de IPs públicos, solicite o aumento dos mesmos antecipadamente.

Configure um modelo de inicialização (Launch Template)

O painel de configurações gerais para o launch de instâncias (General launch settings) exibe os parâmetros que não são controlados pelo EC2 Launch Template. Para modificar essas configurações, vá em “Settings” > “Launch template” e clique no botão “Edit”.

O Default EC2 Launch Template é utilizado quando uma instância de teste ou migração é lançada para este servidor. Este Template é criado automaticamente quando você adiciona um servidor de origem ao AWS MGN. Na mesma tela é possível visualizar ou alterar estes itens:

Dica #3: Utilize a funcionalidade de “right-sizing” do AWS MGN para uma melhor correspondência inicial do tamanho das instâncias EC2 após a migração.

Elimine ações manuais com um modelo de pós-lançamento (Post-Launch Template)

Para poder usar o Post-Launch Template, você deve primeiro ativar as ações pós-lançamento (Post-launch actions). Acesse “Settings” > “Post-launch template” > “Post-launch actions settings” e escolha “Edit”. Para ativar esta funcionalidade, você deve permitir que o MGN instale o Agente do Systems Manager (SSM Agent) em seus servidores. Isso permitirá que o MGN execute ações após o lançamento das instâncias EC2. Ative a opção “Install the Systems Manager agent and allow executing actions on launched servers” e escolha “Save template”.

Utilize esta configuração para escolher se deseja executar as ações pós-lançamento apenas em suas instâncias de migração final (cutover) ou em ambas, instâncias de teste e migração final.

O AWS MGN possui diversos Post-launch actions que permitem simplificar o processo de migração. Por exemplo, é possível fazer o join em um domínio, instalar o agente do CloudWatch, criar uma AMI, converter um CentOS para Rocky Linux e fazer o upgrade de um Windows Server para uma versão mais nova. Para ativar um Post-launch Action, selecione um dos cards em “Post-launch template” e clique em “Edit”. No exemplo a seguir, criaremos uma AMI da instância EC2 a partir desta ação (“Create AMI from instance”):

Em “Edit action”, dê um nome no campo “Action name”, selecione o checkbox “Activate this action” e clique em “Save action”.

Depois disto, este Post-launch action deve aparecer como “Active”:

Dica #4: Utilize as opções de Post-launch para ajudar a modernizar os seus workloads. Faça o deployment tanto nos servidores de teste quanto de cutover para que os testes sejam os mais fidedignos possíveis. Tenha em mente que algumas ações quando executadas em teste e cutover podem gerar recursos duplicados (exemplo: geração de uma AMI).

Iniciando a réplica de dados nos servidores de origem

O AWS MGN também mostra as instruções necessárias para a instalação do agente nos servidores de origem. Para visualizar as instruções, selecione “Add server” na tela de “Source servers”:

Nos exemplos abaixo, substitua a [Região AWS] pela região de destino da migração como sa-east-1 ou us-east-1, por exemplo. Troque também o [IAM Access Key ID] e [IAM Secret Access Key] pelas informações correspondentes geradas no momento da criação do usuário.

Execute os seguintes comandos para download e instalação do agente de acordo com o sistema operacional.

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

Instalação:

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:

A lista de URLs para download do agente para máquinas Windows encontra-se aqui.

Instalação em máquinas Windows (exceto 2003, 2003 R2 e 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

Instalação em máquinas Windows Server 2003, Windows Server 2003 R2 ou 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

Após alguns minutos, o AWS MGN criará os servidores de replicação e o status da migração aparecerá na console:

O AWS MGN suporta 150 servidores de origem por região por padrão, mas este limite pode ser alterado. Caso a sua migração possua um número muito maior de servidores, considere o uso do Cloud Migration Factory. É possível visualizar as métricas de migração de todos os servidores de origem na console e filtrá-las de acordo com a saúde, status da replicação e ciclo de vida da migração dos mesmos:

Conclusão

As funcionalidades de “Post-launch actions” permitem a automação de várias atividades, eliminando a execução manual de passos que consomem tempo e são propensos a erro. No último artigo (Parte 3), demonstraremos como organizar a nossa migração com as funcionalidades de Applications e Waves. Até a próxima!

Sobre os Autores

Juliano Fernandes Baeta é Arquiteto de Soluções para Parceiros Globais nos Estados Unidos e América Latina. Sua missão é ajudar Clientes e Empresas Integradoras de Sistemas a construir soluções seguras, eficazes e resilientes na AWS.

Thiago Mantovani está localizado no Brasil e é Arquiteto de Soluções da AWS com especialização em Migrações. Seu maior foco é ajudar os clientes de diversos segmentos na América Latina em sua jornada para nuvem de forma resiliente e escalável. Fora do trabalho, ele adora se divertir com sua família e é um grande fã e praticante de esportes.

Pedro Calixto é Arquiteto de Soluções especialista em migrações na AWS. Pedro integra a equipe de Cloud Acceleration para a América Latina. Seu foco é ajudar empresas a exceder resultados de negócio, acelerando a migração e a modernização de workloads para a AWS de forma escalável

O blog da AWS