Este artigo dá continuidade
ao ciclo sobre backup
- Backup, parte 2: Visão geral e teste de ferramentas de backup baseadas em rsync
- Backup, parte 3: Revisão e teste do duplicity, duplicaty, deja dup
- Backup, parte 4: Visão geral e teste do zbackup, restic, borgbackup,
- Backup, parte 5: Teste do bacula e veeam backup for linux
- Backup, Parte 6: Comparação de ferramentas de backup
- Backup, parte 7: Conclusões
Como já mencionamos no primeiro artigo, existem muitas ferramentas de backup baseadas em rsync.
Das que melhor se adequam às nossas necessidades, vou considerar 3: rdiff-backup, rsnapshot e burp.
Conjuntos de arquivos de teste
Os conjuntos de arquivos para teste serão os mesmos para todos os candidatos, incluindo artigos futuros.
Primeiro conjunto: 10 GB de arquivos de mídia, e aproximadamente 50 MB — código fonte do site em PHP, tamanhos de arquivos variando de alguns kilobytes para o código fonte até dezenas de megabytes para os arquivos de mídia. O objetivo é simular um site estático.
Segundo conjunto: é gerado do primeiro ao renomear um subdiretório com arquivos de mídia de 5 GB. O objetivo é estudar o comportamento do sistema de backup ao renomear um diretório.
Terceiro conjunto: é gerado do primeiro ao remover 3 GB de arquivos de mídia e adicionar novos 3 GB de arquivos de mídia. O objetivo é estudar o comportamento do sistema de backup durante uma operação típica de atualização do site.
Obtendo resultados
Qualquer backup é realizado pelo menos 3 vezes e acompanhado por um descarregamento dos caches do sistema de arquivos com os comandos sync e echo 3 > /proc/sys/vm/drop_caches tanto no lado do servidor de teste quanto no servidor de armazenamento de backup.
No servidor que será a fonte dos backups, foi instalado um software de monitoramento — netdata, que será utilizado para avaliar a carga no servidor durante a cópia, isso é necessário para avaliar a carga do servidor durante o processo de backup.
Também considero que o servidor de armazenamento de backups é mais lento em processamento do que o servidor principal, mas possui discos mais espaçosos com uma velocidade de escrita aleatória relativamente baixa — a situação mais comum durante o backup, e devido ao fato de que o servidor de backup não deve realmente realizar outras tarefas além do backup, eu não monitorarei sua carga com netdata.
Além disso, meus servidores mudaram, nos quais vou testar diferentes sistemas de backup.
Atualmente, eles têm as seguintes característicasProcessador
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (usando LuaJIT 2.0.4 do sistema)
Executando o teste com as seguintes opções:
Número de threads: 2
Inicializando o gerador de números aleatórios a partir do tempo atual
Limite de números primos: 20000
Inicializando as threads de trabalho...
Threads iniciadas!
Velocidade da CPU:
eventos por segundo: 1081.62
Estatísticas gerais:
tempo total: 30.0013s
número total de eventos: 32453
Latência (ms):
min: 1.48
avg: 1.85
max: 9.84
percentil 95: 2.07
soma: 59973.40
Equidade das threads:
eventos (avg/stddev): 16226.5000/57.50
tempo de execução (avg/stddev): 29.9867/0.00
Memória RAM, leitura…
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.0.17 (usando LuaJIT 2.0.4 do sistema)
Executando o teste com as seguintes opções:
Número de threads: 4
Inicializando o gerador de números aleatórios a partir do tempo atual
Executando o teste de velocidade da memória com as seguintes opções:
tamanho do bloco: 1KiB
tamanho total: 102400MiB
operação: ler
escopo: global
Inicializando as threads de trabalho...
Threads iniciadas!
Total de operações: 104857600 (5837637.63 por segundo)
102400.00 MiB transferidos (5700.82 MiB/seg)
Estatísticas gerais:
tempo total: 17.9540s
número total de eventos: 104857600
Latência (ms):
min: 0.00
avg: 0.00
max: 66.08
percentil 95: 0.00
soma: 18544.64
Equidade das threads:
eventos (avg/stddev): 26214400.0000/0.00
tempo de execução (avg/stddev): 4.6362/0.12
… e gravação
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.0.17 (usando LuaJIT 2.0.4 do sistema)
Executando o teste com as seguintes opções:
Número de threads: 4
Inicializando o gerador de números aleatórios a partir do tempo atual
Executando o teste de velocidade da memória com as seguintes opções:
tamanho do bloco: 1KiB
tamanho total: 102400MiB
operação: gravar
escopo: global
Inicializando as threads de trabalho...
Threads iniciadas!
Total de operações: 91414596 (3046752.56 por segundo)
89272.07 MiB transferidos (2975.34 MiB/seg)
Estatísticas gerais:
tempo total: 30.0019s
número total de eventos: 91414596
Latência (ms):
min: 0.00
avg: 0.00
max: 1022.90
percentil 95: 0.00
soma: 66430.91
Equidade das threads:
eventos (avg/stddev): 22853649.0000/945488.53
tempo de execução (avg/stddev): 16.6077/1.76
Disco no servidor de origem de dados
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (usando LuaJIT do sistema 2.0.4)
Executando o teste com as seguintes opções:
Número de threads: 4
Inicializando gerador de números aleatórios a partir do horário atual
Flags de abertura de arquivo extras: (nenhum)
128 arquivos, 8MiB cada
1GiB de tamanho total do arquivo
Tamanho do bloco 4KiB
Número de solicitações de I/O: 0
Relação de leitura/escrita para o teste de I/O aleatório combinado: 1.50
FSYNC periódico habilitado, chamando fsync() a cada 100 solicitações.
Chamando fsync() no final do teste, Habilitado.
Usando modo de I/O síncrono
Realizando teste aleatório de r/w
Inicializando threads de trabalho...
Threads iniciadas!
Operações com arquivos:
leituras/s: 4587.95
gravações/s: 3058.66
fsyncs/s: 9795.73
Throughput:
leitura, MiB/s: 17.92
gravado, MiB/s: 11.95
Estatísticas gerais:
tempo total: 60.0241s
número total de eventos: 1046492
Latência (ms):
min: 0.00
avg: 0.23
max: 14.45
percentil 95: 0.94
soma: 238629.34
Justiça entre threads:
eventos (média/desvio padrão): 261623.0000/1849.14
tempo de execução (média/desvio padrão): 59.6573/0.00
Disco no servidor de armazenamento de backups
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (usando LuaJIT do sistema 2.0.4)
Executando o teste com as seguintes opções:
Número de threads: 4
Inicializando gerador de números aleatórios a partir do horário atual
Flags de abertura de arquivo extras: (nenhum)
128 arquivos, 8MiB cada
1GiB de tamanho total do arquivo
Tamanho do bloco 4KiB
Número de solicitações de I/O: 0
Relação de leitura/escrita para o teste de I/O aleatório combinado: 1.50
FSYNC periódico habilitado, chamando fsync() a cada 100 solicitações.
Chamando fsync() no final do teste, Habilitado.
Usando modo de I/O síncrono
Realizando teste aleatório de r/w
Inicializando threads de trabalho...
Threads iniciadas!
Operações com arquivos:
leituras/s: 11.37
gravações/s: 7.58
fsyncs/s: 29.99
Throughput:
leitura, MiB/s: 0.04
gravado, MiB/s: 0.03
Estatísticas gerais:
tempo total: 73.8868s
número total de eventos: 3104
Latência (ms):
min: 0.00
avg: 78.57
max: 3840.90
percentil 95: 297.92
soma: 243886.02
Justiça entre threads:
eventos (média/desvio padrão): 776.0000/133.26
tempo de execução (média/desvio padrão): 60.9715/1.59
Velocidade da rede entre os servidores
iperf3 -c backup
Conectando ao host backup, porta 5201
[ 4] local x.x.x.x porta 59402 conectado a y.y.y.y porta 5201
[ ID] Intervalo Transferência Largura de Banda Retr Cwnd
[ 4] 0.00-1.00 seg 419 MBytes 3.52 Gbits/seg 810 182 KBytes
[ 4] 1.00-2.00 seg 393 MBytes 3.30 Gbits/seg 810 228 KBytes
[ 4] 2.00-3.00 seg 378 MBytes 3.17 Gbits/seg 810 197 KBytes
[ 4] 3.00-4.00 seg 380 MBytes 3.19 Gbits/seg 855 198 KBytes
[ 4] 4.00-5.00 seg 375 MBytes 3.15 Gbits/seg 810 182 KBytes
[ 4] 5.00-6.00 seg 379 MBytes 3.17 Gbits/seg 765 228 KBytes
[ 4] 6.00-7.00 seg 376 MBytes 3.15 Gbits/seg 810 180 KBytes
[ 4] 7.00-8.00 seg 379 MBytes 3.18 Gbits/seg 765 253 KBytes
[ 4] 8.00-9.00 seg 380 MBytes 3.19 Gbits/seg 810 239 KBytes
[ 4] 9.00-10.00 seg 411 MBytes 3.44 Gbits/seg 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervalo Transferência Largura de Banda Retr
[ 4] 0.00-10.00 seg 3.78 GBytes 3.25 Gbits/seg 8100 remetente
[ 4] 0.00-10.00 seg 3.78 GBytes 3.25 Gbits/seg receptor
Metodologia de teste
- O sistema de arquivos está sendo preparado no servidor de teste com o primeiro conjunto de testes, o repositório no servidor de backup está sendo inicializado, se necessário.
O processo de backup está sendo iniciado e seu tempo está sendo medido. - Os arquivos estão sendo migrados no servidor de teste para o segundo conjunto de testes. O processo de backup está sendo iniciado e seu tempo está sendo medido.
- O servidor de teste está realizando a migração para o terceiro conjunto de testes. O processo de backup está sendo iniciado e seu tempo está sendo medido.
- O terceiro conjunto de testes obtido é considerado o novo primeiro; os itens 1-3 são repetidos mais 2 vezes.
- Os dados são inseridos em uma tabela resumo, gráficos do netdata são adicionados.
- Um relatório é elaborado para o método de backup separado.
Resultados Esperados
Como todos os 3 candidatos se baseiam na mesma tecnologia (rsync), espera-se que os resultados sejam próximos do rsync comum, incluindo todas as suas vantagens, a saber:
- Os arquivos no repositório serão armazenados "como estão".
- O tamanho do repositório só aumentará incluindo a diferença entre os backups.
- Haverá uma carga relativamente alta na rede durante a transmissão de dados, bem como uma carga baixa no processador.
O teste do rsync comum será utilizado como referência, seus resultados
são os seguintes
O gargalo estava no servidor de armazenamento de backups na forma de um disco baseado em HDD, o que pode ser claramente visto nos gráficos em forma de serra.
Os dados foram copiados em 4 minutos e 15 segundos.
Teste do rdiff-backup
O primeiro candidato é o rdiff-backup, um script em Python que realiza o backup de um diretório para outro. Nesse processo, o backup atual é armazenado "como está", enquanto os backups anteriores são acumulados em um subdiretório específico incrementalmente, economizando assim espaço.
Vamos verificar o modo de operação típico, ou seja, o cliente inicia o processo de backup por conta própria, enquanto no servidor é ativado um processo que aceita os dados para o backup.
Vamos dar uma olhada, no que ele é capaz em nossas condições.
Tempo de execução de cada teste:
Primeira execução
Segunda execução
Terceira execução
Primeiro conjunto
16m32s
16m26s
16m19s
Segundo conjunto
2h5m
2h10m
2h8m
Terceiro conjunto
2h9m
2h10m
2h10m
O rdiff-backup reage de forma bastante dolorosa a qualquer grande alteração de dados, e não utiliza completamente a rede.
Teste do rsnapshot
O segundo candidato é o rsnapshot, que é um script em Perl, cuja principal exigência para operação eficiente é o suporte a links duros. Assim, economiza-se espaço no disco. Os arquivos que não foram alterados desde o último backup referenciam o arquivo original através de links duros.
Além disso, a lógica do processo de backup foi invertida: o servidor ativamente "vai" até seus clientes e coleta os dados.
Resultados do teste
os seguintes resultados foram obtidos
Primeira execução
Segunda execução
Terceira execução
Primeiro conjunto
4m22s
4m19s
4m16s
Segundo conjunto
2m6s
2m10s
2m6s
Terceiro conjunto
1m18s
Executou de forma muito rápida, muito mais rápido que o rdiff-backup e muito próximo do rsync puro.
Executou de forma muito rápida, muito mais rápido que o rdiff-backup e muito próximo do rsync puro.
Teste do burp
Outra opção é a implementação em C sobre o librsync — burp, que tem uma arquitetura cliente-servidor incluindo autorização de clientes e a presença de uma interface web (não incluída na entrega básica). Outra característica interessante é o backup sem direito de recuperação para os clientes.
Vamos olhar para
11m21sdesempenho.
Primeira execução
Segunda execução
Terceira execução
Primeiro conjunto
11m10s
10m56s
5m37s
Segundo conjunto
5m40s
5m35s
3m33s
Terceiro conjunto
3m24s
3m40s
Executou duas vezes mais devagar que o rsnapshot, mas ainda assim rapidamente, e com certeza mais rápido que o rdiff-backup. Os gráficos são um pouco serrilhados — a performance novamente esbarra no subsistema de disco do servidor de armazenamento de backups, embora isso não seja tão evidente quanto no rsnapshot.
Funcionou duas vezes mais devagar que o rsnapshot, mas ainda assim é suficientemente rápido e definitivamente mais rápido que o rdiff-backup. Os gráficos são um pouco dentados — o desempenho, mais uma vez, é limitado pelo subsistema de disco do servidor de armazenamento de backups, embora isso não seja tão acentuado quanto no rsnapshot.
Resultados
O tamanho dos repositórios de todos os candidatos era aproximadamente o mesmo, ou seja, primeiro cresceu até 10 GB, depois até 15 GB, depois até 18 GB e assim por diante, o que está relacionado à particularidade do funcionamento do rsync. Também é importante notar que todos os candidatos eram de thread único (carga do processador em torno de 50% em uma máquina dual-core). Todos os 3 candidatos ofereciam a possibilidade de restaurar o último backup "como está", ou seja, era possível restaurar arquivos sem usar qualquer programa externo, incluindo aqueles utilizados para criar os repositórios. Isso também é uma "herança natural" do rsync.
Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.
Quanto mais complexa for a solução de backup e quanto mais recursos diferentes ela tiver, mais lentamente ela funcionará, mas qualquer uma delas será adequada para projetos que não exigem muito, exceto, talvez, o rdiff-backup.
Anúncio
Esta nota continua o ciclo sobre backup
Backup, parte 2: Visão geral e teste de ferramentas de backup baseadas em rsync
Backup, parte 3: Revisão e teste do duplicity, duplicaty, deja dup
Backup, parte 4: Visão geral e teste do zbackup, restic, borgbackup,
Backup, parte 5: Teste do bacula e veeam backup for linux
Backup, Parte 6: Comparação de ferramentas de backup
Backup, parte 7: Conclusões
Autor da publicação: Pavel Demkovich
Fonte: habr.com
