Criando uma estratégia de disaster recovery com o AWS Elastic Disaster Recovery

Por Gabriel Marchelli, Startups Solution Architect e
Victor I. Yamashita, Startups Solution Architect

Introdução

Muitos clientes começam sua jornada para a AWS buscando por uma estratégia de Disaster Recovery do seu ambiente on-premises, as justificativas para optar por um ambiente de Disaster Recovery são diversas, como a recuperação de incidentes imprevisíveis, oferecer maior credibilidade para a organização, maior economia considerando que o custo de uma indisponibilidade duradoura costuma ser consideravelmente maior do que o custo de um ambiente de contingência, e, por último, atingir uma alta disponibilidade.

Além da estratégia de Disaster Recovery do ambiente on-premises ou de outros provedores de Cloud para a AWS, clientes também fazem o uso do AWS Elastic Disaster Recovery (AWS DRS) em servidores que já estão rodando na AWS, para criar uma estratégia de Disaster Recovery em outra região.

As estratégias de Disaster Recovery disponíveis para você na AWS podem ser categorizadas em quatro abordagens, variando de baixo custo e baixa complexidade de apenas fazer backups a estratégias mais complexas usando várias regiões ativas dentro da AWS.

A escolha da estratégia correta deve considerar variáveis como o RTO (Recovery Time Objective), que se baseia no tempo que um sistema leva para se recompor e retomar as atividades após sofrer uma parada. E no RPO (Recovery Point Objective) que seria a quantidade de dados que a empresa toleraria perder se sofresse uma parada no funcionamento dos sistemas.

As 4 abordagens de recuperação de desastres levando em conta o RPO/RTO podem ser visualizadas na imagem abaixo:

O AWS DRS, permite que as organizações façam um plano de recuperação de suas aplicações com downtime mínimo e sem alterações nas aplicações e na sua arquitetura. O AWS DRS usa a estratégia Pilot Light, mantendo uma cópia dos dados e recursos necessários para replicação (Intâncias de Replicação) em uma Amazon Virtual Private Cloud (Amazon VPC), usada como área de preparação. Quando um evento de failover é acionado, os recursos preparados são usados para criar automaticamente uma implantação de capacidade total no Amazon VPC de destino, usado como o local de recuperação. Para mais informações consulte a documentação do serviço: https://docs.thinkwithwp.com/drs/latest/userguide/what-is-drs.html

A replicação dos dados para a área de preparação proporciona uma redução dos custos de Disaster Recovery, considerando que os servidores serão provisionados no ambiente de contingência somente quando necessário. O AWS DRS possibilita realizar testes sem interrupções para confirmar a integridade do processo. Quando necessário, podemos iniciar a operação de Disaster Recovery, escolhendo entre o estado mais recente do servidor ou algum ponto de recuperação anterior no tempo. Iniciada a operação de Disaster Recovery, o AWS DRS provisionará o novo ambiente em poucos minutos. Após a resolução do problema no seu site principal, você poderá fazer o failback. Na continuidade deste blogpost iremos demonstrar como executar todos esses processos.

Imagem que ilustra o funcionamento do AWS DRS:

Neste blog mostraremos como configurar uma solução de disaster recovery utilizando o AWS DRS em 6 etapas, sendo elas:

Configuração do AWS DRS
Instalação do agente de replicação
Monitoramento da replicação
Testes de integridade
Ativação do ambiente DR
Replicação Reversa e Failback

Para essa demonstração, configuramos um servidor com WordPress na Região AWS South America (São Paulo) (sa-east-1) (https://docs.thinkwithwp.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html) para servir como nosso Corporate Data Center (figura 3), e criaremos nosso ambiente de disaster recovery na região AWS N. Virginia (us-east-1), onde ficará a “Staging Area” e a “Recovery Area”.

O primeiro passo é definir em qual região AWS você usará para o seu ambiente de Disaster Recovery e configurar a fundação, como Amazon VPC, Subnet’s publicas/privadas, tabelas de roteamento, Security Groups e etc. Utilizaremos essas informações e recursos para criarmos o Modelo de Execução (Launch Template) do Amazon Elastic Compute Cloud (Amazon EC2). Caso queira entender melhor o que são os modelos de execução, visite https://docs.thinkwithwp.com/pt_br/AWSEC2/latest/UserGuide/ec2-launch-templates.html.

Com a fundação criada, vamos acessar o serviço do AWS DRS. Para isso utilize a caixa de pesquisa no console AWS e procure por AWS DRS, ou pelo menu Serviços / Armazenamento / AWS Elastic Disaster Recovery.

Ao acessar o serviço, se você nunca utilizou AWS DRS antes nessa região, você será direcionado para a página de configuração, onde em apenas 4 etapas você estará pronto para iniciar a replicação.

Caso você já tenha feito essas configurações e queira ajusta-las, você pode fazer através do menu Configurações.

1 – Configuração do AWS DRS

Etapa 1 – Configuração dos servidores de replicação

Nessa etapa você vai definir a subnet da área de staging e o tipo de instância para os servidores de replicação. Para mais informações em como melhor definir um tipo de instância, acesse https://docs.thinkwithwp.com/drs/latest/userguide/replication-server-settings.html?icmpid=docs_console_unmapped#instance-type.

Etapa 2 – Volumes e grupos de segurança

Aqui vamos definir o tipo de volume que será utilizado nos servidores de replicação, criptografia do volume e grupos de segurança. Os valores mostrados na figura abaixo são definidos por padrão, mas você pode customizá-los conforme a necessidade.

Etapa 3 – Configurações adicionais

Nessa etapa você poderá configurar se a comunicação entre os seus servidores on-premises e os servidores de replicação será de forma publica (via internet) ou de forma privada, fazendo o uso de conexões VPN, DirectConnect ou VPC Peering.

Também é possível limitar a largura da banda da rede utilizada conforme as limitações de conexão que você tiver. Por exemplo, caso você tenha apenas um link de internet em seu ambiente on-premises e parte desse link precisa ser utilizado pelos seus servidores, você pode limitar o uso de banda para não afetar essas comunicações.

E por último, o tempo de retenção dos snapshots gerados e as tags de alocação.

Etapa 4 – Revisão

Essa ultima etapa é uma revisão do que foi configurado. Revise e, estando tudo certo, clique em “Create default”.

Após essa configuração, estaremos prontos para instalar o agente em nosso servidor on-premises e iniciar a replicação.

Vale lembrar que essas configurações poderão ser customizadas para cada servidor caso haja a necessidade.

2 – Instalação do agente de replicação

O agente de replicação do AWS DRS é compatível com sistemas operacionais Linux e Microsoft Windows. As versões suportadas podem ser consultadas na documentação https://docs.thinkwithwp.com/drs/latest/userguide/Supported-Operating-Systems.html.

Durante a instalação do agente, será solicitado o Access Key ID e o Secret Access Key, que são as credenciais que permitirão os seus servidores se comunicarem com os serviços da AWS. Para a criação dessas credenciais, siga os passos fornecidos na documentação https://docs.thinkwithwp.com/drs/latest/userguide/credentials.html.

Com as credenciais criadas, podemos seguir com a instalação do agente. Para isso, acesse o menu “Actions / Add replicating source servers”, localizado na aba “Source servers” do AWS DRS, e clique em “Learn more”, ou acesse diretamente o link https://docs.thinkwithwp.com/drs/latest/userguide/adding-servers.html.

Ao acessar essa página, você selecionará o sistema operacional em que deseja instalar e seguirá as instruções. No ambiente demonstrado, o servidor é baseado em Linux. Nesse link você encontra o passo-a-passo para a instalação do agente https://docs.thinkwithwp.com/drs/latest/userguide/agent-installation-instructions.html

Após a instalação do agente, você poderá visualizar os servidores e acompanhar todo o progresso da replicação a partir da aba “Source servers” do AWS DRS. O primeiro status que aparecerá é de “Initiating”, que é a primeira fase onde o AWS DRS configura as instâncias de replicação cria os componentes de redes necessários e inicia a replicação.

3 – Monitoramento da replicação

Podemos acompanhar o status da replicação acessando os detalhes de cada “Source servers”. Se os passos anteriores forem executados com sucesso, você conseguirá ver a porcentagem da replicação, assim como outras informações relacionadas ao seu servidor.

Algumas das informações mais relevantes sobre o status da replicação são:

Lag – RPO (Recovery Point Objective)
Replication progress – O progresso, em porcentagem, da replicação.
Backlog – A quantidade (em MiB) de dados que foram escritos em seu servidor e que ainda não foram replicados para o AWS DRS.

4 – Teste de Integridade

É possível realizar um teste de integridade do ambiente de Disaster Recovery, esse teste irá provisionar servidores na região escolhida da AWS. Esse cenário possibilita uma validação do funcionamento correto da estratégia de Disaster Recovery.

Antes de executar o teste de integridade, é necessário validar se o “Source Server” já está com o status “Ready” dentro da coluna “Ready for Recovery”. Após a validação do status “Ready”, o próximo passo é selecionar “Initiate Recovery Job” e, em seguida, selecionar “Initiate Recovery Drill”.

O próximo passo é escolher de qual “Points in time” você deseja fazer a recuperação. Os “Points in time” são imagens do servidor de origem em diferentes horários, onde você pode escolher se deseja utilizar a sincronização mais recente ou optar por algum momento mais antigo do servidor. Nesse exemplo foi escolhido a versão mais recente e, após escolher a opção desejada, basta clicar em “Initiate drill”.

Para acompanhar o status do teste de integridade, você pode clicar em “Recovery job history” no lado esquerdo da tela, e em seguida clicar no “Job ID” correspondente:

Na próxima tela é possível acompanhar todas as tarefas que foram executadas até o término da recuperação e os logs do evento aparecerão dentro do quadro “Job log”. Note que entre os logs aparecerá alguns de conversão, esses logs correspondem a conversão automática que o AWS DRS realiza para tornar as instâncias compatíveis com a Cloud.

Após o término da recuperação, você notará que a nova instância aparecerá listada entre as instâncias do Amazon EC2 (Como consultar instâncias do Amazon EC2: https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/concepts.html). A partir desse momento, você pode acessar a instância e validar a funcionalidade do DR. Note que, no exemplo, há apenas uma única instância, mas esse exemplo é escalável para um parque completo de servidores.

Para mais informações sobre o teste de integridade, você pode consultar a documentação do AWS DRS: https://docs.thinkwithwp.com/drs/latest/userguide/failback-overview.html

5 – Ativação do ambiente DR

A qualquer momento, podemos ativar o ambiente de recuperação de desastres, que será provisionado de acordo com as configurações de instâncias e de rede escolhidas na etapa de “Configuração do AWS DRS” do tutorial.

Antes de provisionar o ambiente de recuperação de desastres é necessário validar se o “Source Server” já está com o statuts “Ready” dentro da coluna “Ready for Recovery”. Após a validação do status “Ready”, o próximo passo é selecionar “Initiate Recovery Job” e, em seguida, selecionar “Initiate Recovery”.

Em seguida, devemos escolher de qual ponto no tempo desejamos fazer a recuperação. Os “Points in time” são imagens dos servidores de origem em diferentes horários, onde você pode escolher se deseja utilizar a sincronização mais recente ou optar por algum momento mais antigo do servidor. Nesse exemplo foi escolhido a versão mais recente e, após escolher a opção desejada, basta clicar em “Initiate recovery”.

Para acompanhar o status do provisionamento, você pode clicar em “Recovery job history” no lado esquerdo da tela, e, em seguida, clicar no “Job ID” correspondente.

A principal diferença entre o teste de integridade e a ativação do ambiente de Disaster Recovery está na continuidade da sincronização dos dados do ambiente primário. Durante o teste, os dados continuam sendo replicados para a área de staging, diferentemente do que acontece durante a ativação do ambiente. Após concluir o provisionamento do ambiente de contingência, a sincronização com o ambiente primário é pausada. Observando a figura abaixo, podemos notar o status “Not Started” na coluna “Reversed direction launch state”. O serviço está aguardando o início da replicação reversa para a possibilidade do failback, o que é esperado após a resolução dos problemas que levaram a indisponibilidade do ambiente primário.

Após o término do provisionamento do ambiente de recuperação, você notará que a nova instância aparecerá listada entre as instâncias de Amazon EC2 (Como consultar instâncias do Amazon EC2: https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/concepts.html). Note que, no exemplo, há apenas uma única instância, mas esse exemplo é replicável para um parque completo de servidores. As instâncias provisionadas no Amazon EC2 durante o teste são automaticamente terminadas durante a ativação do ambiente de DR.

Para mais detalhes você pode consultar a documentação do AWS DRS: https://docs.thinkwithwp.com/drs/latest/userguide/failback-overview.html

6 – Replicação Reversa e Failback

Algo que nos perguntamos quando temos um ambiente de Disaster Recovery ativado é: como manter meu ambiente on-premises atualizado? A resposta para isso é a feature de Replicação Reversa do AWS DRS, que permite sincronizar os dados alterados nos servidores, iniciados pelo processo de Disaster Recovery, de volta para os servidores on-premises, preservando a integridade dos dados e possibilitando um failback mais transparente.

É possível realizar essa estratégia de replicação reversa para ambos cenários, ou seja, quando você tem o ambiente on-premises e faz o Disaster Recovery na AWS ou quando os seus servidores já estão na AWS e você faz o Disaster Recovery em outra região. Entretanto, para cada estratégia, a forma de configurar a replicação reversa é diferente.

Para ativar a replicação reversa para o seu ambiente on-premises siga os passos mostrado na documentação https://docs.thinkwithwp.com/drs/latest/userguide/failback-performing-on-prem.html ou https://docs.thinkwithwp.com/drs/latest/userguide/failback-failover-drsfa.html , caso o seu ambiente esteja em VMware vCenter.

O exemplo mostrado a seguir, de replicação reversa e failback, é para o cenário de teste apresentado nesse blogpost, ou seja, os servidores de origem são do Amazon EC2 e o ambiente de Disaster Recovery é em outra região da AWS. Para mais detalhes veja a documentação https://docs.thinkwithwp.com/drs/latest/userguide/failback-failover-region-region.html.

Para simplificar o entendimento, abaixo você consegue visualizar a arquitetura da replicação reversa.

Primeiro vamos garantir que o Disaster Recovery foi ativado. Após ativar o disaster recovery, selecione a instância de recuperação e clique em “Start reversed replication”, conforme mostrado abaixo. Nesse cenário, os blocos do disco da instância iniciada pelo Disaster Recovery começarão a ser replicados para os servidores de replicação na região de origem. O AWS DRS utilizará os mesmos mecanismos da replicação para a replicação reversa.

Caso você obtenha um erro dizendo que o agente não está conectado ao AWS DRS, primeiro verifique se todos os pré-requisitos foram atendidos (https://docs.thinkwithwp.com/drs/latest/userguide/preparing-environments.html) e, então, faça a reinstalação do agente utilizando o parâmetro “—install-as-recovery-instance” e passando como valor o ID da instância replicada.

Exemplo do comando:

sudo python3 aws-replication-installer-init.py —install-as-recovery-instance s-35def9e56643ef778

Após iniciado com sucesso a replicação reversa, você poderá acompanhar o status da mesma forma como o fez para acompanhar o status da instância de recuperação, conforme mostrado na imagem a seguir.

Assim que replicação reversa for concluída, poderemos ver no AWS DRS da região de origem, nesse caso sa-east-1, um novo “Source Server”, que faz referência ao servidor iniciado pela operação de Disaster Recovery mostrado a seguir.

Para iniciar a operação de failback, basta selecionar os servidores que deseja, clicar na opção “Launch for failback”, selecionar o “point in time” que deseja e iniciar o failback.

Importante lembrar que todos os jobs, sejam eles de Disaster Recovery ou Failback, podem ser acompanhados através do “Recovery job history”, que fica no menu lateral do AWS DRS. Na figura abaixo podemos ver que o Job de failback foi concluído com sucesso e uma nova instância do Amazon EC2 foi lançada na região de origem contendo os dados atualizados do ambiente de Disaster Recovery.

Agora já podemos redirecionar o trafego de volta para o ambiente on-premises e pronto, a operação de failback foi concluída com sucesso.

Conclusão

Neste blogpost foi abordado um pouco das estratégias de Disaster Recovery e demonstrado como utilizar o serviço AWS Elastic Disaster Recovery (DRS) para obter uma replicação contínua entre o ambiente on-premises e a AWS. Entre os benefícios da utilização dessa arquitetura estão o baixo RTO e RPO e a possibilidade de realizar testes de integridade do seu ambiente de Disaster Recovery.

Sobre os autores

Gabriel Marchelli é Startups Solution Architect na AWS.

Victor I. Yamashita é Startups Solution Architect na AWS

O blog da AWS