Proteja as cargas de trabalho do Hyper-V com o AWS Elastic Disaster Recovery

Por Bill Chan e Daniel Covey, Arquitetos de Soluções na AWS.

A recuperação de desastres (DR) é um processo essencial para qualquer organização que queira manter a continuidade dos negócios no caso de um desastre, como inundação, falha de energia ou ataque de ransomware. A estratégia de DR adotada pelas organizações geralmente é orientada por uma compensação entre o custo e o impacto comercial do tempo necessário para que as cargas de trabalho sejam disponibilizadas, conforme medido pelo Objetivo de Tempo de Recuperação (RTO – Recovery Time Objective), ou pela quantidade de perda de dados tolerável, medida pelo Objetivo de Ponto de Recuperação (RPO – Recovery Point Objective). Os clientes geralmente usam a virtualização para reduzir custos e melhorar a eficiência operacional de seus investimentos em infraestrutura. O Hyper-V é uma opção para implementar a virtualização de hardware fornecida pela Microsoft. Ao usar a virtualização, você ainda deve planejar a recuperação de desastres e a continuidade dos negócios no caso de uma falha imprevista.

O AWS Elastic Disaster Recovery fornece DR para aplicações na Amazon Web Services (AWS) a partir de infraestrutura física e virtual, bem como infraestrutura de nuvem de outros provedores de nuvem. O Elastic Disaster Recovery pode proteger as cargas de trabalho do Hyper-V que são executadas localmente e permitir que você alcance RTOs em minutos e RPOs em segundos. O Elastic Disaster Recovery usa um ambiente de preparação leve com recursos mínimos para manter os custos baixos e manter uma cópia atualizada dos seus servidores de origem na AWS. Isso contrasta com as estratégias tradicionais de DR on-premises, que precisam da duplicação de recursos em um local de recuperação, muitas vezes permanecendo ociosas e com alto custo. Com o Elastic Disaster Recovery, os recursos em seu local de recuperação só são escalados para a capacidade de produção no caso de um desastre.

Neste blog, mostramos como o Elastic Disaster Recovery pode proteger cargas de trabalho em execução no Hyper-V. Demonstraremos como configurar o Elastic Disaster Recovery, realizar uma recuperação na AWS e, em seguida, retornar ao ambiente on-premises. Economize custos removendo recursos ociosos do site de recuperação, recupere suas aplicações em minutos e use um processo unificado para testar, recuperar e fazer o failback de uma ampla variedade de aplicações, tudo isso sem precisar de habilidades especializadas.

Visão geral da solução

A solução abrange dois fluxos de DR:

Um failover de uma máquina virtual (VM) Hyper-V de um ambiente on-premises para uma região de recuperação na AWS.
Um failback da VM Hyper-V recuperada em uma instância do Amazon Elastic Compute Cloud (Amazon EC2) da região de recuperação para o ambiente on-premises.

Observação: para simplificar, usaremos a Internet pública para conectividade nesta solução, mas você também pode configurar a conectividade privada para seu caminho de replicação, conforme mostrado neste blog.

Fluxo da solução de failover

Figura 1: Arquitetura da solução de recuperação de desastres Hyper-V on-premises usando o Elastic Disaster Recovery

No fluxo de failover, a solução é composta pelos seguintes componentes:

Um ambiente Hyper-V on-premises executando um sistema operacional compatível. Esta postagem usa uma VM do Windows, mas o processo também se aplica ao Linux. Consulte a documentação do Elastic Disaster Recovery para obter uma lista dos sistemas operacionais compatíveis.
Um agente de replicação do Elastic Disaster Recovery instalado no servidor de origem executa a replicação em nível de bloco e envia dados diretamente do servidor de origem para o servidor de replicação no ‘blog-staging-vpc’.
A área de preparação usa uma instância EC2 de baixo porte para o servidor de replicação e um volume Amazon Elastic Block Storage (Amazon EBS) de baixo custo de tamanho idêntico para o volume de armazenamento.
Quando uma recuperação é iniciada, o Elastic Disaster Recovery inicia automaticamente uma VM do Windows na ‘blog-recovery-vpc’ com base nas configurações de inicialização definidas.
O serviço Elastic Disaster Recovery fornece a interface para definir as configurações de replicação e realizar ações como iniciar uma recuperação e iniciar um failback.

Fluxo da solução de failback

Figura 2: Arquitetura da solução de failback da AWS para o ambiente Hyper-V on-premises

O fluxo de failback é composto pelos seguintes componentes:

A instância de recuperação em execução na ‘blog-recovery-vpc’.
Use a ISO do Failback Client para criar uma VM no Hyper-V que atue como destino para a instância de recuperação na ‘blog-recovery-vpc’. Você tem a opção de retornar ao servidor base original ou a um servidor diferente. Nesta postagem, mostraremos o processo de failback para uma nova VM no ambiente on-premises. Para obter mais detalhes, consulte “Passo a passo detalhado do Failback Client”.

Passo a passo

A lista a seguir resume as etapas para implantar o Elastic Disaster Recovery para Hyper-V on-premises e validar o processo de failover/failback:

Configurar o serviço AWS Elastic Disaster Recovery
Instale o AWS Replication Agent na VM do Windows
Iniciar uma recuperação para a VM
Valide a instância recuperada
Execute um failback on-premises da VM

Pré-requisitos

Para este passo a passo, você deve ter os seguintes pré-requisitos:

Uma conta da AWS
Um ambiente Hyper-V on-premises executando uma VM
Uma VPC de teste, uma subnet pública de staging e um gateway de Internet (IGW)
Uma VPC de recuperação, uma sub-rede pública de recuperação e um IGW
Um usuário do AWS Identity and Access Management (IAM) com as políticas gerenciadas “AWSElasticDisasterRecoveryAgentInstallationPolicy” e “AWSElasticDisasterRecoveryFailbackInstallationPolicy”. Observe o ID da Access Key e a Secret Access Key do usuário do IAM, pois isso é necessário para o processo de instalação do agente de replicação e do cliente de failback. Consulte a criação de um usuário do IAM em sua conta da AWS para obter detalhes. Observe que usamos um usuário do IAM para simplificar. Como melhor prática de segurança, consulte “Gerar as credenciais necessárias da AWS” para gerar credenciais temporárias.
Um grupo de segurança de recuperação no ‘blog-recovery-vpc’ que permite acesso de entrada TCP nas portas 3389 (para RDP) e 1500 (para replicação)

Observe que, se você não tiver um ambiente Hyper-V disponível, consulte este repositório do GitHub para obter um modelo de amostra do AWS CloudFormation (usado como está e não suportado pela AWS) para implantar uma infraestrutura na AWS que simula um ambiente Hyper-V on-premises, junto com os componentes de suporte da arquitetura de rede Elastic Disaster Recovery descritos nesta solução.

1. Configurar o AWS Elastic Disaster Recovery

1. Se estiver inicializando o AWS Elastic Disaster Recovery pela primeira vez, siga as etapas do assistente Configurar o AWS Elastic Disaster Recovery, conforme mostrado a seguir. Essa etapa precisa do usuário administrador da sua conta da AWS ou de um usuário do IAM com permissões listadas em Inicializando o AWS Elastic Disaster Recovery. Se você já inicializou o AWS Elastic Disaster Recovery, atualize as configurações padrão de replicação e inicialização com os parâmetros de entrada mostrados a seguir. Na Etapa 1, defina a subnet da área de teste como sua subnet pública de teste (como ‘blog-staging-public-subnet’). Mantenha o tipo de instância do servidor de replicação como ‘t3.small’:

Figura 3: Etapa 1 da configuração do AWS Elastic Disaster Recovery — servidores de replicação

2. As etapas 2 (Especificar volumes e grupos de segurança), 3 (Definir configurações adicionais de replicação) e 4 (Definir configurações padrão de inicialização do DRS) definem os volumes de replicação, os grupos de segurança, a limitação de dados, a política de retenção e as configurações de inicialização padrão. Mantenha os valores padrão para essas etapas.

3. Na Etapa 5, defina a subnet como sua subnet pública de recuperação (como ‘blog-recovery-public-subnet’) e os grupos de segurança como o grupo de segurança que você criou:

Figura 4: Etapa 5 da configuração do AWS Elastic Disaster Recovery — Launch Template default no Amazon EC2

4. Na Etapa 6, Revisar e inicializar, revise a tela de resumo e selecione Configurar e inicializar.

5. Edite o Default Launch Template no EC2. Nas configurações avançadas, verifique se a opção Auto Assign Public IP está definida como Sim.

2. Instale o AWS Replication Agent na VM Hyper-V para adicioná-lo como servidor de origem

Baixe o exe em ‘https://aws-elastic-disaster-recovery-<REGION>.s3.<REGION>.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe‘, substituindo o <REGION> pela região da AWS na qual você está replicando. Se seu servidor de origem for uma VM Linux, consulte as instruções de instalação do agente para Linux. Usando o PowerShell, baixe o agente de replicação executando:

Invoke-WebRequest “https://aws-elastic-disaster-recovery-<REGION>.s3.<REGION>.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe” -outfile “AwsReplicationWindowsInstaller.exe”

No PowerShell, execute o arquivo de instalação do agente AWSReplicationWindowsInstaller.exe como administrador, usando o ID da Access Key e o ID da Secret Key do seu usuário do IAM:

.\AwsReplicationWindowsInstaller.exe –-region ap-southeast-2 –-aws-access-key-id <DRSIAMAccessKeyId> --aws-secret-access-key <DRSIAMSecretAccessKey>

Quando solicitado, pressione ‘Enter’ para replicar todos os discos. A imagem a seguir mostra a saída de uma instalação bem-sucedida do AWS Replication Agent:

Figura 5: Saída da linha de comando para a instalação do agente de replicação no servidor Windows 2019

3. Depois que o agente de replicação for instalado com sucesso, você deverá ver a VM do Windows adicionada como servidor de origem no console do AWS Elastic Disaster Recovery:

Figura 6: Windows VM nos servidores de origem do console Elastic Disaster Recovery

4. Depois que a sincronização inicial for concluída, o servidor de origem estará pronto para recuperação e poderemos iniciar uma recuperação:

Figura 7: Status do servidor de origem da VM Windows

3. Iniciar uma recuperação

Agora que o servidor de origem está pronto para recuperação, podemos selecionar o nome do host da VM e iniciar um trabalho de recuperação selecionando a opção Iniciar recuperação:

Figura 8: Início de uma recuperação no console do Elastic Disaster Recovery

2. Escolha um ponto no tempo a partir do qual iniciar as instâncias de recuperação para o servidor de origem:

Figura 9: Selecione um momento para iniciar o trabalho de recuperação

3. Você também pode ver o histórico de cada job de recuperação:

Figura 10: Histórico do job de recuperação

4. Quando a recuperação for concluída, uma nova instância será criada para a VM. Selecione o ID da instância para obter mais detalhes sobre a instância recuperada.

Figura 11: Instância recuperada da VM do Windows

4. Valide a instância recuperada

Agora que o servidor de origem foi recuperado, valide se ele está funcionando usando um cliente RDP (Remote Desktop Protocol Client) para se conectar à VM do Windows 2019. Você deve ver o painel do Server Manager no primeiro login bem-sucedido:

Figura 12: Server Manager após login bem-sucedido

2. Crie um arquivo de texto vazio (por exemplo, ‘test.txt’), que usamos para validar se o processo de failback contém atualizações feitas na instância recuperada.

5. Execute um failback da VM do Windows para o ambiente on-premises

Em Instâncias de recuperação, a VM do Windows tem uma ação pendente de Usar cliente de failback, que é necessária para fazer o failback da VM do Windows para o ambiente on-premises.
Na instância bare metal do Hyper-V, baixe a ISO do Failback Client em ‘https://aws-elastic-disaster-recovery-<REGION>.s3.<REGION>.amazonaws.com/latest/failback_livecd/aws-failback-livecd-64bit.iso‘ substituindo o <REGION> pela região da AWS na qual você está replicando. Usando o PowerShell, baixe o ISO do Failback Client executando:

Invoke-WebRequest “https://aws-elastic-disaster-recovery-<REGION>.s3.<REGION>.amazonaws.com/latest/failback_livecd/aws-failback-livecd-64bit.iso” -outfile “aws-failback-livecd-64bit.iso”

Abra o Hyper-V Manager on-premises e crie uma nova VM para fazer o failback da VM de recuperação. Os parâmetros usados nesta postagem para o New Virtual Machine Wizard são:

a. Nome: Elastic Disaster Recovery Failback VM

b. Escolha a geração dessa máquina virtual: Geração 1

c. Memória de inicialização: 10240 MB

d. Conexão: Hyper-VSwitch

e. Opções de instalação

i. Instale um sistema operacional a partir de um CD/DVD-ROM inicializável. Arquivo de imagem (.iso): C:\<path to file>\aws-failback-livecd-64bit.iso

4. Inicie a VM. Depois que a VM Linux for inicializada, você será solicitado a fornecer o seguinte:

a. Entre na região da AWS para retornar a partir de: ap-southeast-2

b. Insira um endpoint personalizado do Amazon Simple Storage Service (Amazon S3) (deixe em branco se não for relevante):

c. AWS Access Key: use o acesso para seu usuário do IAM

d. AWS Secret Access Key: use a chave secreta para seu usuário do IAM

e. ID da instância (como i-xxxx). Insira a entrada: <instance-id of the Windows VM>

5. O processo de failback mapeia os volumes de recuperação, instala o software de replicação, associa o agente de replicação ao cliente de failback e executa a replicação (conforme mostrado a seguir):

Figura 13: Saídas de linha de comando para o processo de failback na VM

6. Depois que a replicação de dados for concluída, selecione a instância e execute a ação de failback completo por meio do console do Elastic Disaster Recovery:

Figura 14: Ação de failback concluída no console do Elastic Disaster Recovery

7. Depois que o failback for concluído com êxito, a VM de failback se tornará o novo servidor de origem para iniciar uma recuperação. Use um cliente RDP para fazer login na VM de failback e verificar se o arquivo de texto vazio ‘test.txt’ (criado em uma etapa anterior) existe:

Figura 15: Failback bem-sucedido da VM do Windows 2019

Limpando

Para evitar cobranças futuras, remova os recursos que foram criados na configuração do ambiente. Isso inclui encerrar quaisquer instâncias de recuperação lançadas e servidores de replicação criados como parte do serviço Elastic Disaster Recovery. Consulte o guia do usuário do Amazon EC2 para obter detalhes sobre como encerrar uma instância, excluir um volume do EBS ou excluir um snapshot do EBS.

Conclusão

É fundamental que as organizações mantenham a continuidade dos negócios em caso de desastre, tais como inundação ou ataque de ransomware. Neste post, demonstramos como você pode proteger e recuperar cargas de trabalho do Microsoft Hyper-V em execução em um data center on-premises usando o Elastic Disaster Recovery. Começamos inicializando o serviço Elastic Disaster Recovery, seguido pela instalação do agente Elastic Disaster Recovery. Depois que isso foi concluído, conseguimos obter proteção contínua de dados entre nosso servidor de origem e o servidor de replicação. Em seguida, iniciamos uma recuperação na região alvo da AWS, em resposta a um evento de DR, e validamos nossa instância de recuperação. Depois de validarmos nossa recuperação, retornamos ao ambiente base original, concluindo o ciclo de vida de DR.

O AWS Elastic Disaster Recovery adota uma abordagem Pilot Light para a recuperação de desastres, que minimiza o tempo de inatividade e a perda de dados com a recuperação rápida e confiável de aplicações on-premises e baseados na nuvem usando armazenamento acessível, computação mínima e recuperação pontual. Com o Elastic Disaster Recovery, os clientes podem obter RTOs em minutos e RPOs em segundos.

Consulte este guia de introdução para obter mais detalhes sobre como você pode minimizar o tempo de inatividade e a perda de dados com a recuperação rápida e confiável de aplicações on-premises e baseados em nuvem usando o Elastic Disaster Recovery. Obrigado por ler este post. Se você tiver algum comentário ou pergunta, não hesite em deixá-los abaixo.

Esse artigo foi originalmente publicado em inglês no AWS Blog (link aqui).

Autores

	Bill Chan é arquiteto de soluções corporativas e trabalha com grandes empresas para criar arquiteturas de nuvem altamente escaláveis, flexíveis e resilientes. Ele ajuda as organizações a entender as melhores práticas em relação a soluções avançadas baseadas em nuvem e como migrar cargas de trabalho existentes para a nuvem. Ele gosta de relaxar com a família e jogar basquete.
	Daniel Covey é arquiteto de soluções da AWS e passou os últimos 8 anos ajudando clientes a proteger suas cargas de trabalho durante um desastre. Ele trabalhou com a CloudEndure antes e depois da aquisição pela AWS e continua oferecendo orientação aos clientes que desejam garantir que seus dados estejam protegidos contra ransomware e desastres.

Tradutores/Revisores

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 15 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

Lucas Henrique Garcia é Arquiteto de Soluções do time de Enterprise e trabalhou previamente no time de Premium Support da AWS em Dublin. Seu foco está em ajudar clientes da AWS a resolverem seus problemas e a desenhar arquiteturas para seus negócios.

O blog da AWS