Opções de recuperação de desastres na nuvem
As estratégias de recuperação de desastres disponíveis para você na AWS podem ser amplamente categorizadas em quatro abordagens, que vão desde baixo custo e baixa complexidade para fazer backups a estratégias mais complexas que envolvem o uso de várias regiões ativas. É fundamental testar regularmente sua estratégia de recuperação de desastres para que tenha confiança em invocá-la caso seja necessário.
Figura 6: estratégias de recuperação de desastres
Para um evento de desastre que envolva interrupção ou perda de um único datacenter físico para uma workload bem projetada
Backup e restauração
Backup e restauração são uma abordagem adequada para atenuar a perda ou corrupção de dados. Essa abordagem também pode ser usada para mitigar um desastre regional por meio da replicação de dados para outras regiões da AWS ou para atenuar a falta de redundância para workloads implantadas em uma única zona de disponibilidade. Além dos dados, você deve reimplantar a infraestrutura, a configuração e o código da aplicação na região de recuperação. Para permitir que a infraestrutura seja reimplantada rapidamente sem erros, você deve sempre utilizar a infraestrutura como código (IaC) na implantação usando serviços como o AWS CloudFormation
Figura 7: arquitetura de backup e restauração
Serviços da AWS
Os dados da workload exigirão uma estratégia de backup que seja executada periodicamente ou seja contínua. A frequência com que você executa o backup determinará o ponto de recuperação alcançável (que deve estar alinhado para atender ao seu RPO). O backup também deve oferecer um meio para ser restaurado até o ponto em que foi realizado. O backup com recuperação em um ponto anterior no tempo é disponibilizado por meio dos seguintes serviços e recursos:
Para o Amazon Simple Storage Service (Amazon S3), você pode usar a replicação entre regiões (CRR) do Amazon S3
O AWS Backup
-
Volumes do Amazon Elastic Block Store (Amazon EBS)
-
Instâncias do Amazon EC2
-
Bancos de dados do Amazon Relational Database Service (Amazon RDS)
(incluindo bancos de dados do Amazon Aurora ) -
Tabelas do Amazon DynamoDB
-
Sistemas de arquivos do Amazon Elastic File System (Amazon EFS)
-
Volumes do AWS Storage Gateway
Com o AWS Backup, é possível fazer cópia de backups entre regiões; por exemplo, para uma região de recuperação de desastres.
Para ter outra estratégia de recuperação de desastres para seus dados do Amazon S3, habilite o versionamento de objetos do S3. O versionamento de objetos protege seus dados no S3 contra as consequências das ações de exclusão ou modificação, mantendo a versão original antes da ação. O versionamento de objetos pode ser um método útil para atenuar desastres provocados por erros humanos. Se você estiver usando a replicação do S3 para fazer backup de dados em sua região de DR, quando um objeto for excluído no bucket de origem, o Amazon S3 adicionará um marcador de exclusão somente no bucket de origem por padrão. Essa abordagem protege os dados na região de DR contra exclusões mal-intencionadas na região de origem.
Além dos dados, você também deve fazer backup da configuração e da infraestrutura necessárias para reimplantar sua workload e atender ao objetivo de tempo de recuperação (RTO). O AWS CloudFormation
Todos os dados armazenados na região de recuperação de desastres como backups devem ser restaurados no momento do failover. O AWS Backup oferece recurso de restauração, mas atualmente não permite restauração programada ou automática. Você pode implementar a restauração automática para a região de DR usando o AWS SDK para chamar APIs para o AWS Backup. Você pode definir essa configuração como um trabalho regularmente recorrente ou acionar a restauração sempre que um backup for concluído. A figura a seguir mostra um exemplo de restauração automática usando o Amazon Simple Notification Service (Amazon SNS)
Figura 8: restauração e teste de backups
nota
Sua estratégia de backup deve incluir o teste de seus backups. Consulte a seção Testes de recuperação de desastres para obter mais informações. Consulte AWS Well-Architected Lab: Testing Backup and Restore of Data
Luz piloto
Com a abordagem de luz piloto, você replica seus dados de uma região para outra e provisiona uma cópia de sua infraestrutura de workload principal. Os recursos necessários para auxiliar a replicação e o backup de dados, como bancos de dados e armazenamento de objetos, estão sempre ativos. Outros elementos, como servidores de aplicações, são carregados com o código e as configurações da aplicação, mas são desativados e usados apenas durante testes ou quando o failover de recuperação de desastres é invocado. Ao contrário da abordagem de backup e restauração, sua infraestrutura principal está constantemente disponível e você sempre tem a opção de provisionar rapidamente um ambiente de produção em grande escala ativando e aumentando a escala na horizontal dos servidores de aplicações.
Figura 9: arquitetura de luz piloto
A abordagem de luz piloto reduz o custo contínuo da recuperação de desastres ao minimizar os recursos ativos e simplifica a recuperação no momento de um desastre porque todos os principais requisitos de infraestrutura estão em ordem. Essa opção de recuperação exige que você altere sua abordagem de implantação. Você precisa fazer alterações na infraestrutura principal em cada região e implantar alterações de workload (configuração, código) simultaneamente em cada região. Para simplificar essa etapa, você pode automatizar suas implantações e usar a infraestrutura como código (IaC) para implantar infraestrutura em várias contas e regiões (implantação completa da infraestrutura na região principal e implantação de infraestrutura reduzida na escala vertical/desativada para regiões de DR). É recomendável usar uma conta diferente por região para fornecer o mais alto nível de isolamento de recursos e segurança (caso seus planos de recuperação de desastres também incluam credenciais comprometidas).
Com essa abordagem, você também precisa atenuar desastres de dados. A replicação contínua de dados protege você contra alguns tipos de desastre, mas pode não oferecer proteção contra corrupção ou destruição de dados, a menos que sua estratégia também inclua versionamento de dados armazenados ou opções para recuperação em um ponto anterior no tempo. Você pode fazer backup dos dados replicados na região do desastre para criar backups em um ponto anterior no tempo nessa mesma região.
Serviços da AWS
Além de usar os serviços da AWS abordados na seçãoBackup e restauração para criar backups em um ponto anterior no tempo, considere também os seguintes serviços para sua estratégia de luz piloto.
Com relação à luz piloto, a replicação contínua de dados para bancos de dados e armazenamentos de dados em tempo real na região de DR é a melhor abordagem para RPO baixo (quando usada além dos backups em um ponto anterior no tempo discutidos anteriormente). A AWS fornece replicação de dados contínua, entre regiões e assíncrona para dados por meio dos seguintes serviços e recursos:
Com a replicação contínua, as versões de seus dados ficam disponíveis quase imediatamente em sua região de DR. Os tempos reais de replicação podem ser monitorados usando recursos de serviço como o S3 Replication Time Control (S3 RTC) para objetos do S3 e recursos de gerenciamento do Amazon Aurora Global Database.
Ao fazer o failover para executar sua workload de leitura e gravação na região de recuperação de desastres, você deve promover uma réplica de leitura do RDS para que se torne a instância primária. Para instâncias de banco de dados diferentes do Aurora, o processo leva alguns minutos para ser concluído e a reinicialização faz parte do processo. Para replicação entre regiões (CRR) e failover com o RDS, o uso do Amazon Aurora Global Database oferece várias vantagens. O banco de dados global usa uma infraestrutura dedicada que mantém seus bancos de dados totalmente disponíveis para atender à sua aplicação e pode replicar para a região secundária com latência típica de menos de 1 segundo (e com uma latência bem menor que 100 milissegundos dentro de uma região da AWS). Com o Amazon Aurora Global Database, se sua região principal sofrer uma degradação de performance ou interrupção, você poderá promover uma das regiões secundárias para assumir responsabilidades de leitura/gravação em menos de 1 minuto, mesmo no caso de uma paralisação regional completa. A promoção pode ser automática e não há reinicialização.
Uma versão de sua infraestrutura de workload principal reduzida na escala vertical, com menos recursos ou recursos menores, deve ser implantada em sua região de DR. Usando o AWS CloudFormation, você pode definir sua infraestrutura e implantá-la de forma consistente nas contas e regiões da AWS. O AWS CloudFormation usa pseudoparâmetros predefinidos para identificar a conta da AWS e a região da AWS em que ela está implantada. Portanto, você pode implementar a lógica de condição em seus modelos do CloudFormation para implantar na região de recuperação de desastres somente a versão de sua infraestrutura reduzida na escala vertical. Para implantações de instâncias do EC2, uma imagem de máquina da Amazon (AMI) fornece informações como configuração de hardware e software instalado. Você pode implementar um pipeline do Image Builder que cria as AMIs necessárias e copiá-las para as regiões principal e de backup. Isso ajuda a garantir que essas AMIs ouro tenham tudo o que você precisa para reimplantar ou expandir sua workload em uma nova região em caso de desastre. As instâncias do Amazon EC2 são implantadas em uma configuração reduzida na escala vertical (menos instâncias do que em sua região principal). Você pode usar o hibernate para colocar instâncias do EC2 em um estado interrompido, no qual você não paga pelos custos do EC2, mas apenas pelo armazenamento usado. Para iniciar instâncias do EC2, você pode criar scripts usando a Command Line Interface (AWS CLI)
Para uma configuração ativo/standby, como a luz piloto, a princípio todo tráfego vai para a região principal e muda para a região de recuperação de desastres se a região principal não estiver mais disponível. Há duas opções de gerenciamento de tráfego a serem consideradas ao usar os serviços da AWS. A primeira é usar o Amazon Route 53
A segunda opção é usar o AWS Global Accelerator
CloudEndure Disaster Recovery
O CloudEndure Disaster Recovery
Figura 10: arquitetura do CloudEndure Disaster Recovery
Standby passivo
Na abordagem de standby passivo, é necessário garantir que haja uma cópia reduzida na escala vertical, mas totalmente funcional, de seu ambiente de produção em outra região. Essa abordagem amplia o conceito de luz piloto e diminui o tempo de recuperação porque sua workload fica sempre ativa em outra região. Ela também permite que você realize testes com maior facilidade ou implemente testes contínuos para aumentar a confiança em sua capacidade de se recuperar de um desastre.
Figura 11: arquitetura de standby passivo
Observação: a diferença entre luz piloto e standby passivo às vezes pode ser difícil de entender. Ambos incluem um ambiente em sua região de DR com cópias dos principais ativos da região. A diferença é que a luz piloto não pode processar solicitações sem que outras ações sejam executadas primeiro, enquanto o modo de standby passivo pode lidar imediatamente com o tráfego (em níveis de capacidade reduzidos). A abordagem de luz piloto requer que você “ligue” os servidores, possivelmente implante infraestrutura adicional (não central) e aumente a escala na vertical, enquanto o modo de standby passivo requer apenas que você aumente a escala na vertical (tudo já está implantado e em execução). Use suas necessidades de RTO e RPO para ajudar você a escolher uma dessas abordagens.
Serviços da AWS
Todos os serviços da AWS cobertos por backup e restauração e luz piloto também são usados em standby para backup de dados, replicação de dados, roteamento de tráfego ativo/standby e implantação de infraestrutura que inclui instâncias do EC2.
O AWS Auto Scaling
Ativo/ativo em vários locais
Você pode executar sua workload simultaneamente em várias regiões como parte de uma estratégia ativo/ativo em vários locais ou de standby a quente ativo/passivo. A estratégia ativo/ativo em vários locais atende ao tráfego de todas as regiões nas quais está implantada, enquanto o standby a quente atende ao tráfego apenas de uma região, e as outras regiões são usadas somente para recuperação de desastres. Com uma abordagem ativo/ativo em vários locais, os usuários podem acessar sua workload em qualquer uma das regiões em que ela está implantada. Essa é a abordagem mais complexa e cara para a recuperação de desastres, mas pode reduzir o tempo de recuperação para quase zero na maioria dos desastres com as opções de tecnologia e implementação corretas (no entanto, a corrupção de dados pode precisar contar com backups, o que geralmente resulta em um ponto de recuperação diferente de zero). O standby a quente usa uma configuração ativo/passivo em que os usuários são direcionados apenas para uma região e as regiões de DR não recebem tráfego. A maioria dos clientes acredita que, se eles forem criar um ambiente completo na segunda região, faz sentido usá-lo como ativo/ativo. Entretanto, se você não quiser usar as duas regiões para lidar com o tráfego do usuário, o modo de stanby a quente é uma abordagem mais econômica e menos complexa do ponto de vista operacional.
Figura 12: arquitetura ativa/ativa em vários locais (altere um caminho ativo para Inativo para standby a quente)
No cenário ativo/ativo em vários locais, visto que a workload está sendo executada em mais de uma região, não existe failover. Nesse caso, o teste de recuperação de desastres se concentraria em como a workload reage à perda de uma região: o tráfego é encaminhado para fora da região com falha? As outras regiões podem lidar com todo o tráfego? Também é necessário testar um desastre de dados. O backup e a recuperação ainda assim são necessários e devem ser testados regularmente. Também é necessário observar que os tempos de recuperação de um desastre de dados envolvendo corrupção, exclusão ou obscurecimento de dados sempre serão superiores a zero e o ponto de recuperação sempre estará em algum ponto antes da descoberta do desastre. Se a complexidade e custo adicionais de uma abordagem ativo/ativo em vários locais (ou standby a quente) forem necessários para manter tempos de recuperação quase nulos, outros esforços deverão ser feitos para preservar a segurança, bem como evitar erros humanos e atenuar desastres humanos.
Serviços da AWS
Todos os serviços da AWS cobertos por backup e restauração, luz piloto e standby passivo também são usados aqui para backup de dados em um ponto anterior no tempo, replicação de dados, roteamento de tráfego ativo/ativo e implantação e escalabilidade de infraestrutura que inclui instâncias do EC2.
Para os cenários ativo/passivo discutidos anteriormente (luz piloto e standby passivo), o Amazon Route 53 e o AWS Global Accelerator podem ser usados para encaminhar o tráfego de rede para a região ativa. Aqui, para a estratégia ativo/ativo, esses dois serviços também permitem a definição de políticas que determinam quais usuários irão para qual endpoint regional ativo. Com o AWS Global Accelerator, você define uma discagem de tráfego para controlar a porcentagem de tráfego que é direcionada para cada endpoint da aplicação. O Amazon Route 53 comporta essa abordagem de porcentagem e também várias outras políticas disponíveis, inclusive aquelas baseadas em geoproximidade e latência. O Global Accelerator utiliza automaticamente a extensa rede de servidores de borda da AWS para introduzir o tráfego na estrutura de rede da AWS o mais rápido possível, o que resulta em latências de solicitação mais baixas.
A replicação de dados com essa estratégia permite um RPO próximo de zero. Serviços da AWS como o Amazon Aurora Global Database usam uma infraestrutura dedicada que mantém seus bancos de dados totalmente disponíveis para atender à sua aplicação e podem realizar a replicação para uma região secundária com latência típica de menos de um segundo. Com as estratégias ativo/passivo, as gravações ocorrem somente na região primária. Na estratégia ativo/ativo, a diferença é delinear de que forma as gravações em cada região ativa serão tratadas. As leituras do usuário normalmente são projetadas para que sejam realizadas na região mais próxima a eles, o que é conhecido como leitura local. Nas gravações, você tem várias opções:
-
Na estratégia de gravação global, todas as gravações são encaminhadas para uma única região. Em caso de falha nessa região, outra região é promovida para aceitar gravações. O Aurora Global Datase é uma boa opção para gravação global porque comporta sincronização com réplicas de leitura entre regiões e você pode promover uma das regiões secundárias para assumir responsabilidades de leitura/gravação em menos de 1 minuto.
-
Na estratégia de gravação local, as gravações são encaminhadas para a região mais próxima (assim como as leituras). As tabelas globais do Amazon DynamoDB possibilitam essa estratégia, permitindo leituras e gravações de todas as regiões em que sua tabela global estiver implantada. As tabelas globais do Amazon DynamoDB usam a reconciliação último gravador ganha entre as atualizações simultâneas.
-
Na estratégia de gravação particionada, as gravações são atribuídas a uma região específica com base em uma chave de partição (como ID de usuário) para evitar conflitos de gravação. A replicação do Amazon S3 configurada bidirecionalmente
pode ser usada para esse caso e, no momento, comporta replicação entre duas regiões. Ao implementar essa abordagem, habilite a sincronização de modificação de réplica nos buckets A e B para replicar alterações de metadados de réplica como listas de controle de acesso a objetos (ACLs), etiquetas de objeto ou bloqueios de objeto nos objetos replicados. Você também pode configurar se deve ou não replicar marcadores de exclusão entre buckets em suas regiões ativas. Além da replicação, sua estratégia também deve incluir backups em um ponto anterior no tempo como proteção contra eventos de corrupção ou destruição de dados.
O AWS CloudFormation é uma ferramenta avançada para aplicar a infraestrutura implantada de forma consistente entre contas da AWS em várias regiões da AWS. O AWS CloudFormation StackSets amplia essa funcionalidade ao permitir que você crie, atualize ou exclua pilhas do CloudFormation em várias contas e regiões com uma única operação. Embora o AWS CloudFormation use YAML ou JSON para definir a infraestrutura como código, o AWS Cloud Development Kit (AWS CDK)