fbpx
As 4 Principais Estratégias de Disaster Recovery (DR)
Voiced by Amazon Polly

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.

Arquitetura de Referência para Backup & Restore

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.

Arquitetura de Referência para Pilot Light

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.

Arquitetura de Referência de Warm Standby

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.

Arquitetura de Referência para Multi-site Active/Active

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.

Últimos posts por Pedro Pisa (exibir todos)
Entre em Contato

Para aprofundar em assuntos sobre Disaster Recovery, entre em contato com nossos especialistas.