Backup remoto de VMs com RSYNC

As VMs (máquinas virtuais) realmente são um marco extraordinário no mundo da TI. As vantagens e facilidades são inúmeras, porém alguns desafios ganharam um pouco mais de estatura, como é o caso do backup remoto, ou seja, fora das instalações físicas por precaução contra eventuais desastres.

Nós ainda temos a opção de continuar com aquela forma antiga de realizar backup, dos dados e configurações (conteúdo) das máquinas, que agora são virtuais. Porém, o dinamismo das VMs e principalmente do mundo dos negócios não aceitam mais aquele longo tempo de indisponibilidade para restaurar um serviço. O restabelecimento precisa ser quase que imediato, e a arquitetura de VMs pode nos ajudar muito nesse desafio. Basta mudar o backup “de conteúdo” para backup “de VM”.

Existem diversas estratégias para isso. Se a empresa dispõe de capital e tem a diretriz de manter uma TI enxuta e simples, há algumas opções simplesmente maravilhosas no mercado que permitem a configuração desse backup e coisas até muito mais avançadas como “Site de Disaster Recover” através de interfaces amigáveis, claras e simples.

Porém, essa não é a realizada da grande maioria das empresas e se você precisa recorrer a ferramentas Open Source e fazer a mágica com suas próprias mãos, heis aí um desafio respeitável. Assim como no mercado de soluções “pagas”, também temos algumas opções de software livre. A MATERA fez um estudo de 2 formas de realizar o bakcup das VMs e mantê-las sincronizadas. Veja como foi:

Estratégia 1Snapshot externo: nessa estratégia nós tiramos um snapshot da VM que gera um novo HD virtual e “fecha” o anterior para somente leitura. Toda nova gravação acontece no novo HD. Assim conseguimos transferir o HD anterior e “aplica-lo” no HD principal da VM no site remoto.

Estratégia 2RSYNC: essa é uma sincronização de grandes arquivos do jeito padrão do RSYNC, sem muitos truques ou segredos.

O nosso teste

Instalamos um Linux, medimos o espaço de cada diretório (du -h /), disparamos a instalação de um pacote (yum install java) e depois medimos novamente o espaço consumido. Então realizamos a sincronização dessa diferença com o HD da VM no backup remoto.  Segue a mensagem de instalação do pacote:

(4/5): ol7_UEKR3/x86_64/primary 8.5 MB
(5/5): ol7_latest/x86_64/primary 9.9 MB
Total download size: 35 MB
Installed size: 113 MB

Agora as medições:

Tabela 1 – Medições das estratégias de sincronização remota de VMs.

As linhas destacadas nas planilhas são os tamanhos dos diretórios que aumentaram após a instalação do pacote. Os dados abaixo da tabela da estratégia do Snapshot mostram que para um aumento de 385MB dento da VM, gerou um HD virtual de 443MB, ou seja, 58MB (15%) de overhead. O arquivo a ser transferido para sincronizar o HD no site remoto é de 443MB.

Observando os dados abaixo da tabela da estratégia do RSYNC vemos que o host não percebe qualquer mudança no HD virtual da VM, pois tudo acontece apenas dentro dele. O overhead é zero! Logo abaixo está o resultado da execução do RSYNC. As linhas realçadas significam o seguinte:

  • Literal data: o tamanho dos blocos realmente alterados. Apenas 54MB, mesmo que o resultado do comando de instalação tenha reportado incremento de 168MB. Já temos um grande ganho, mas provavelmente circunstancial.
  • Sent 20.98M bytes…: com o uso do recurso de compactação do RSYNC ele transportou apenas 21MB todos os 54MB de blocos alterados.
  • Total size…: o que realmente importa no final é ospeedup“, que é quantas vezes mais rápido o RSYNC conseguiu sincronizar os arquivos comparado com a situação de transferir o arquivo inteiro. Nesse exemplo, foi quase 249 vezes mais rápido!!!

Conclusão

Os nossos testes mostraram que ambas as estratégias tem vantagens e desvantagens e que o melhor mesmo é emprega-las da forma mais apropriada de acordo com a criticidade de cada VM. As VMs críticas para o negócio, ou que implementam serviços básicos utilizados por outros serviços de TI, devem preferencialmente ter seu backup via Snapshot externo, pois a principal vantagem é o downtime zero. A grande desvantagem é que o overhead em espaço do gerenciamento das escritas no novo HD o deixam muito grande, justamente o que impede que essa estratégia seja usada para todas as VMs. No teste escolhido para o artigo ele foi muito pequeno comparado aos 160% de escritas randômicas. Como estamos num contexto de backup remoto, quanto menor o volume a ser trafegado, mais rápido seu backup vai terminar.

Já as demais VMs, que podem ter um certo tempo de downtime, especialmente fora do horário de expediente, a estratégia mais adequada parece ser o RSYNC diferencial do HD de origem para o HD de destino, pois a otimização de transportar apenas os blocos de dados atualizados e o recurso de compactação realmente otimizam em muito a transferência.

PS: Há também estratégias de reconstrução de ambiente baseadas nos softwares de gestão de configuração, como o Puppet, por exemplo, mas ainda não usamos isso internamente, então fica para um próximo post.

Links Externos

Máquinas virtuais: https://pt.wikipedia.org/wiki/M%C3%A1quina_virtual

Snapshot Externo: https://fedoraproject.org/wiki/Features/Virt_Live_Snapshots

RSYNC: https://pt.wikipedia.org/wiki/Rsync

Puppet: https://puppetlabs.com/puppet/what-is-puppet

Por EMILSON MARGOTO

Postado em: 21 de agosto de 2015

Confira outros artigos do nosso blog

Seja Digital migra para AWS com Matera

13 de dezembro de 2017

Caue dos Santos Pereira

Raspberry Pi e o propósito de Valores

28 de setembro de 2016

Emilson Margoto

Cuidados com Smartphones

27 de agosto de 2015

Jose Rafael Eloy Capucho

Deixe seu comentário