 |
Quando falamos de Recuperação de Desastres, ou Disaster Recovery (DR), tanto na nuvem quando on-premises, temos que entender os requisitos de negócios para endereçar dois pontos principais: quanto tempo estamos dispostos a ficar fora do ar e qual o custo disso, e quantos dados estamos dispostos a recriar ou perder?
Recovery Time Objective (RTO)
Para endereçar o tempo que uma aplicação fica fora do ar, é necessário definir o RTO. O RTO representa o tempo máximo aceitável desde o último ponto de recuperação de dados. Esse objetivo determina o que é considerado uma perda de dados aceitável entre o último ponto de recuperação e a interrupção do serviço e é definido pela organização.
Recovery Point Objective (RPO)
Já quando falamos dos dados perdidos em uma indisponibilidade, é necessário definir o RPO. O RPO representa o atraso máximo aceitável entre a interrupção do serviço e sua restauração. Esse objetivo determina o que é considerado uma janela de tempo aceitável quando o serviço não está disponível e é definido pela organização.
Ao definir o RTO e RPO, é sempre importante levar em consideração o custo da solução implementada. Caso o custo da recuperação seja maior do que o custo da falha ou perda, a opção de recuperação não deve ser implementado, a menos que haja um driver secundário, como requisitos regulamentares.
Estratégias de DR
Existem 4 principais estratégias de recuperação de desastres. São elas: Backup & Restore, Pilot Light, Warm Standby e Multi-site Active/Active. Cada uma possui seus prós e contras e caso de uso que são mais recomendados. De maneira geral, os principais aspectos são o RPO e RTO e o custo de cada abordagem.
Backup & Restore
A estratégia de Backup & Restore consiste em realizar o backup dos dados em uma outra estrutura (no caso da AWS, em outra região), e restaurar quando necessário. Deve ser realizado o backup tanto dos dados, quanto do código e configurações. Essa estratégias é a mais econômica, uma vez que não mantém recursos ligados, mas é a que mais demora para restaurar, pois, em caso de um desastre, é necessário subir toda a infraestrutura, e o RPO está diretamente relacionado à frequência do backup. Se o backup é realizado diariamente, estamos falando de um RPO de 24 horas.
Pilot Light
Já a estratégia de Pilot Light envolve replicar dados de uma região para outra e provisionar uma cópia da infraestrutura principal. Osecursos necessários para apoiar a replicação de dados e backup, como Banco de Dados, devem estar sempre ativos. Já outros elementos, como servidores de aplicação, quando necessário, são iniciados com o código do aplicativo e configurações, mas ficam desligados e são usados apenas durante o teste ou quando o failover é invocado. Essa estratégia reduz de maneira significativa o RPO, uma vez que a replicação dos dados é feita de maneira constante, e reduz um pouco o RTO, uma vez que não é necessário restaurar o backup antes de iniciar os serviços.
Warm Standby
A estratégia de Warm Standby reduz muito o RTO, uma vez que é mantida uma cópia reduzida, mas totalmente funcional, de seu ambiente de produção em outra região. Essa abordagem estende o conceito do Pilot Light e diminui o tempo de recuperação porque seu workload está sempre ativo em outra região. A diferença entre os métodos Pilot Light e Warm Standby, é que o primeiro não pode processar solicitações sem antes iniciar recursos, enquanto o warm standby pode lidar com o tráfego em níveis de capacidade reduzida imediatamente, precisando apenas um redimensionamento para poder atender uma capacidade maior de requisições.
Multi-site Active/Active
Por fim, a estratégia que reduz o RTO e RPO a temos tendendo a zero é a Multi-site Active/Active. Nessa abordagem, o workload é executado simultaneamente em várias regiões, nos formatos multi-site ativo/ativo ou hot standby ativo/passivo.
No formato multi-site ativo/ativo, é realizado o roteamento do tráfego para todas as regiões de maneira simultânea. Enquanto no formato hot standby ativo/passivo apenas uma região atende ao tráfego, e as outras regiões são usadas apenas para recuperação de desastres. Um dos principais cases de referência dessa estratégias de DR é o da Netflix.
Portanto, ao definir a melhor estratégia de Disaster Recovery para a sua empresa, é necessário entender os requisitos de negócios para definir os valores de RPO e RTO adequados para cada uma das aplicações. Com esses valores e, baseado na arquitetura do Workload, será possível definir a melhor estratégia de DR e projetar o processo de sincronização e failover para cada Workload.
- Desafios da Migração de Bancos de Dados para a Nuvem - 20 de agosto de 2022
- As 4 Principais Estratégias de Disaster Recovery (DR) - 28 de janeiro de 2022
- Como funciona o Well Architected Review - 18 de maio de 2021
Entre em Contato
Para aprofundar em assuntos sobre Disaster Recovery, entre em contato com nossos especialistas.