Fazendo Testes de Performance em Repositórios Linux de Backup
Uma das principais expectativas que se tem dentro de um ambiente de backup é sem sombra de dúvidas o quão rápido você consegue se recuperar de um desastre. Sem sombra de dúvidas esse é um fator importante, mas que é necessário entender como os componentes de backup se relacionam entre si. Caso você ainda não conheça todos os componentes do Veeam eu te convido a ler esse meu artigo aqui, onde eu explico quais são os principais componentes e por que eles são necessários e importante dentro da infraestrutura de backup como um todo.
RTO (Recovery Time Objective)
O RTO, que numa tradução direta significa objetivo de tempo de recuperação, nada mais é que o tempo máximo que um computador, sistema ou aplicativo pode ficar inoperante após uma falha. Os RTOs normalmente são definidos pelas áreas de negócio de uma empersa e leva como base a aplicação de um servidor ou sistema e qual é o seu impacto nos negócios. Perda de dados e interrupções afetam a geração de receita, e quantificar o impacto de uma interrupção é um fator-chave na determinação de RTOs.
Entretanto para conseguir atender os requisitos dos RTOs é necessário configurar o ambiente de maneira adequada maximizando os desempenhos dos componentes do ambiente de backup e minimizando os tempos de recuperação de dados.
Imaginando o cenário de um ambiente de TI complexo, com diversas aplicações e uma varieade grande nos tipos de dados que podemos restaurar, fica complexo de se pensar em um RTO geral para cada uma dessas aplicações visto que cada uma dela possuem complexidades diferentes e tamanho de servidores diferentes entre si. Sendo assim, um bom modo que eu gosto de pensar nos RTOs é estipular um valor de tempo para cada Terabyte recuperado por hora. Alguns exemplos como 1 terabyte por hora, 3 terabytes por hora, 5 terabytes por hora podem ser alguns dos valores interessantes para o negócio. É importante nesse momento você estar inteirado e com conhecimento de como essas aplicações funcionam dentro da corporação e do negócio sim.
Repositório de Backup
Entendido isso, um dos principais componentes responsáveis por ume alta performance nas restaurações de backup é o resositório de backup. O repositório é o componente reponsável por armazenar todos os backups gerados através do Veeam. Sendo assim, para conseguir atender um bom tempo na recuperação desses dados é importante que esse repositório tenha uma boa performance de I/O. É através do I/O e principalmente através das velocidades de leitura e escrita desse repositório que nós conseguimos garantir essa recuperabilidade de dados através da métrica terabyte/hora.
Teste de Performance de Disco
Nos testes que vou apresentar aqui eu utilizei um repositório de backup Linux com imutabilidade ativa dentro do Veeam. Caso você ainda não sabe como configurar um repositório imutável no linux eu também te convido a ler esse meu artigo aqui.
Para os testes em questão eu utilizei o utilitário fio diretamente no sistema operacional Linux. Diversos utilitários podem ser escolhidos para fazer esses teste, porém eu optei por utilizar ele justamente porque a própria Veeam recomenda o uso dele através do artigo KB2014 da sua base de conhecimento.
Para instalar o fio, como eu estou utilizando um repositório Linux baseado em Debian, basta você usar o comando apt install fio.
Teste de Active Full
Para simular um teste de performance de um backup do tipo active full basta rodar o seguinte comando abaixo:
fio --name=full-write-test --filename=/backup/testfile-activefull.dat --size=1024G --bs=512k --rw=write --ioengine=libaio --direct=1 --time_based --runtime=600s
Tenha em mente que no seu ambiente o caminho /backup e o arquivo testfile-activefull.dat deve ser substituido pelo path do servidor e também pelo nome de arquivo de sua preferência.
Além disso o parametro –size=1024G deve ser substituido pelo tamanho de arquivo da sua necessidade. Eu gosto de optar por um arquivo de 1 terabyte justamente para dar corpo e robustes para o teste.
Sendo assim, ao rodar o comando nos temos o seguinte resultado:
Resultado
Como podemos ver acima o resultado foi o seguinte:
Run status group 0 (all jobs):
WRITE: bw=1777MiB/s (1863MB/s), 1777MiB/s-1777MiB/s (1863MB/s-1863MB/s), io=1041GiB (1118GB), run=600001-600001msec
Disk stats (read/write):
dm-5: ios=69668/2402236, merge=0/0, ticks=7897960/639636, in_queue=8537596, util=100.00%, aggrios=140712/4613752, aggrmerge=1/393, aggrticks=14063087/1088530, aggrin_queue=15151616, aggrutil=100.00%
sdb: ios=140712/4613752, merge=1/393, ticks=14063087/1088530, in_queue=15151616, util=100.00%
Chegamos a conclusão que o resultado teve valores entre 1777 e 1863 megabytes por segundo.
Dessa forma o que também gosto de fazer é transformar esse valor em terabyte por hora ao invés do megabyte por segundo que foi apresentado no testei. Para isso basta fazer o seguinte calculo:
MB/s / 1024/ 1024 * 3600
Esse calculo nada mais é que do que atransformação do megabyte em terabyte e depois disso a multiplicação do resultado pela quantidade de segundos dentro de uma hora que são 3600.
Nesse meu exemplo eu consegui obter o resultado de 6.1 TB por hora.
Teste de Synthetic Full
Para simular um teste de performance de um backup do tipo synthetic full basta rodar o seguinte comando abaixo:
fio --name=merge-test --filename=/backup/testfile-syntheticfull.dat --size=10240G --bs=512k --rw=randrw --rwmixwrite=50 --direct=1 --ioengine=libaio --iodepth=4 --runtime=600 --time_based
Também tenha em mente que no seu ambiente o caminho /backup e o arquivo testfile-activefull.dat deve ser substituido pelo path do servidor e também pelo nome de arquivo de sua preferência.
Lemebre-se também do parametro –size=1024G deve ser substituido pelo tamanho de arquivo da sua necessidade. Eu gosto de optar por um arquivo de 1 terabyte justamente para dar corpo e robustes para o teste.
Caso foi ainda não é familiarizado de com o backup do tipo synthetic full, recomendo a ler a documentação oficial da Veeam.
Sendo assim, ao rodar o comando nos temos o seguinte resultado:
Resultado
Como podemos ver acima o resultado foi o seguinte:
Run status group 0 (all jobs):
READ: bw=78.4MiB/s (82.2MB/s), 78.4MiB/s-78.4MiB/s (82.2MB/s-82.2MB/s), io=45.9GiB (49.3GB), run=600029-600029msec
WRITE: bw=78.1MiB/s (81.9MB/s), 78.1MiB/s-78.1MiB/s (81.9MB/s-81.9MB/s), io=45.8GiB (49.1GB), run=600029-600029msec
Disk stats (read/write):
dm-5: ios=109450/256429, merge=0/0, ticks=2841452/275636, in_queue=3117088, util=98.17%, aggrios=243337/557844, aggrmerge=5/147, aggrticks=5639959/656148, aggrin_queue=6296106, aggrutil=98.87%
sdb: ios=243337/557844, merge=5/147, ticks=5639959/656148, in_queue=6296106, util=98.87%
Chegamos a conclusão que o resultado teve valores entre 78 e 82 megabytes por segundo.
Dessa forma o que também gosto de fazer é transformar esse valor em terabyte por hora ao invés do megabyte por segundo que foi apresentado no testei. Para isso basta fazer o seguinte calculo:
MB/s / 1024/ 1024 * 3600
Esse calculo nada mais é que do que atransformação do megabyte em terabyte e depois disso a multiplicação do resultado pela quantidade de segundos dentro de uma hora que são 3600.
Nesse meu exemplo eu consegui obter o resultado de 200 GB por hora.
Podemos ver que o synthetic full possui uma performance menor do que o active full. Isso se deve principalmente ao jeito que o synhtetic full funciona.
Testes de Rede
Além dos teses de performance de disco, também é bem importante fazer os testes na camada de conectividade e de rede. O servidor Linux em questão possui uma interface de 10 Gbps e um bom teste que eu gosto de fazer é tranferir um arquivo entre o repositório e um outro servidor localizado na mesma rede.
Um testes simples que gosto de fazer é a cópia de arquivos através do WinSCP. Com isso é possível fazer a transferência do arquivo através do repositório Linux e um outro servidor Windows na rede. No meu teste eu consegui chegar na seguinte taxa:
Transfereindo um arquivo simples de 100GB eu consegui chegar na taxa de 34 megabytes por segundo. Seguindo o mesmo cálculo utilizado anteriormente de MB/s / 1024/ 1024 * 3600, se chegou a conclusão do resultado de 115 GB por hora.
Teste de Restore de Backup
Por último é importante também fazer uma restauração de backup, afinal de contas é com a restauração do backup que você vai ter os números finais de recuperação.
Nesse meu exemplo eu fiz um restore de arquivo, do tipo guest file, de um arquivo de um pouco mais de 1 TB e consegui uma taxa de 190 megebaytes por segundo:
Seguindo o mesmo cálculo utilizado anteriormente de MB/s / 1024/ 1024 * 3600, se chegou a conclusão do resultado de 650 GB por hora.
Conclusão
Concluo assim dizendo que o tempo de restauração de um backup esta atrelado a diversos outros fatores e que se conversam entre si. É preciso entender o ambiente e saber onde que se encontra os principais gargalos para conseguir chegar nas respostas adequadas para o tempo de recuperação de um disastre.
