Video Screencast Help

VVR - Bunker Replication

Created: 27 Jun 2014 • Updated: 30 Jun 2014
MMartini's picture
+3 3 Votes
Login to vote

Dando continuidade a questão replicação disponíveis para o cliente, podemos recomendar o melhor dos dois mundos. Como tratado anteriormente, ao se deparar com as dúvidas de disponibilidade e ponto de recuperação em um ambiente de DR, existem duas maneiras de se trabalhar com essas variáveis, replicação síncrona e assíncrona.

E se fosse possível utilizarmos o melhor de ambos? A possibilidade de escolher entre a disponibilidade imediata do ambiente (síncrona), ou o sacrifício dessa disponibilidade para a recuperação do ambiente antes de um erro no sistema (assíncrona).

Esse conceito pode ser utilizado em uma replicação definida como Bunker. Nesse tipo de replicação, a grosso modo, as alterações feitas no ambiente são armazenadas em um terceiro servidor ou, dependendo da infraestrutura disponível, diretamente em um storage.

O processo utilizado para um ambiente bunker consiste em uma “bifurcação” no ambiente de DR. De maneira assíncrona, temos o site Principal e o site secundário. A replicação entre ambos ocorre em um intervalo pré-determinado, nesse caso, usaremos o período de 1 hora.

No caminho entre o site Primário e o Secundário existe uma bifurcação que estará sendo encaminhada para o Bunker. Esse caminho é definido como RPO zero, onde toda alteração é devidamente escrita no servidor Bunker. Apesar de ser um cenário aparentemente simples, suas funcionalidades ficam ao “gosto do cliente”.

Vamos usar o período de 1 hora como informado antes. O ambiente em questão possui uma replicação assíncrona com o site Secundário, onde as alterações feitas ficam armazenadas no RVG e replicadas no seu tempo definido. Em contra partida, o Bunker está sendo alimentado constantemente pelo site Primário, com a vantagem de não necessitarmos a utilização de um segundo RVG, pois o Bunker usa seus discos para o armazenamento das Logs.

Em caso de indisponibilidade do site Primário, seja por erro de hardware, ou alguma informação que foi corrompida, podemos optar por duas saídas. Um RPO zero, ou um RPO+RTO de até 1 hora.

No caso de um RPO zero, estamos falando então de o Bunker assumir o papel de origem da informação e enviar todas as alterações para o site Secundário, afim de permitir que o ambiente esteja up-to-date. Se podemos ter um RPO zero, por que optaria por um RTO de até 1 hora então?

Imagine que a aplicação do cliente teve algum de seus arquivos corrompidos, devido a falha de sistema, quebra de segurança ou até mesmo erro humano. Qual o tempo necessário para voltar para o ponto integro do ambiente? O software de backup seria capaz de retornar essa informação, mas qual seria o tempo necessário? Em que ponto eu conseguiria retornar essa informação?

Usando o Bunker, a replicação poderia ser estabelecida até um determinado momento, por exemplo, os próximos 50 minutos, e os 10 anteriores, onde ocorreu a falha, seriam então inutilizados no momento da replicação. Com um RTO menor, seria possível retornar a aplicação em um ponto no tempo onde o software de backup não teria condições de atuar, ou até mesmo seria necessário a intervenção de uma outra equipe para recuperar informações anteriores.

 Apesar de simples, a utilização dessa função em um cliente poderia ter várias aplicações, conseguindo mesclar entre a disponibilidade imediata do ambiente, à um ponto no tempo em que um software de backup não teria condições de auxiliar.