O blog da AWS

Automatizando sua replicação para Disaster Recovery com CloudEndure e Ansible

Por Juliano Baeta, Arquiteto de Soluções para Global Systems Integrators para a América Latina

 

Continuidade de Negócios é um aspecto crítico para muitas empresas em diferentes indústrias. Desastres podem impactar a renda, causar perda de dados e prejudicar a reputação de uma companhia. Dependendo do negócio, o objetivo de ponto de recuperação (RPO – Recovery Point Objective) e objetivo de tempo de recuperação (RTO – Recovery Time Objective) podem ser mais agressivos e uma janela de horas pode não ser aceitável. Há algumas estratégias de configurações que terão um impacto direto nos números de RPO e RTO, variando de “nenhuma contingência” a uma solução altamente automatizada para recuperação de desastres.

 

Por que CloudEndure Disaster Recovery?

É aí que o CloudEndure Disaster Recovery entra em jogo. Você pode usá-lo para proteger seus bancos de dados mais críticos, incluindo Oracle, MySQL e SQL Server, bem como aplicações corporativas, como SAP.

O CloudEndure Disaster Recovery replica continuamente suas máquinas (incluindo sistema operacional, configuração do estado do sistema, bancos de dados, aplicativos e arquivos) em uma área de staging de baixo custo na sua conta AWS de destino e região preferida. No caso de um desastre, você pode instruir o CloudEndure Disaster Recovery a iniciar automaticamente milhares de suas máquinas em seu estado totalmente provisionado em minutos.

Ao replicar suas máquinas em uma área de staging e ainda ser capaz de executar máquinas totalmente provisionadas em minutos, o CloudEndure Disaster Recovery pode reduzir significativamente o custo de sua infraestrutura de recuperação de desastres.

O CloudEndure Disaster Recovery também facilita os testes recorrentes que um ambiente de recuperação de desastre demanda. Graças à esta funcionalidade é possível criar um ambiente de teste simulando um desastre sem afetar a produção nem o sincronismo dos dados. Dessa forma, pode-se validar o tempo e os procedimentos de subida do ambiente de desastre de forma automatizada. Além disso, um registro de atividades ajuda a comprovar que estes testes estão sendo realizados com periodicidade para fins de auditoria ou compliance.

 

Por que Ansible?

O Ansible é uma ferramenta open-source e agentless para gerenciamento de configuração, que se conecta a máquinas remotas usando SSH ou Windows Remote Management para executar suas tarefas. Você pode executar o Ansible a partir de máquinas locais, na nuvem ou até mesmo de seu notebook, desde que tenha o acesso necessário às máquinas remotas.

Realizar o download, instalação e configuração de qualquer ferramenta, uma a uma em centenas ou até milhares de máquinas, pode ser propenso a erros, tedioso, demorado e ineficiente. O Ansible pode simplificar muito o processo de proteção de suas máquinas por meio do CloudEndure Disaster Recovery executando as mesmas tarefas em paralelo para várias máquinas remotas.

 

Objetivo:

Neste post, vamos configurar nosso ambiente CloudEndure Disaster Recovery, automatizar o download, instalação e replicação em vários servidores CentOS por meio de um Ansible Playbook. No final, lançaremos algumas instâncias do Amazon EC2 na região de destino como parte de um teste de recuperação de desastres.

 

Arquitetura:

O CloudEndure Disaster Recovery replica seu ambiente continuamente para volumes EBS utilizados como Staging. Essa replicação é feita por instâncias chamadas de Staging Area Replication Servers. Você não precisa configurar esses servidores; eles são criados automaticamente para você como parte do processo quando você replica o primeiro servidor. Além disso, as instâncias EC2 de destino são iniciadas somente quando você testa ou inicia um failover, fornecendo uma solução econômica, já que não há ambiente de computação duplicado.

Figura 1 – Arquitetura do CloudEndure

 

Requisitos:

  • Uma conta AWS: Se você não tem uma conta na AWS, siga estas instruções para abrir uma.
  • Licenças do CloudEndure Disaster Recovery: Elas podem ser adquiridas através da AWS Marketplace.
  • Ansible instalado: Um laptop, desktop ou outra máquina com Ansible instalado. Se você não tem o Ansible, por favor acesse esta documentação para verificar como prosseguir.
  • Servidor(es) Remoto(s): Um ou mais servidores a replica através do CloudEndure Disaster Recovery. Você pode iniciar uma instância Amazon EC2 para seus testes.
  • Conectividade de rede: A conectividade de rede a seguir é necessária:
    • Comunicação através do protocolo TCP na porta 443:
      • Entre as máquinas de origem e o CloudEndure Service Manager.
      • Entre a área de Staging e o CloudEndure Service Manager.
    • Comunicação através do protocolo TCP na porta 1500:
      • Entre as máquinas de origem e a área de Staging.

 

Mãos na Massa!

Faça login na console do CloudEndure por meio da seguinte URL:

https://console.cloudendure.com/#/signIn

Figura 2 – Login em CloudEndure User Console

 

A experiência do CloudEndure é baseada em Projetos, que são as unidades organizacionais básicas para suas migrações ou ambientes de recuperação de desastres. Após o processo de login, clique no ícone no canto superior esquerdo para criar um novo projeto:

Figura 3 – Ícone no canto superior esquerdo para criar um novo projeto

 

Preencha as caixas com o nome do projeto, tipo de projeto e escolha a licença aplicável. Para o tipo de projeto, escolha “Disaster Recovery”. Depois de preencher as informações, clique em “CREATE PROJECT”:

Figura 4 – Criar novo projeto

 

O próximo pop-up irá guiá-lo através das configurações do projeto. Clique em “CONTINUAR”:

Figura 5 – Projeto criado mas não configurado ainda

 

Em “AWS CREDENTIALS”, especifique a AWS Access Key ID e a AWS Secret Access Key. O CloudEndure chama as devidas APIs para replicações através desta Access Key. Caso não tenha um usuário IAM com as permissões necessárias para o CloudEndure operar, cheque esta documentação.

Figura 6 – Credenciais AWS para o projeto

 

Em “REPLICATION SETTINGS”, escolha a região de origem, região de destino, o tipo de instância do servidor de replicação, o tipo de disco padrão e a sub-rede onde os servidores de replicação serão iniciados. No exemplo abaixo, estamos definindo um ambiente primário na América do Sul (sa-east-1) com o objetivo de Recuperação de Desastres em N. Virgínia (us-east-1):

Figura 7 – Configurações de replicação para o projeto

 

Com a configuração do projeto finalizada, clique no botão “SHOW ME HOW”:

Figura 8 – Configuração do projeto finalizada

 

A próxima janela mostra as instruções para adicionar máquinas para replicação, que incluem o token de instalação do agente e os comandos adequados para baixar e executar o instalador do CloudEndure. Usaremos essas informações para criar nosso simples playbook Ansible:

Figura 9 – Instruções de como adicionar máquinas

 

Na sua máquina Ansible, defina os hosts onde o CloudEndure será instalado. No exemplo abaixo, um grupo de hosts chamado “aws” foi criado e ele será referenciado no playbook Ansible posteriormente. Além disso, definimos a variável “ansible_user” como “centos” para especificar o usuário do sistema operacional que será usado pelo Ansible para executar as conexões remotas.

 

$ cat /etc/ansible/hosts                                                                                                                                               
[aws]
ec2-18-230-57-120.sa-east-1.compute.amazonaws.com       ansible_user=centos
ec2-54-207-23-166.sa-east-1.compute.amazonaws.com       ansible_user=centos
ec2-18-228-26-68.sa-east-1.compute.amazonaws.com        ansible_user=centos
ec2-18-230-6-97.sa-east-1.compute.amazonaws.com         ansible_user=centos
ec2-54-232-135-107.sa-east-1.compute.amazonaws.com      ansible_user=centos
ec2-18-228-241-215.sa-east-1.compute.amazonaws.com      ansible_user=centos
ec2-18-229-161-31.sa-east-1.compute.amazonaws.com       ansible_user=centos
ec2-54-94-30-48.sa-east-1.compute.amazonaws.com         ansible_user=centos
ec2-18-230-124-24.sa-east-1.compute.amazonaws.com       ansible_user=centos

 

O Playbook YAML possui os seguintes parâmetros:

  • hosts: Os hosts onde as instruções serão executadas. Como mencionado acima, estamos fornecendo um grupo chamado “aws” como os hosts remotos;
  • gather_facts: Coleta e reúne informações sobre as máquinas remotas. Iremos desativar este módulo definindo-o como “false”, para acelerar nossa execução;
  • tasks: Este playbook é composto por duas tarefas (tasks), uma para baixar o instalador e uma tarefa para executá-lo.

A primeira tarefa usa o módulo get_url que é semelhante ao comando wget recomendado pelo CloudEndure. Nós especificamos a URL, nome do arquivo de destino, owner, group e mode. A segunda tarefa executa o comando conforme especificado no console do Cloud Endure. Para as tarefas, também especificamos o parâmetro “become: true” para elevar nossos privilégios no sistema operacional para executar corretamente os comandos necessários. No comando “shell”, substitua a string abaixo após a flag “-t” com a string da licença especificada no console do CloudEndure.

 

$ cat cloud-endure.yaml
---
- hosts: aws
  gather_facts: false
  tasks:
  - name: Download CloudEndure Installer
    get_url:
      url: https://console.cloudendure.com/installer_linux.py
      dest: /home/centos/install_linux.py
      owner: centos
      group: centos
      mode: '0755'
  - name: Install CloudEndure
    shell: /usr/bin/python /home/centos/install_linux.py -t AAAA-BBBB-CCCC-DDDD-EEEE-FFFF-GGGG-HHHH-IIII-JJJJ-KKKK-LLLL-MMMM-NNNN-OOOO-PPPP --no-prompt
    become: true
...

Na sua máquina Ansible, quando você executar o playbook, o Ansible se conectará a cada host especificado no arquivo do playbook. Se os hosts exigem uma chave e os hosts compartilham a mesma chave, uma maneira fácil de executar o playbook é criar uma sessão adicionando uma chave de antemão, como no exemplo abaixo:

 

$ eval "$(ssh-agent)"
  Agent pid 59392
$ ssh-add -K [path to your key.pem file]

 

Em seguida, execute seu playbook usando o comando ansible-playbook:

$ ansible-playbook cloud-endure.yaml
PLAY [aws] *****************************************************************************************
TASK [Download CloudEndure Installer] *****************************************************************************************
changed: [ec2-54-207-23-166.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-230-6-97.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-230-57-120.sa-east-1.compute.amazonaws.com]
changed: [ec2-54-232-135-107.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-228-26-68.sa-east-1.compute.amazonaws.com]
changed: [ec2-54-94-30-48.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-228-241-215.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-230-124-24.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-229-161-31.sa-east-1.compute.amazonaws.com]
TASK [Install CloudEndure] *****************************************************************************************
changed: [ec2-54-207-23-166.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-230-6-97.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-230-57-120.sa-east-1.compute.amazonaws.com]
changed: [ec2-54-232-135-107.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-228-26-68.sa-east-1.compute.amazonaws.com]
changed: [ec2-54-94-30-48.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-228-241-215.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-230-124-24.sa-east-1.compute.amazonaws.com]
changed: [ec2-18-229-161-31.sa-east-1.compute.amazonaws.com]
PLAY RECAP *****************************************************************************************
ec2-18-228-241-215.sa-east-1.compute.amazonaws.com : ok=2    changed=2    unreachable=0    failed=0
ec2-18-228-26-68.sa-east-1.compute.amazonaws.com : ok=2    changed=2    unreachable=0    failed=0
ec2-18-229-161-31.sa-east-1.compute.amazonaws.com : ok=2    changed=2    unreachable=0    failed=0
ec2-18-230-124-24.sa-east-1.compute.amazonaws.com : ok=2    changed=2    unreachable=0    failed=0
ec2-18-230-57-120.sa-east-1.compute.amazonaws.com : ok=2    changed=2    unreachable=0    failed=0
ec2-18-230-6-97.sa-east-1.compute.amazonaws.com : ok=2    changed=2    unreachable=0    failed=0
ec2-54-207-23-166.sa-east-1.compute.amazonaws.com : ok=2    changed=2    unreachable=0    failed=0
ec2-54-232-135-107.sa-east-1.compute.amazonaws.com : ok=2    changed=2    unreachable=0    failed=0
ec2-54-94-30-48.sa-east-1.compute.amazonaws.com : ok=2    changed=2    unreachable=0    failed=0

Após a instalação do agente do CloudEndure em cada máquina, o processo de replicação de dados deve começar imediatamente e você poderá ver o progresso através do painel do CloudEndure:

Figura 10 – Progresso da replicação de dados

 

Após a conclusão da replicação inicial, você deve ver no painel, a caixa “Require Attention” com o número de máquinas replicadas. Isso significa que as máquinas estão sendo replicadas, mas nunca foram testadas:

Figura 11 – Mensagem “Require Attention” no painel

 

Enquanto as máquinas são replicadas, você pode configurar o blueprint da máquina de destino, que é o conjunto de instruções sobre como iniciar a máquina como tamanho, sub-rede, Security Groups, IPs e tipo de discos. Você pode revisar como configurar o blueprint aqui.

Como prática recomendada, é importante testar sua Recuperação de Desastres e você pode fazer isso iniciando as máquinas na região de destino em “Test Mode”. Selecione as máquinas que deseja testar e no canto superior direito, clique em “Test Mode”:

Figura 12 – Iniciar máquinas na região de destino em modo de testes

 

Confirme o lançamento das máquinas de destino e clique em “NEXT”:

Figure 13 – Confirmação de início das instâncias

 

Os pontos de recuperação (Recovery Point) funcionam como uma “máquina do tempo” e você pode voltar para qualquer ponto do tempo disponível. No exemplo abaixo vemos que temos pontos no tempo de 10 em 10 minutos, o CloudEndure também disponibiliza pontos no tempo consolidados para até 30 dias atrás.

Escolha o ponto de recuperação para teste e clique em “CONTINUE WITH LAUNCH”:

Figura 14 – Escolha o ponto de recuperação

 

Você pode monitorar o início das máquinas na região de destino por meio da opção “Job Progress” à esquerda:

Figura 15 – Progresso dos Jobs

 

O status das máquinas testadas agora muda de “Require Attention” para “Ready”.

Figura 16 – Máquinas “Ready” no painel

 

 

Na console do CloudEndure, o status de “DISASTER RECOVERY LIFECYCLE” será alterado para “Tested Recently” para cada máquina testada durante esse processo. Para “DATA REPLICATION PROGRESS”, o status será “Continuous Data Protection”.

Figure 17 – Máquinas testadas recentemente

 

No final do teste, observando o Console da AWS, você deve ver as instâncias iniciadas na região de destino:

Figura 18 – Console da AWS com máquinas iniciadas na região de destino

 

Limpando

Para evitar incorrer em encargos futuros, exclua os recursos nas regiões de origem e de destino e cancele a assinatura do CloudEndure no AWS Marketplace.

 

Conclusão

Com o CloudEndure Disaster Recovery, você pode simplificar a implementação e aumentar a confiabilidade fornecendo replicação contínua para uma região de destino. O CloudEndure Disaster Recovery permite RPO de sub-segundos e com uma conversão e orquestração automatizadas, você pode reduzir o RTO para minutos. Com o Ansible, você pode garantir que um ambiente seja protegido pelo CloudEndure Disaster Recovery em escala, executando seu playbook em centenas de máquinas locais ou instâncias Amazon EC2.

 

Sobre o autor

Juliano Fernandes Baeta é Arquiteto de Soluções para Global Systems Integrators para a América Latina. É um entusiasta de Big Data, Analytics, Machine Learning e sua missão é ajudar parceiros a construir soluções seguras, eficazes e resilientes na AWS.