Se você conhece um pouco sobre Data Centers, Servidores e Serviços Críticos de TI, provavelmente já ouviu falar da sigla DR ou do termo Disaster Recovery.
Então vamos lá!
Disaster Recovery é um conjunto de políticas e procedimentos para permitir a recuperação ou a continuidade da infraestrutura computacional e sistemas da informação após um evento massivo ocasionado por um desastre natural, falhas de hardware ou até mesmo um evento provocado por um ser humano.
A recuperação de desastre foca na TI ou sistemas da informação que suportam funções do negócio e para isso, se faz necessária a elaboração de um Plano de Recuperação de Desastres, conhecido como DRP ou Disaster Recovery Plan. Um DRP normalmente é desenvolvido de acordo com a necessidade e exigência de cada negócio e geralmente composto por 3 fases:
Programa de Administração de Crise Este trata de um plano desenvolvido em conjunto, com definições de atividade, pessoas envolvidas, servidores e dados físicos ou virtuais.
Plano de Continuidade Operacional Este possui diretivas do que fazer em cada operação ou procedimentos em caso de um desastre.
Plano de Recuperação de Desastres Este trata da aplicação prática do plano de continuidade operacional, ou seja, nesta fase, já estamos colocando a mão na massa.
Dentro de um DRP (disaster recovery plan) é preciso selecionar uma estratégia de recuperação em caso de um desastre, e para que isso aconteça, precisamos indicar métricas de RPO e RTO dentro do nosso negócio.
Rapidamente, vou falar sobre estes 2 pontos tão importantes dentro de um DRP. O RTO, ou Recovery Time Objective, está relacionado ao período máximo de tempo que o sistema levará para voltar a operar após uma parada ou dificuldade massiva. Já o RPO, ou Recovery Point Objective, está relacionado a quantidade de dados ou informações que é tolerável perder em caso de parada nas operações.
Em resumo, na hora de elaborar seu plano de DRP você precisa se fazer 2 perguntas para indicar as métricas de RTO e RPO:
1 - Quanto tempo nossos sistemas da informação poderão ficar inoperantes após um desastre?
2 - Qual a quantidade de dados ou intervalo em que o negócio irá tolerar perda?
Com base no que falei até aqui, parece ser algo fácil, porém não basta ter um plano com diretivas, procedimentos e métricas se não tivermos recursos computacionais para o processamento e armazenamento destas informações em um segundo Data Center ou Zona de Disponibilidade.
Vou explicar de forma mais prática…
É importante estarmos cientes que na maioria dos cenários, todos os recursos computacionais disponíveis e em uso no Data Center principal (SITE A), precisarão estar disponíveis no Data Center secundário (SITE B).
Então imagine o seguinte: sua empresa elaborou um DRP, e através de uma determinada solução de virtualização ou ferramenta de replicação, está realizando sincronismo de dados baseado nas métricas definidas entre SITE A e SITE B. No SITE-A, a empresa possui um cluster computacional com 10 servidores físicos e está utilizando 80% dos recursos de CPU e 90% dos recursos de memória do parque. Já no SITE-B, possui apenas 5 servidores físicos idênticos aos modelos disponíveis no SITE-A.
Desta forma, é possível observar neste caso, que com recursos limitados no Data Center secundário, não será possível realizar a inicialização de todos os serviços, pois a capacidade computacional do ambiente de spare é inferior a capacidade do recurso alocado na produção.
Para concluir, quero te falar sobre uma solução Open Source que já trabalhamos há uma década, e que permite realizarmos configurações de Disaster Recovery nativamente, o Ceph Storage. Confira mais detalhes neste post.
O Ceph permite a configuração de Disaster Recovery de blocos de forma assíncrona entre dois clusters utilizando o RBD Mirroring, e esse recurso está disponível em dois modos:
Jounal-based: Este modo usa o recurso de imagem de registro em diário RBD para garantir replicação point-in-time e consistente com falhas entre clusters. Cada gravação na imagem RBD é primeiro gravada no diário associado antes de modificar a imagem real. O cluster remoto irá ler a partir deste diário associado e reproduzirá as atualizações em sua cópia local da imagem. Como cada gravação na imagem RBD resultará em duas gravações no cluster Ceph, espere que as latências de gravação quase dupliquem ao usar o recurso de imagem de diário RBD.
Snapshot-based: Este modo usa instantâneos de espelho de imagem RBD agendados periodicamente ou criados manualmente para replicar imagens RBD consistentes com falhas entre clusters. O cluster remoto determinará quaisquer atualizações de dados ou metadados entre dois instantâneos espelhados e copiará os deltas para sua cópia local da imagem. Com a ajuda do recurso de imagem RBD fast - fast-diff, os blocos de dados atualizados podem ser determinados rapidamente sem a necessidade de digitalizar a imagem completa do RBD. Como esse modo não é tão refinado quanto o diário, o delta completo entre dois instantâneos precisará ser sincronizado antes do uso durante um cenário de failover. Desta forma, qualquer conjunto de deltas parcialmente aplicado será revertido no momento do failover.
Dependendo das necessidades desejadas de replicação em seu negócio, o espelhamento RBD pode ser configurado para replicação unidirecional ou bidirecional.
Além do RBD Mirroring, Ceph Storage tem a capacidade de replicar objetos ativamente entre 3 ou mais Data Centers ou Zonas de Disponibilidade usando um CRUSH Map personalizado.
Neste modelo, há a necessidade dos Data Centers estarem interconectados em alto throughput e baixa latência, além do cluster Ceph estar unificado em uma mesma configuração durante sua formação e deployment.
Neste modo, ao realizar a criação de uma máquina virtual ou serviço no cluster, dados são replicados entre diferentes regiões geográficas e em caso de falha massiva em um dos Data Centers, todas as VMS irão convergir para uma outra Zona de Disponibilidade.
O mais interessante ao utilizar este cenário é que nenhum dado é perdido, ou seja, apenas é gerada indisponibilidade momentânea das VMS alocadas no ambiente, tratando-se de um Downtime temporário até que o serviço de HA inicie os serviços em um outro Data Center.
Ao utilizar este modelo em seu DRP, na maioria dos casos é possível considerar apenas métricas de RTO como prioridade, pois os dados replicados garantem cópias integras em pelo menos dois sites ativamente.
Quer saber mais sobre como implantar essa solução em seu negócio? Entre em contato com a gente!
Guto Rodrigues | Founder & CEO | NewFront
Comments