Quatro estratégias de Disaster and Recovery (DR) na AWS

O que é Disaster and Recovery na AWS?

O Amazon Web Services (AWS) permite configurar a recuperação de desastres, tanto para serviços locais quanto para cargas de trabalho implantadas na nuvem da Amazon.

A AWS oferece quatro estratégias principais de recuperação de desastres (DR) que você pode aproveitar para criar backups e réplicas disponíveis durante eventos de desastres. Cada estratégia tem custo e complexidade progressivamente maiores, mas tempos de recuperação menores:

1. Backup e restauração – envolve fazer backup de seus sistemas e restaurá-los do backup em caso de desastre.
2. Pilot Light – envolve executar serviços principais no modo de espera e acionar serviços adicionais conforme necessário em caso de desastre.
3. Warm standby – envolve a execução de um sistema de backup completo no modo de espera, com dados ao vivo replicados de o ambiente de produção.
4. Multisite ativo/ativo – executando um sistema de produção secundário completo, pronto para atender ao tráfego quando necessário.

Créditos da Imagem: Amazon

Veja também: O que é RTO e RPO e por que você precisa entendê-los para seu Disaster and Recovery (DR)

Cada estratégia de DR na AWS oferece diferentes objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO) projetados em várias faixas de custos e complexidades.

Geralmente, as estratégias de DR mais complexas e altamente disponíveis têm custos mais altos e as estratégias menos complexas que oferecem menor disponibilidade são mais econômicas.

Para garantir que sua estratégia de DR atenda às necessidades de sua organização e esteja funcionando corretamente, você precisa testá-la antes da implementação inicial e novamente de forma contínua.

Neste artigo, veremos:

Estratégias de DR na AWS e seu objetivo de ponto de recuperação e objetivo de tempo de recuperação

Ao planejar sua estratégia de recuperação de desastres na AWS, considere seu objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO), conforme ilustrado na imagem abaixo:

• O Objetivo de tempo de recuperação (RTO) é o maior atraso que a empresa pode tolerar entre o evento de desastre e a continuação dos serviços.
• O Objetivo de ponto de recuperação (RPO) é o tempo mais longo que pode passar desde a última janela de backup. Por exemplo, se a organização faz backup de arquivos uma vez por hora, no máximo a organização pode perder uma hora de dados, o RPO é de 60 minutos.

Créditos da Imagem: Amazon

O gráfico a seguir ilustra como as quatro estratégias de recuperação de desastres se relacionam com RTO e RPO, adicionando a dimensão do custo de implementação de cada solução. A linha vermelha vertical mostra o RTO definido por uma organização—as estratégias de DR à direita desta linha não são aceitáveis.

• Backup e restauração oferecem o menor custo, mas o RTO mais longo
• Pilot Light fornece um custo médio e RTO
• Warm standby fornece um alto custo e baixo RTO
• Estrutura Ativo/ativo em vários sites fornece o custo mais alto e um RTO quase zero

Créditos da Imagem: Amazon

Vamos detalhar um pouco mais cada tipo de estratégia mencionados acima:

Estratégias de DR na AWS: arquitetura de referência

Vamos nos aprofundar em cada uma das estratégias de recuperação de desastres que analisamos acima e ver como a Amazon recomenda a implantação de cada uma. Essas são arquiteturas de referência que você pode usar como um blueprint ou personalizar de acordo com suas cargas de trabalho específicas e requisitos de DR.

Backup and Restore

Créditos da Imagem: Amazon

A imagem acima ilustra como é possível fazer backup de vários tipos de recursos de dados da AWS. Aqui estão vários princípios a serem lembrados ao usar a estratégia de DR de backup e restauração na AWS:

• Você pode criar backups na mesma região da origem.
• Para garantir a disponibilidade durante desastres, os backups também são replicados para outras regiões.
• Durante o failover da região, você pode recuperar dados do backup e restaurar sua infraestrutura da região de recuperação.
• Você pode aproveitar os serviços de infraestrutura como código (IaC), como o AWS Cloud Development Kit (AWS CDK) e o AWS CloudFormation para implantar consistentemente sua infraestrutura em várias regiões.
• Para reduzir o RTO dessa estratégia, você pode implementar técnicas que melhorem a detecção e a recuperação. Por exemplo, você pode projetar e executar a automação sem servidor usando o Amazon EventBridge.

Pilot Light

Créditos da Imagem: Amazon

• Aqui estão alguns princípios a serem lembrados ao usar a estratégia Pilot Light na AWS: serviços inativos — as solicitações são processadas e os componentes de infraestrutura inativa são implantados somente quando acionados. Por exemplo, na figura 2, o Amazon EC2 Auto Scaling e o Elastic Load Balancing servem como componentes básicos de infraestrutura, enquanto elementos funcionais, como recursos de computação, são mantidos “desligados”.
• Desligando recursos — você pode garantir que suas instâncias do EC2 sejam desligadas não implantando nenhuma. Na imagem acima, não há instâncias implantadas.
• Ativando recursos — você pode ativar instâncias implantando uma Amazon Machine Image (AMI) usada anteriormente que já foi copiada para outras regiões. A AMI cria instâncias do EC2 que contêm o sistema operacional (SO) e os pacotes necessários.
• Dados ativos — bancos de dados e armazenamentos de dados são mantidos continuamente atualizados ou quase atualizados com dados localizados na região ativa. Os dados ao vivo são mantidos prontos para quando for necessário atender às operações de leitura.
• Replicações e backup — criar réplicas e colocá-las em clusters somente leitura não é suficiente para garantir a disponibilidade durante um evento de perda de dados. Você também precisa criar backups que permitam retroceder até o último estado bom. A Figura 2 ilustra como o Amazon Aurora replica seus dados para um cluster somente leitura localizado em uma região de recuperação local. Os instantâneos de cluster são uma alternativa para criar backups.

Warm Standby

Créditos da Imagem: Amazon

A estratégia de Warm Standby mantém os dados ativos (assim como a estratégia de DR de Pilot Light), ao mesmo tempo em que mantém backups periódicos. Aqui estão vários princípios a serem lembrados ao usar a estratégia de espera quente na AWS:

• Uma Warm Standby não pode atender ao tráfego de nível de produção — ela mantém o mínimo necessário para lidar com solicitações em uma capacidade reduzida. Na imagem acima, você pode ver como apenas uma instância do EC2 é implantada por cada camada.
• É relativamente fácil testar a Warm Standby — os endpoints passivos não precisam de trabalho adicional antes de lidar com transações de teste sintéticas antes da implantação.
• Você deve dimensionar a infraestrutura antes do failover — para atender às necessidades de produção antes do failover.
• A principal diferença entre a estratégia de Pilot Light e Warm Standby o código e a infraestrutura em execução.

Multi-Site Ativo/Ativo

Créditos da Imagem: Amazon

A estratégia ativa/ativa de vários sites mantém duas ou mais regiões ativas disponíveis para aceitar solicitações. Aqui estão vários princípios a serem lembrados ao usar a estratégia ativa/ativa de vários sites na AWS:

• Durante o failover — as solicitações são redirecionadas de regiões incapazes de lidar com as solicitações.
• Solicitações de leitura — são atendidas usando dados replicados nas regiões. As réplicas são mantidas ativas para garantir a disponibilidade durante o failover.
• Solicitações de gravação — há várias opções para garantir que as solicitações de gravação sejam atendidas. Por exemplo, você pode redirecionar gravações para uma região específica ou gravar em uma região local.
• Backup de dados — deve ser criado para garantir que você possa restaurar versões anteriores durante eventos de perda de dados. A imagem acima mostra como as tabelas globais são usadas para a camada de banco de dados no Amazon DynamoDB. Isso garante que as tabelas possam ser gravadas em qualquer local e os dados possam ser propagados rapidamente para qualquer outra região.

Recuperação de desastres na AWS — uma ou várias regiões

Existem três opções principais de redundância para uma operação de recuperação de desastres na AWS, cada uma com resiliência progressivamente maior:

Multiplas AZs (Availability Zones) na mesma região

Protege contra um desastre que interrompe um data center da Amazon. Ao replicar em várias AZs na mesma região, suas cargas de trabalho são resilientes a falhas de um data center inteiro devido a um erro, ataque mal-intencionado ou desastre natural. Cada AZ é isolada de falhas nas outras AZs da mesma região.

Se você tiver um requisito regulatório para armazenar dados em uma região geográfica específica (residência de dados), poderá usar a opção de redundância multi-AZ, garantindo que todas as três AZs estejam dentro da região obrigatória.

Multiplas AZs com Backup em outra Região

Uma opção mais resiliente é fazer backup de dados, configurações e definições de infraestrutura para outra região da Amazônia. Isso é significativamente mais simples e barato do que a implantação multirregional, discutida abaixo. Você pode optar por armazenar dados no armazenamento Amazon S3 Standard para recuperação rápida ou, se a recuperação puder esperar entre minutos e horas, considere o Amazon S3 Glacier ou o Glacier Deep Archive para economizar custos.

Multiplas Regiões AWS

A opção mais resiliente é implantar cargas de trabalho em várias regiões da AWS, o que protege contra o risco de falha em vários data centers, fisicamente distantes uns dos outros, ao mesmo tempo. Em caso de falha de uma região amazônica inteira, suas cargas de trabalho ainda estarão sendo executadas com segurança em outra região amazônica.