O blog da AWS

Monitore o AWS Application Migration Service em várias contas e regiões

Por Tom Conlin, arquiteto de infraestrutura em nuvem da AWS Professional Services,
Ajay Mehta, arquiteto sênior de infraestrutura de nuvem da AWS Professional Services,
y Santosh Vallurupalli, aarquiteto de infraestrutura em nuvem e faz parte da equipe de serviços profissionais da AWS.

 

Normalmente, os clientes começam sua jornada para a nuvem da AWS fazendo rehost (lifting-and-shifting) dos servidores em seu ambiente local. Eles fazem isso por vários motivos de negócios, como passar de despesas de capital para despesas operacionais, reduzir o custo total de propriedade, reduzir os custos de suporte, saída do data center e muitos outros. O AWS Application Migration Service (MGN) é o serviço automatizado de lift and shift que facilita as migrações de servidores para a AWS em grande escala. O serviço AWS MGN permite que as organizações movam as aplicações para a AWS com o mínimo de tempo de inatividade e sem alterar as aplicações ou sua arquitetura. Com o AWS MGN, os clientes podem migrar servidores com o mínimo de tempo de inatividade e sem a necessidade de fazer alterações do lado da aplicação.A escalabilidade das operações de migração para atender às necessidades dos negócios exige muitos componentes, incluindo a  observabilidade. Os servidores geralmente são agrupados por dependências e migrados como uma unidade. Para que a unidade seja migrada com sucesso, todos os dados devem ser totalmente replicados no dia da migração. O agente AWS MGN é instalado nos servidores de origem e, em seguida, replica os dados para a conta e região da AWS. Como resultado de mudanças no ambiente, na rede ou nos dados, a replicação pode parar ou ser adiada, comprometendo a migração. Além disso, os servidores de origem desconectados incorretamente do MGN exigem que os dados sejam replicados novamente, o que pode causar um atraso na migração. Sem visibilidade desses eventos, os cronogramas e a cadência da migração dos clientes correm o risco de serem adiados. Atrasos na migração criam custos adicionais e o retrabalho exige mais horas de trabalho. Monitorar eventos de interrupção, atraso ou desconexão do servidor de origem em tempo hábil pode ajudar a mitigar esses riscos.Neste blog, mostramos como configurar uma solução de monitoramento para servidores de origem do AWS MGN, que fornece recursos de registro e notificação para replicação de dados paralisada, tempo de replicação de dados decorrido e servidores de origem desconectados do serviço MGN. Com essa solução, os clientes podem monitorar as operações do AWS MGN em várias contas para as quais podem migrar servidores de ambientes locais.

Visão geral da solução

Essa solução usa o conceito de uma conta central da AWS e uma conta da AWS de destino. A conta da AWS de destino é aquela para a qual o servidor de origem local será migrado, e a conta central da AWS é aquela para a qual os eventos do AWS MGN e os alarmes do CloudWatch de várias contas da AWS de destino serão encaminhados para processamento e agregação. Aqui está uma explicação adicional da atividade que ocorre em cada uma das contas, junto com a arquitetura da solução proposta:

Figura 1: Arquitetura da Solução

1. Conta de destino

Os recursos de monitoramento da conta de destino incluem alarmes do Amazon CloudWatch, funções AWS Lambda, as regras do Amazon EventBridge e os papéis do AWS IAM (Identity and Access Management). Quando essa solução é implementada, ela cria uma função Lambda na conta de destino que cria automaticamente novos alarmes para indicar a duração do atraso e a replicação dos dados decorridos sempre que novos servidores de origem são adicionados ao AWS MGN. Posteriormente, quando os servidores de origem forem removidos do AWS MGN, uma função adicional do Lambda removerá automaticamente os alarmes que foram configurados para esse servidor de origem. Essa solução configura uma regra do EventBridge que encaminha eventos para o EventBus da conta central quando os alarmes do CloudWatch vão para o estado “ALARM”.

O AWS MGN envia nativamente determinados eventos do MGN para o AWS EventBridge, mesmo quando a replicação de dados é interrompida. Uma regra do EventBridge é configurada para encaminhar eventos para o EventBus da conta central quando os servidores de origem do MGN experimentam uma paralisação na replicação de dados. Você pode monitorar uma ou mais contas de destino com essa solução seguindo as etapas de implementação descritas no restante do blog. Para simplificar, usaremos uma única conta de destino como tutorial neste blog.

2. Conta central

Os recursos da conta de monitoramento central incluem um EventBus personalizado, uma regra do EventBridge, uma função Lambda, um tópico e inscrição do Amazon Simple Notification Service e um grupo de logs do CloudWatch (LogGroup).

Uma regra do EventBridge é configurada na conta central para executar uma função Lambda (chamaremos essa função de conta central Lambda) toda vez que os eventos forem carregados no EventBus da conta central. A função Lambda processa os eventos em um esquema comum e, em seguida, envia o evento formatado para um tópico do SNS e para um grupo de logs do CloudWatch.

Pré-requisitos

Neste blog, presumimos que você configurou o AWS Application Migration Service e está pronto para instalar o agente de replicação nos servidores de origem destinados à migração para a AWS. Também presumimos que você tenha uma conta central da AWS na qual os eventos serão agregados.

Antes de seguir as etapas para implementar a solução, verifique se você tem o seguinte:

  1. Duas contas da AWS com permissões para implementar e gerenciar os serviços descritos neste blog nessas contas.
  2. Um bucket S3 para armazenar o modelo do CloudFormation empacotado para a implementação da solução

Etapas de implementação da solução

A solução inclui dois modelos do CloudFormation, um implementado na conta de destino para coletar eventos e alertas do MGN e outro implementado na conta central para processar os eventos agregados e enviá-los a um tópico do SNS para receber alertas por email. Esses modelos do CloudFormation são encontrados nas pastas  central_account/ e target_account/  do repositório da solução.  A solução também inclui um exemplo de código para a função Lambda que processa os eventos adicionados na conta central. A função Lambda para a conta central é encontrada em  lambda_function/.

Aqui estão as etapas para implementar essa solução

  1. Empacote o código Lambda para a conta central
  2. Implemente a solução
    1. Em sua conta central
    2. Na sua conta de destino

1. Empacote o código Lambda para a conta central

Nessa solução, fornecemos um exemplo de código Lambda que processa alarmes e eventos MGN do CloudWatch de várias contas. Você pode clonar o repositório do GitHub e personalizar o código Lambda para atender às suas necessidades. A função Central Lambda é escrita em Python e é muito grande para ser incluída em linha no modelo do CloudFormation, portanto, ela deve ser empacotada. Para automatizar o empacotamento da função Lambda, fornecemos um modelo do CloudFormation que configura um ambiente Cloud9. Siga as etapas abaixo para implementar o modelo Cloud9 CloudFormation, que empacotará o código Lambda e gerará um modelo de saída do CloudFormation que poderá ser usado posteriormente para implementar a solução.

  1. Baixe esse modelo do CloudFormation  e salve-o localmente.
  2. Em sua conta central, acesse o console do AWS CloudFormation
  3. Escolha Criar a pilha  e, em seguida, escolha com novos recursos (padrão)  Com novos recursos (padrão).
  4. Na página Criar a pilha, em Especificar o  modelo (modelo) que você baixou na etapa a), selecione Fazer upload de um arquivo de modelo.
  5. Selecione Escolher arquivo e, em seguida, escolha o arquivo de modelo cloud9-mgn-monitoring.yaml  da sua pasta local.
  6. Na página Especificar detalhes de empilhamento, insira um nome para a pilha (por exemplo, MGNMonitoringCloud9Stack).
  7. Em Parâmetros, insira esses valores para os seguintes parâmetros:
    1. s3bucketName: nome do bucket do S3 em que o modelo empacotado do CloudFormation será carregado.
    2. URL ZIP do código MGN: URL do arquivo zip do código MGN.

Depois de empacotar o código Lambda da conta central e verificar se ele existe no bucket do S3 que você especificou, crie uma pilha do CloudFormation na conta central da AWS usando o modelo recém-gerado do CloudFormation central_account_monitoring_resources_packaged.yaml. Em seguida, continue com a etapa #2.

2. Implemente a solução

a. Em sua conta central

Depois de empacotar o código Lambda da conta central e verificar se ele existe no bucket do S3 que você especificou, crie uma pilha do CloudFormation na conta central da AWS usando o modelo recém-gerado do CloudFormation central_account_monitoring_resources_packaged.yaml. Os recursos da conta central devem ser implementados primeiro, pois a pilha CloudFormation da conta de destino recebe as saídas da pilha central como entrada.

  1. Faça login na conta central e abra o console do AWS CloudFormation.
  2. Confirme se a sessão do console está na mesma região da AWS do bucket do S3 no qual você empacotou o código Lambda.
  3. Escolha Criar a pilha  e, em seguida, escolha com novos recursos (padrão)  Com novos recursos (padrão).
  4. Na página Criar a pilha, em especificar o modelo, selecione carregar um arquivo de modelo.
  5. Selecione Escolher arquivo e, em seguida, escolha o arquivo de modelo central_account_monitoring_resources_packaged.yaml da sua pasta local (central_account/).
  6. Selecione Avançar.
  7. Na página Especificar detalhes de empilhamento, insira um nome para a pilha (por exemplo, MGNMonitoringCentralAccountStack).
  8. Em Parâmetros, insira esses valores para os seguintes parâmetros:
    1. EventBusPolicyPrincipal: Uma lista separada por vírgula de identificadores de contas da AWS que enviarão eventos MGN para a conta central.
    2. mgnMonitoringLambdaRoleName: O nome da função que a função central de processamento de eventos do MGN Lambda assume.
    3. SNSSubscriptionEmail: O email para o qual os alertas são enviados para bloqueio, atraso, replicação de dados transcorridos e desconexão do servidor de origem do MGN.
  9. Na página Configurar opções de empilhamento, você pode adicionar rótulos ou escolher outras opções, se quiser, e depois escolher Avançar. (Próximo).
  10. Na página de revisão, valide os parâmetros, marque a caixa de seleção para confirmar que os recursos do IAM serão criados e escolha Criar empilhamento. (Criar pilha)
  11. Certifique-se de aceitar a assinatura do SNS. Ele será enviado para o email que você forneceu no modelo do CloudFormation.

b.  Na sua conta de destino

Da mesma forma, implemente o modelo CloudFormation da conta de destino por meio do console seguindo as etapas abaixo:

  1. Faça login na conta de destino e abra o console do AWS CloudFormation.
  2. Confirme se a sessão do console está na mesma região da AWS do bucket do S3 em que você armazenou o código.
  3. Escolha Criar a pilha  e, em seguida, escolha com novos recursos (padrão)  Com novos recursos (padrão).
  4. Na página Criar a pilha, em especificar o modelo, selecione carregar um arquivo de modelo.
  5. Selecione Escolher arquivo e, em seguida, vá para a pasta target_account e selecione target_account_monitoring_resources.yaml.
    1. Selecione Avançar.
    2. Na página Especificar detalhes de empilhamento, insira um nome para a pilha (por exemplo, mgnMonitoringTargetAccountStack).
    3. Em Parâmetros, insira esses valores para os seguintes parâmetros:
      1. CentralLambdaroLearn: O ARN da função Lambda da conta central. Você pode obtê-lo na seção “Saídas” da pilha do CloudFormation criada na conta central.
      2. CentralRegion: A região da AWS para centralizar eventos. Observe que, se o modelo de destino for implementado em outra região da mesma conta, o modelo suprimirá a criação de funções do IAM conforme elas existem.
      3. CentralEventBusArn: O ARN do EventBus da conta central: revise-o na seção “Saídas” da pilha do CloudFormation criada na conta central.
      4. LagDurationThresholdInSeconds: O limite de duração para o atraso do alarme do CloudWatch no servidor de origem do MGN. O valor padrão é 3600 segundos ou 6 horas.
      5. ElapsedReplnDurationThreholdInSeconds: O limite de duração da replicação que já passou para o alarme do CloudWatch no servidor de origem do MGN. O valor padrão é 7776000 segundos ou 90 dias. Quando esse limite for excedido, os clientes incorrerão em custos de uso do AWS MGN.
      6. LagDurationPeriodInSeconds: O período durante o qual os pontos de dados são coletados para exceder o limite de duração do atraso. O valor padrão é 300 segundos ou 5 minutos.
      7. ElapsedReplnDurationPeriodInSeconds: O período durante o qual os pontos de dados são coletados por violações do limite de duração da replicação cumulativa. O valor padrão é 300 segundos ou 5 minutos.
      8. LagDurationEvaluationPeriod: o número de períodos que o CloudWatch avaliará ao determinar o status do alarme. O valor padrão é 1.
      9. ElapsedReplnDurationEvaluationPeriod: O número de períodos que o CloudWatch avaliará ao determinar o status do alarme. O valor padrão é 1.
      10. AlarmLambdaExecutionRolename: O nome da função do Lambda IAM para criar e excluir alarmes do CloudWatch. O valor padrão é  MGN-Monitoring-Generic-Alarm-Lambda-Role.
      11. TargetAccountRetRuleRoleName: O nome da função IAM da regra EventBridge que permite que a regra coloque eventos no EventBus central. O valor padrão é MGN-Monitoring-Generic-EventBridge-Invoke-EventBus-Role.
      12. CentralAccountLambdaRolename: O nome da função do IAM que assumirá a função Lambda da conta central com permissão somente de leitura para o AWS MGN na conta de destino. O valor padrão é  MGN-Monitoring-Generic-Central-Account-Lambda-Role. Observe que, se o nome dessa função for alterado, isso também deverá ser refletido no código Lambda Python da conta central.
    4. Na página Configurar opções de empilhamento, você pode adicionar rótulos ou escolher outras opções, se quiser, e depois escolher Avançar.
    5. Na página de revisão, valide os parâmetros, marque a caixa de seleção para confirmar que os recursos do IAM serão criados e escolha Criar pilha.

Testando a solução

Para testar a solução que você implementou nas etapas anteriores, você pode ativar manualmente os eventos MGN para simular eventos de migração em tempo real. Na próxima seção, analisaremos alguns dos eventos e alarmes do MGN e apresentaremos opções sobre como você pode ativar manualmente esses eventos para testá-los.

Evento de replicação de dados paralisado

Depois de instalar o agente do Application Migration Service (MGN) em um servidor de origem, uma instância EC2 com a tag de nome AWS Application Migration Service Replication Server será criada na conta da AWS de destino. Esse servidor facilita a replicação de dados do servidor de origem para a AWS. Para que a replicação continue, o servidor de replicação e o agente devem se comunicar pela porta 1500. Portanto, você pode modificar as regras do grupo de segurança associadas à instância de replicação MGN para fechar a porta 1500 e interromper a replicação.

Além disso, no servidor de origem, você pode interromper o agente de replicação, que também interrompe a replicação. Qualquer um desses cenários causará uma estagnação do evento de replicação de dados que corresponde à regra EventBridge da conta do Target que criamos por meio da conta do Target CloudFormation Stack. A ativação dessa regra encaminha esse evento para o EventBus central. Em seguida, você verá um email informando que a replicação de dados está paralisada no servidor e uma entrada de registro no grupo central de registros do CloudWatch.

A notificação por email resultante é mostrada abaixo:

Duração do atraso

Para alarmes do CloudWatch com duração de atraso, você pode definir o limite de alarme para 1 segundo no alarme de duração do atraso e adicionar ou criar um arquivo grande no servidor de origem. Isso gerará um evento de atraso que também enviará um email indicando que o servidor está atrasado no servidor e uma entrada de registro no grupo central de registros do CloudWatch.

A notificação por email resultante é mostrada abaixo:

Tempo de replicação decorrido

Para a duração da replicação decorrida, defina o limite de alarme como 1 segundo no alarme de duração de replicação decorrida. Isso fará com que o limite da duração da replicação decorrida seja violado e o alarme do CloudWatch chegue ao estado de ALARME. Isso também fará com que a solução envie um email indicando que o servidor está atrasado no servidor e uma entrada de registro no grupo central de registros do CloudWatch.

A notificação por email resultante é mostrada abaixo:

Servidor de origem desconectado

Para desconectar um servidor de origem, acesse o console do AWS Application Migration Service, selecione um servidor de origem na lista, clique no menu suspenso Ações e selecione Desconectar do serviço. Isso gerará o evento de desconexão do servidor de origem.

A notificação por email resultante é mostrada abaixo:

Processo de limpeza

Para limpar a configuração do MGN Monitoring e os componentes implementados pelas pilhas do AWS CloudFormation, siga as etapas abaixo.

Use o console do AWS CloudFormation ou o AWS CLI para remover as pilhas do CloudFormation que foram implementadas como parte das etapas 1 e 2 da implementação da solução, nas contas centrais e de destino da AWS. A exclusão das pilhas do CloudFormation em ambas as contas excluirá todos os recursos definidos nos modelos central e de destino do CloudFormation.

Na conta central, exclua o bucket do S3 e o código Lambda que você carregou anteriormente.

Conclusão

Com a solução descrita neste blog, você pode monitorar o status de sua migração de rehost da AWS em várias contas e regiões a partir de um local central. Além disso, você pode incluir eventos da MGN e personalizar ainda mais essa solução para incluir esses alertas nas ferramentas de monitoramento e alerta da sua empresa, como Moogsoft, ServiceNow etc., para criar automaticamente incidentes e ter visibilidade em tempo real dos problemas que podem afetar sua migração de rehost para a AWS. A solução também é extensível para incluir o monitoramento de outros eventos emitidos pela MGN durante o ciclo de vida da migração.

 

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre os autores

Tom Conlin é arquiteto de infraestrutura em nuvem da AWS Professional Services. Ele gosta de criar soluções automatizadas e nativas da AWS para clientes. Em seu tempo livre, ela gosta de relaxar com a família e amigos, viajar e ser voluntária em um centro local de resgate de cães.

 

 

 

 

Ajay Mehta é arquiteto sênior de infraestrutura de nuvem da AWS Professional Services. Trabalhe com clientes corporativos para acelerar a adoção da nuvem criando zonas-alvo e transformando as organizações de TI para que adotem práticas operacionais de nuvem e operações ágeis. Quando não está trabalhando, ela gosta de passar tempo com a família, viajar e explorar novos lugares.

 

 

 

 

Santosh Vallurupalli é arquiteto de infraestrutura em nuvem e faz parte da equipe de serviços profissionais da AWS. Ele gosta de ajudar os clientes no processo de adoção da nuvem e criar soluções nativas da nuvem para problemas complexos. Quando não está trabalhando, ele gosta de viajar e assistir “The Office” no modo de repetição

 

 

 

 

 

Tradutor

Luis Alberto é um profissional com mais de 28 anos de experiência em tecnologia. Ele está localizado na Colômbia e é arquiteto de soluções, especializado em questões de migração para a AWS para clientes de diferentes setores na América Latina. Ela está focada em apoiar seus clientes na adoção de ferramentas que os ajudem a acelerar sua migração para a AWS.

 

 

 

 

Revisor

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 da 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