Recuperação de desastres AWS: 5 melhores práticas

Recuperação de desastres AWS: 5 melhores práticas

Resolva desastres em um deployment da AWS implementando uma estratégia de recuperação de desastres. Saiba como escolher os métodos de recuperação corretos e evitar mais problemas.

Se a AWS fizer parte de sua estratégia de TI, a recuperação de desastres da AWS deverá ser incluída em sua estratégia geral de DR.

Ter um plano de DR adaptado à AWS garante que você possa minimizar a perda de dados e reduzir o tempo de inatividade durante um incidente envolvendo os recursos do provedor de nuvem.

Isso varia de um incidente causado por uma falha do data center da AWS a erros cometidos pelo administrador, como exclusão acidental de dados ou uma configuração incorreta que causa uma falha.

O planejamento de recuperação de desastres da AWS leva a uma melhor experiência para seus usuários e maior confiabilidade e resiliência para os negócios.

Alguns aspectos do planejamento de DR para AWS não são tão diferentes de DR em nenhum contexto. Outros são específicos da AWS e exigem conhecimento de suas ferramentas ou serviços específicos. Para maximizar a confiabilidade e minimizar o tempo de recuperação quando ocorre um desastre em um ambiente da AWS, siga estas cinco etapas principais.

Recuperação de desastres AWS etapa 1: escolha o método de recuperação correto

Uma equipe de TI tem vários métodos para recuperar cargas de trabalho com falha na AWS, que são detalhados na documentação da AWS. Esses incluem:

•Backup e restauração. Os administradores da nuvem AWS fazem backups regulares e restauram dados desses backups após uma falha. Essa abordagem custa menos porque não exige que você hospede um ambiente de backup ao vivo. Mas também causa os tempos de recuperação mais longos porque você cria um ambiente de recuperação do zero.

•Pilot Light. Essa abordagem usa um ambiente de backup mínimo, que é o que significa a luz piloto, em execução ao lado do ambiente de produção. A recuperação é um pouco mais rápida do que seria se você começasse do zero, mas o ambiente de luz piloto incorre em custos contínuos.

•Warm standby. Essa configuração requer um ambiente de backup em grande escala onde a equipe de TI possa restaurar serviços em caso de falha. Mas esse método não está totalmente pronto para produção. Os custos de hospedagem são mais altos para um ambiente de backup maior, mas a recuperação é mais rápida.

•Multisite ou active-active. A DR ativa-ativa depende de um ambiente de backup completo junto com o ambiente de produção. Os custos de hospedagem são mais altos nesse caso, mas o tempo de recuperação é mínimo porque as cargas de trabalho fazem failover para o ambiente de backup quase instantaneamente.

O método de recuperação correto para uma implantação na nuvem da AWS depende do orçamento e das necessidades de recuperação. Invista em uma estratégia de espera quente ou multisite/ativo-ativo se você tiver um orçamento generoso de recuperação de desastres da AWS. As decisões de negócios sobre as cargas de trabalho da AWS ditam o objetivo do ponto de recuperação (RPO) e o objetivo do tempo de recuperação (RTO).

Você pode empregar vários métodos de recuperação da AWS ao mesmo tempo. Uma abordagem de backup e restauração ou luz piloto funciona para cargas de trabalho não críticas que podem tolerar algum tempo de inatividade.

Simultaneamente, você pode criar configurações de espera ativa ou ativa-ativa para outras cargas de trabalho que devem estar em funcionamento o mais rápido possível. Use todas as opções apropriadas para encontrar um equilíbrio entre o custo e o desempenho do planejamento de recuperação.

Recuperação de desastres AWS etapa 2: calcular RPO e RTO

Dois cálculos principais devem orientar o método de recuperação usado:

RPO. A quantidade de perda de dados que você pode tolerar após uma interrupção sem sofrer interrupções críticas nos negócios. O RPO geralmente é medido em termos de tempo. Por exemplo, seu RPO pode valer vinte e quatro horas de dados de negócios.

RTO. A quantidade de tempo que os sistemas críticos podem ficar inativos antes de representarem um grande risco para os negócios.

Cada carga de trabalho de negócios ou individual tem diferentes requisitos de RPO e RTO. Para determinar as necessidades de recuperação, liste de quais cargas de trabalho a empresa depende e, em seguida, categorize-as de acordo com a importância delas para a empresa. Tente rótulos como essencial, muito importante, importante, não crítico e insignificante.

Em seguida, considere por quanto tempo a empresa poderá permanecer operacional se os dados ou aplicativos associados a cada carga de trabalho forem perdidos. Os resultados são o RPO e o RTO de destino das cargas de trabalho.

As cargas de trabalho da AWS com necessidades rápidas de RPO e RTO são mais bem atendidas por planos de recuperação de desastres que permitem a restauração rápida em caso de interrupção.

Recuperação de desastres AWS etapa 3 – fazer um plano de backup do EC2

A AWS recomenda duas abordagens para fazer backup de máquinas virtuais em execução no AWS EC2:

•EBS snapshots. Um snapshot de um volume Elastic Block Store (EBS) contém os dados dentro da instância do EC2.

•Backups de AMIs. As imagens de máquina da Amazon (AMIs) contêm todas as informações necessárias para reconstruir uma instância do EC2 com falha.

Em geral, o backup baseado em AMI facilita a recuperação mais rápida porque você não precisa reconstruir nenhuma configuração para iniciar uma instância de substituição do EC2. Tudo o que é necessário está contido na AMI.

O backup de AMI é menos flexível e um pouco mais arriscado em alguns aspectos. As AMIs geram instâncias idênticas às instâncias do EC2 nas quais se baseiam. Isso pode ser um problema se houver um problema em uma instância do EC2 que cause falha.

Nesse caso, a instância restaurada potencialmente atinge os mesmos problemas que a que substituiu. Você também pode ter problemas se a instância original ainda estiver em execução. A instância original e a instância de substituição podem tentar reivindicar os mesmos recursos exclusivos na AWS, porque suas configurações são idênticas.

Por outro lado, os volumes do EBS podem ser anexados a qualquer instância do EC2 de sua escolha. Você pode restaurar os dados de uma instância com falha, mas usar uma configuração diferente para a instância com backups do EBS.

Considere usar instantâneos do EBS e backups de AMI ao mesmo tempo. Dessa forma, você pode recuperar instâncias do EC2 usando qualquer abordagem que faça mais sentido em um determinado cenário. No entanto, optar por ambos os backups significa assumir custos de armazenamento e esforço operacional.

Marque os backups do EC2 para gerenciá-los com eficiência. Além disso, implemente um processo de gerenciamento de ciclo de vida que exclua backups desatualizados para economizar espaço e custos de armazenamento quando eles não forem mais necessários.

Recuperação de desastres AWS etapa 4: usar a automação de backup da AWS

Você pode gerenciar a recuperação de desastres da AWS manualmente, mas os melhores planos de DR da AWS usam a automação para garantir que os processos de recuperação sejam os mais rápidos e suaves possíveis.

Uma ferramenta importante para essa finalidade é o AWS Backup, uma abordagem centralizada baseada em políticas para gerenciar operações de backup e recuperação para diversos recursos da AWS.

A ferramenta não abrange todos os tipos de serviço da AWS, mas aborda os principais. Esses são serviços como instâncias do EC2 e a maioria dos bancos de dados da AWS. Ele pode fazer backup de recursos automaticamente e realizar restaurações automatizadas.

O Amazon Route 53 Application Recovery Controller é uma ferramenta complementar de backup e recuperação da AWS. Essa ferramenta é especialmente útil para cargas de trabalho com configurações de rede complexas.

Ele avalia automaticamente os planos de recuperação e failover. Use-o para certificar-se de que um ambiente de luz piloto, espera quente ou recuperação ativo-ativo seja o caminho certo para restaurar uma carga de trabalho com falha, de acordo com as expectativas de negócios.

As ferramentas de backup nativas da AWS funcionam apenas na AWS. Se você precisar fazer backup de outros ambientes além da AWS, considere soluções de automação de backup de terceiros.

No entanto, ferramentas de backup de terceiros que não armazenam dados na AWS apresentam uma falha. Se os dados de backup não estiverem armazenados na AWS, você precisará transferi-los pela Internet para recuperar as cargas de trabalho. Isso pode levar muito tempo – horas ou, possivelmente, dias – para grandes volumes de dados.

Em alguns casos, ferramentas de backup de terceiros permitem fazer backup de dados da AWS diretamente na AWS, o que acelerará a recuperação.

Recuperação de desastres AWS etapa 5: testar e gerenciar qualquer plano de recuperação da AWS

Teste seus planos de recuperação da AWS regularmente para garantir que funcionem conforme necessário.

A maneira mais direta de testar os planos de recuperação é uma simulação. Crie um cenário em que uma carga de trabalho crítica falhe e execute seu plano para recuperá-la com base nos backups disponíveis. Faça exercícios como esse pelo menos algumas vezes por ano. Faça isso com mais frequência para cargas de trabalho críticas.

Considere também executar verificações do sistema de arquivos nos dados de backup para procurar corrupções ou outros problemas que possam interromper a recuperação. Use ferramentas como o Route 53 Application Recovery Controller para avaliar a preparação da recuperação para cargas de trabalho com suporte.

Atualize os planos de recuperação ao longo do tempo. Reavalie o RTO e o RPO pelo menos uma ou duas vezes por ano e com mais frequência se as cargas de trabalho ou os requisitos de negócios mudarem com frequência. Se uma carga de trabalho se tornar mais crítica para as operações de negócios ao longo do tempo, por exemplo, pode ser necessário mudar de procedimentos de backup e restauração para uma configuração de espera a quente.

Um plano de recuperação de desastres da AWS pode envolver muito mais do que as etapas básicas descritas acima. Cargas de trabalho específicas, como as que envolvem Kubernetes, contêineres ou funções sem servidor, exigem planejamento extra para garantir a recuperação rápida dos recursos exclusivos em jogo.

Independentemente da carga de trabalho ou das tecnologias em uso, a estratégia de backup e recuperação deve começar com o básico. Defina as necessidades de RTO e RPO e desenvolva metodologias de recuperação e abordagens de backup do EC2 que se alinhem a essas necessidades.

Fique por dentro das tendências e inovações educacionais aqui no blog da ITExperts!

Originalmente publicado em: https://www.techtarget.com/searchcloudcomputing/tip/Stay-online-with-these-5-AWS-disaster-recovery-best-practices

Conheça ITExperts e nossas soluções em cloud para Educação.

Solução em infraestrutura educacional.