REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação
Defina uma estratégia de recuperação de desastres (DR) que cumpra os objetivos de recuperação da workload. Escolha uma estratégia como backup e restauração, standby (ativo/passivo) ou ativo/ativo.
Resultado desejado: há uma estratégia de DR definida e implementada para cada workload, permitindo que ela atinja os objetivos de DR. As estratégias de DR entre workloads fazem uso de padrões reutilizáveis (como as estratégias descritas anteriormente).
Antipadrões comuns:
-
Implementar procedimentos de recuperação inconsistentes para workloads com objetivos de DR semelhantes.
-
Deixar que a estratégia de DR seja implementada ad hoc quando ocorrer um desastre.
-
Não ter um plano para a recuperação de desastres.
-
Depender das operações do ambiente de gerenciamento durante a recuperação.
Benefícios do estabelecimento desta prática recomendada:
-
O uso de estratégias de recuperação definidas permite que você adote ferramentas comuns e procedimentos de teste.
-
Usar estratégias de recuperação definidas melhora o compartilhamento de conhecimento entre as equipes e a implementação da DR nas workloads que possuem.
Nível de exposição a riscos quando esta prática recomendada não é estabelecida: alto. Sem uma estratégia de DR planejada, implementada e testada, é improvável que você cumpra os objetivos de recuperação em caso de desastre.
Orientação de implementação
Uma estratégia de DR depende da capacidade de manter a workload em um site de recuperação se o local primário não puder executar a workload. Os objetivos de recuperação mais comuns são o RTO e o RPO, conforme discutido em REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados.
Uma estratégia de DR em várias zonas de disponibilidade (AZs) em uma única Região da AWS pode fornecer mitigação contra eventos de desastre, como incêndios, inundações e grandes interrupções de energia. Se for um requisito implementar proteção contra um evento improvável que impeça a execução da workload em determinada Região da AWS, você poderá optar por uma estratégia de DR que use várias regiões.
Ao arquitetar uma estratégia de DR em várias regiões, você deve escolher uma das estratégias a seguir. Elas estão listadas em ordem crescente de custo e complexidade e em ordem decrescente de RTO e RPO. Região de recuperação refere-se a uma Região da AWS diferente da primária usada para a workload.
Figura 17: Estratégias de recuperação de desastres (DR)
-
Backup e restauração (RPO em horas, RTO em 24 horas ou menos): faça backup de seus dados e aplicações na região de recuperação. O uso de backups automatizados ou contínuos permitirá a recuperação a um ponto anterior no tempo, podendo reduzir o RPO para até cinco minutos em alguns casos. Em caso de desastre, você implantará a infraestrutura (usando a infraestrutura como código para reduzir o RTO), implantará o código e restaurará os dados salvos para se recuperar de um desastre na região de recuperação.
-
Luz piloto (RPO em minutos, RTO em dezenas de minutos): provisione uma cópia da infraestrutura de workload principal na região de recuperação. Replique seus dados na região de recuperação e crie backups deles lá. Os recursos necessários para permitir a replicação e o backup, como bancos de dados e armazenamento de objetos, estão sempre ativos. Outros elementos, como servidores de aplicações ou computação com tecnologia sem servidor, não são implantados. Porém, podem ser criados com a configuração e o código da aplicação necessários.
-
Standby passivo (RPO em segundos, RTO em minutos): mantenha uma versão reduzida, mas totalmente funcional, da workload sempre em execução na região de recuperação. Os sistemas críticos para os negócios são totalmente duplicados e estão sempre ativados, mas com uma frota reduzida. Os dados são replicados e vivem na região de recuperação. Quando chega o momento da recuperação, o sistema é dimensionado rapidamente para processar a carga de produção. Quanto mais a escala do standby passivo for aumentada verticalmente, menor será a dependência do RTO e do ambiente de gerenciamento. Quando totalmente dimensionado, isso é conhecido como standby a quente.
-
Ativo/ativo de várias regiões (multissite) (RPO próximo a zero, RTO potencialmente zero): a workload é implantada em várias Regiões da AWS e processa ativamente o tráfego delas. Essa estratégia exige que você sincronize os dados entre regiões. Deve-se evitar ou lidar com possíveis conflitos causados por gravações no mesmo registro em duas réplicas regionais diferentes, o que pode ser complexo. A replicação de dados é útil para a sincronização de dados e protegerá você contra alguns tipos de desastre, mas não contra corrupção ou destruição de dados, a menos que sua solução também inclua opções para recuperação a um ponto anterior no tempo.
nota
Às vezes, a diferença entre luz-piloto e standby passivo pode ser difícil de entender. Ambos incluem um ambiente na região de recuperação com cópias dos ativos da região primária. A diferença é que a luz-piloto não pode processar solicitações sem primeiro realizar uma ação adicional, enquanto o standby passivo pode processar o tráfego (em níveis de capacidade reduzidos) imediatamente. A luz piloto exigirá que você ative os servidores, possivelmente implante infraestrutura adicional (não essencial) e aumente a escala verticalmente. Já o standby passivo exige apenas que você aumente a escala verticalmente (tudo já está implantado e em execução). Escolha entre elas com base nas suas necessidades de RTO e RPO.
Quando o custo é uma preocupação e você deseja alcançar objetivos de RPO e RTO semelhantes, conforme definido na estratégia de standby passivo, é possível considerar soluções nativas da nuvem, como AWS Elastic Disaster Recovery, que adota a abordagem de luz piloto e oferece metas de RPO e RTO aprimoradas.
Etapas da implementação
-
Determine uma estratégia de DR que satisfaça os requisitos de recuperação para essa workload.
Escolher uma estratégia de DR é uma troca entre reduzir o tempo de inatividade e a perda de dados (RTO e RPO) e o custo e a complexidade da sua implementação. Você deve evitar implementar uma estratégia mais rigorosa do que necessário, pois isso resulta em custos desnecessários.
Por exemplo, no diagrama a seguir, a empresa determinou o RTO máximo permitido e o orçamento limite da estratégia de restauração de serviço. Considerando os objetivos empresariais, as estratégias de DR luz-piloto e standby passivo satisfarão tanto o RTO quanto os critérios de custo.
Figura 18: Escolha de uma estratégia de DR com base no RTO e no custo
Para saber mais, consulte Business Continuity Plan (BCP) (Plano de continuidade de negócios (BCP).
-
Revise os padrões de como a estratégia de DR selecionada pode ser implementada.
Essa etapa é para compreender como implementar a estratégia selecionada. As estratégias são explicadas usando as Regiões da AWS como locais primários e de recuperação. No entanto, também é possível optar por usar as zonas de disponibilidade em uma única região como sua estratégia de DR, que faz uso de elementos de várias dessas estratégias.
Nas etapas a seguir, é possível aplicar a estratégia para sua workload específica.
Backup e restauração
Backup e restauração é a estratégia menos complexa de implementar. Porém, exigirá mais tempo e esforço para restaurar a workload, levando a RTO e RPO mais altos. É uma boa prática sempre fazer backups dos dados e copiá-los para outro local (como outra Região da AWS).
Figura 19: Arquitetura de backup e restauração
Para obter mais detalhes sobre essa estratégia, consulte Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery
Luz piloto
Com a abordagem de luz-piloto, você replica os dados da região primária para a região de recuperação. Os principais recursos usados para a infraestrutura da workload são implantados na região de recuperação. No entanto, recursos adicionais e as dependências ainda são necessários para tornar a pilha funcional. Por exemplo, na Figura 20, nenhuma instância de computação é implantada.
Figura 20: Arquitetura de luz-piloto
Para obter mais detalhes sobre essa estratégia, consulte Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby
Modo de espera passivo
A abordagem de standby passivo envolve garantir que haja uma cópia com escala reduzida verticalmente, mas totalmente funcional, do seu ambiente de produção em outra região. Essa abordagem estende o conceito de luz-piloto e diminui o tempo de recuperação, já que a workload está sempre ativa em outra região. Se a região de recuperação estiver implantada com sua capacidade total, isso é conhecido como standby a quente.
Figura 21: Arquitetura de standby passivo
O uso de standby passivo ou luz-piloto requer que a escala dos recursos seja aumentada verticalmente na região de recuperação. Para verificar se a capacidade está disponível quando necessário, considere o uso de reservas de capacidade para instâncias do EC2. Se você usar o AWS Lambda, a simultaneidade provisionada poderá fornecer ambientes de execução para que eles sejam preparados para responder imediatamente às invocações da função.
Para obter mais detalhes sobre essa estratégia, consulte Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby
Multissite ativo/ativo
É possível executar a workload simultaneamente em várias regiões como parte de uma estratégia de multissite ativo/ativo. O multissite ativo-ativo atende ao tráfego de todas as regiões onde está implantado. Os clientes podem selecionar essa estratégia por outros motivos, além da DR. Ela pode ser usada para aumentar a disponibilidade ou ao implantar uma workload para um público global (a fim de aproximar o endpoint dos usuários e/ou implantar pilhas localizadas para o público nessa região). Como uma estratégia de DR, se a workload não for compatível com uma das Regiões da AWS onde está implantada, essa região será evacuada e as regiões restantes serão usadas para manter a disponibilidade. O multissite ativo-ativo é a estratégia de DR mais complexa operacionalmente e deve ser selecionada apenas quando os requisitos empresariais exigirem.
Figura 22: Arquitetura de multissite ativo-ativo
Para obter mais detalhes sobre essa estratégia, consulte Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active
AWS Elastic Disaster Recovery
Se você estiver considerando a estratégia de luz-piloto ou de standby passivo para a recuperação de desastres, o AWS Elastic Disaster Recovery poderia fornecer uma abordagem alternativa com benefícios melhorados. O Elastic Disaster Recovery pode oferecer uma meta de RPO e RTO semelhante à do standby passivo, mas mantém a abordagem de baixo custo da luz-piloto. O Elastic Disaster Recovery replica os dados da região primária para a região de recuperação, usando a proteção contínua de dados para alcançar um RPO medido em segundos e um RTO que pode ser medido em minutos. Somente os recursos necessários para replicar os dados são implantados na região de recuperação, o que mantém os custos baixos, semelhante à estratégia de luz-piloto. Ao usar o Elastic Disaster Recovery, o serviço coordena e orquestra a recuperação de recursos de computação quando iniciado como parte de um failover ou de uma simulação.
Figura 23: Arquitetura do AWS Elastic Disaster Recovery
Práticas adicionais para proteção de dados
Com todas as estratégias, você também deve atenuar um desastre de dados. A replicação contínua de dados protege você contra alguns tipos de desastre, mas não contra corrupção ou destruição de dados, a menos que sua solução também inclua o versionamento de dados armazenados ou opções para recuperação a um ponto anterior no tempo. Você também deve fazer backup dos dados replicados no local de recuperação para criar backups pontuais além das réplicas.
O uso de várias zonas de disponibilidade (AZs) em uma única Região da AWS
Ao utilizar várias AZs em uma única região, a implementação de DR usa vários elementos das estratégias acima. Primeiro, você deve criar uma arquitetura de alta disponibilidade (HA), usando várias AZs, conforme mostrado na Figura 23. Essa arquitetura usa uma abordagem multissite ativo/ativo, já que as instâncias do Amazon EC2 e o Elastic Load Balancer tem recursos implantados em várias AZs, processando solicitações ativamente. A arquitetura também demonstra o standby a quente, no qual, caso a instância primária do Amazon RDS falhe (ou a própria AZ falhe), a instância de standby será promovida a primária.
Figura 24: Arquitetura Multi-AZ
Além da arquitetura de alta disponibilidade, você precisa adicionar backups de todos os dados necessários para executar a workload. Isso é especialmente importante para dados restritos a uma única zona, como volumes do Amazon EBS ou clusters do Amazon Redshift. Se uma AZ falhar, você precisará restaurar esses dados para outra AZ. Sempre que possível, você também deve copiar backups de dados para outra Região da AWS, como uma camada adicional de proteção.
Uma abordagem alternativa menos comum para uma única região, a DR Multi-AZ está ilustrada nesta publicação de blog, Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack
nota
Algumas workloads têm requisitos regulamentares de residência de dados. Se isso se aplicar à sua workload em uma localidade que atualmente tem apenas uma Região da AWS, a multirregião não atenderá às suas necessidades empresariais. As estratégias Multi-AZ fornecem boa proteção contra a maioria dos desastres.
-
Avalie os recursos da workload e qual será sua configuração na região de recuperação antes do failover (durante a operação normal).
Para recursos de infraestrutura e da AWS, use a infraestrutura como código, como o AWS CloudFormation
Todas as estratégias de DR exigem que seja feito backup das fontes de dados na Região da AWS e, então, esses backups são copiados para a região de recuperação. O AWS Backup
Para saber mais sobre como os serviços da AWS operam entre regiões, consulte essa série de blog em Creating a Multi-Region Application with AWS Services
-
Determine e implemente como deixar sua região de recuperação pronta para failover quando necessário (durante um evento de desastre).
Para multissite ativo-ativo, failover significa evacuar uma região e confiar nas regiões ativas restantes. No geral, essas regiões estão prontas para aceitar tráfego. Para as estratégias de luz-piloto e standby passivo, as ações de recuperação precisarão implantar os recursos ausentes, como as instâncias do EC2 na Figura 20, além de quaisquer outros recursos ausentes.
Para todas as estratégias acima, pode ser necessário promover instâncias somente leitura de bancos de dados para se tornar a instância primária de leitura/gravação.
Para backup e restauração, a restauração de dados do backup cria recursos para esses dados, como volumes do EBS, instâncias de banco de dados do RDS e tabelas do DynamoDB. Você também precisa restaurar a infraestrutura e implantar o código. É possível usar o AWS Backup para restaurar dados na região de recuperação. Perceber REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes para obter mais detalhes. A reconstrução da infraestrutura inclui a criação de recursos como instâncias do EC2, além da Amazon Virtual Private Cloud (Amazon VPC)
-
Determine e implemente como redirecionar o tráfego para failover quando necessário (durante um evento de desastre).
Essa operação de failover pode ser iniciada de forma manual ou automática. O failover iniciado automaticamente com base em verificações de integridade ou alarmes deve ser usado com cautela, pois um failover desnecessário (alarme falso) resulta em custos como indisponibilidade e perda de dados. Portanto, geralmente é usado o failover iniciado manualmente. Nesse caso, você ainda deve automatizar as etapas para failover, para que a inicialização manual seja como apertar um botão.
Há várias opções de gerenciamento de tráfego a serem consideradas ao usar os serviços da Regiões da AWS. Uma opção é usar o Amazon Route 53
Para saber mais sobre essa e outras opções, consulte esta seção do whitepaper de recuperação de desastres.
-
Projete um plano de como será feito failback da workload.
Failback é quando você retorna a operação de workload para a região primária, após o término de um evento de desastre. O provisionamento de infraestrutura e código para a região primária geralmente segue as mesmas etapas que foram usadas inicialmente, contando com a infraestrutura como código e pipelines de implantação de código. O desafio com o failback é restaurar os armazenamentos de dados e garantir sua consistência com a região de recuperação em operação.
No estado de failover, os bancos de dados na região de recuperação estão ativos e têm dados atualizados. O objetivo é ressincronizar da região de recuperação para a região primária, garantindo que ela esteja atualizada.
Alguns serviços da AWS farão isso automaticamente. Se você usar tabelas globais do Amazon DynamoDB
Em casos nos quais isso não seja automático, você precisará restabelecer o banco de dados na região primária como uma réplica do banco de dados na região de recuperação. Em muitos casos, isso envolverá a exclusão do banco de dados primário antigo e a criação de outras réplicas. Por exemplo, para obter instruções de como fazer isso com o banco de dados global do Amazon Aurora presumindo um failover não planejado, consulte este laboratório: Fail Back a Global Database
Após um failover, se você puder continuar a execução na região de recuperação, considere torná-la a nova região primária. Você ainda seguiria todas as etapas acima para transformar a antiga região primária em uma região de recuperação. Algumas organizações fazem uma alternância programada, trocando as regiões primárias e de recuperação periodicamente (por exemplo, a cada três meses).
Todas as etapas necessárias para failover e failback devem ser mantidas em um manual disponível para todos os membros da equipe e que seja revisado periodicamente.
Ao usar o Elastic Disaster Recovery, o serviço auxiliará na orquestração e automatização do processo de failback. Para obter mais detalhes, consulte Performing a failback (Como executar failback).
Nível de esforço do plano de implementação: alto
Recursos
Práticas recomendadas relacionadas:
Documentos relacionados:
-
Blog de arquitetura da AWS: série de recuperação de desastres
-
Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)
-
Crie uma solução de backend ativo-ativo multirregional sem servidor em uma hora
-
Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres
-
AWS Marketplace: produtos que podem ser usados para recuperação de desastres
Vídeos relacionados:
Exemplos relacionados:
-
Well-Architected Lab - Disaster Recovery
- Series of workshops illustrating DR strategies (Laboratório do Well-Architected – Recuperação de desastres: série de workshops ilustrando estratégias de DR)
