Tuning: Melhor Performance e Tratamento de Gargalos do Backup

Bacula

  • Algumas empresas usam Antivírus para Windows e até para Linux. Coloque os Daemons do Bacula como excessões de verificação.
  • Dividir o FileSet em dois quando for fazer backup de mais de 20 milhões de arquivos.

Especialmente os sistemas de arquivos do Windows não lidam bem com volumes com quantidade gigantesca de arquivos pequenos. Neste caso, o ideal é criar múltiplos FileSets e Jobs (ex.: um para cada Volume ou alguns diretórios), de maneira a paralelizar as operações de cópia. Por exemplo, um servidor com volumes C: e E:.

Job1, FileSet1. Include, File = “C:/”

Job2, FileSet2. Include, Plugin = “alldrives: exclude=C”

Job3, FileSet3. Include, Plugin = “vss:/@SYSTEMSTATE/”

O uso do alldrives é importante para fazer backup de todos os outros drives exceto o C:, que já é backupeado pelo Job1. Se alguém criar um novo Volume neste servidor, o Job2 já irá fazer backup automaticamente.

O Job3 seria para backup exclusivo do System State do Windows (caso deseje separar também). O vss: é um plugin exclusivo do Enterprise, mas também é possível utilizar scripts para gerar o System State do Windows em um volume aparte.

Em algumas interfaces gráficas (como a Bweb), é possível agrupar os Jobs de um mesmo cliente para fins de melhor gestão e estatísticas.

  • Diminuir o nível de compressão do GZIP (se habilitado – sempre menos de 6) ou utilizar LZO. Não usar a compressão via software do Bacula para fitas.
  • Executar múltiplos jobs de backup simultâneos (Maximum Concurrent Jobs).

Tenha certeza de habilitar a concorrência nos 4 lugares:

a) Recurso Director no bacula-dir.conf

b) Recurso Storage no bacula-dir.conf

c) Recurso Storage no bacula-sd.conf

d) Recurso Device stanza in bacula-sd.conf

  • Fazer backup em múltiplos discos, fitas ou diferentes storages daemons simultâneamente.
  • Fitas: Habilitar o Spooling de Disco SSD/NVME. Discos HD tradicionais podem ser mais lentos que as fitas.
  • Fitas: Aumentar o Minimum (ex.: 256K) e Maximum Block Size para 256K a 512K (*para LTO4. 1M muito grande e pode gerar problemas. Especificado no: bacula-sd.conf, recurso Device). Necessário recriar todos os volumes com o novo tamanho máximo de bloco, caso contrário o Bacula não conseguirá ler os anteriores.
  • Fitas:  Aumentar o Maximum File Size para 10GB to 20GB (Especificado no: bacula-sd.conf, recurso Device).
  • Desabilitar o AutoPrunning de Clientes e Jobs (Prunar os volumes uma vez por dia através de um Admin Job).
  • Turn on Attribute Spooling for all Jobs (Padrão para a versão 7.0 em diante).
  • Utilizar inserção em lotes (batch insert) no banco de dados (normalmente é padrão, definido na compilação e precisa ser suportado pelo banco).

Catálogo (banco de dados)

a) PostgreSQL

  • Evitar a criação de índices acicionais.
  • Utilizar configurações especiais para o Postgresql (postgresql.conf):

wal_buffers = 64kB
shared_buffers = 1GB # up to 8GB
work_mem = 64MB
effective_cache_size = 2GB
checkpoint_segments = 64
checkpoint_timeout = 20min
checkpoint_completion_target = 0.9
maintenance_work_mem = 256MB

synchronous_commit = on

  • Realização (periódica) de um vacuumdb na base de dados (postgreSQL), com o passar do tempo a grande alteração de registros acaba por deixar a inserção no banco mais demorada. [1]

[1] Dica do Edmar Araújo. Referências: http://www.postgresql.org/docs/9.0/static/app-vacuumdb.html | Carlos Eduardo Smanioto -> Otimização – Uma Ferramenta Chamada Vacuum: http://www.devmedia.com.br/otimizacao-uma-ferramenta-chamada-vacuum/1710

b) MySQL

  • Utilizar configurações especiais para o MySQL:

sort_buffer_size = 2MB
innodb_buffer_pool_size = 128MB

innodb_flush_log_at_trx_commit = 0

innodb_flush_method = O_DIRECT

Como padrão, o innodb_flush_log_at_trx_commit seria 1, significando que o log da transação é armezenado no disco a cada commit no banco e as transações não seriam perdidas no caso de um crash do sistema operacional. Como o Bacula utiliza muitas transações pequenas, você pode reduzir o I/O das logs e aumentar exponencialmente a performance dos backups configurando para 0, significando que não haverá armazenamento de log a cada transação. Como caso de interrupção seria necessário reiniciar o job de backup de qualquer sorte, mostra-se uma opção bastante interessante.

  • Executar o mysqltuner (apt-get install mysql tuner) e implementar as modificações sugeridas.

Rede (SD e FD)

  • Adicionar mais interfaces (bonding/NIC Teaming) e switches mais rápidos (pode usar o comando do Bacula status network ou a aplicação ethtool para verificar a velocidade de sua conexão ethernet).
  • Ajustar o Maximum Network Buffer Size = bytes, que especifica o tamanho inicial do buffer de rede. Este tamanho é ajustado para baixo se o SO operacional não aceitar, ao custo de muitas chamadas de sistemas (não desejado). O valor padrão é 32,768 bytes. O padrão foi escolhido para ser largo o suficiente para transmissão via internet, mas em uma rede local pode ser aumentado para melhoria da performance. Alguns usuários perceberam uma melhoria de 10 vezes de transferência de tados utilizando 65,536 bytes neste valor.
  • Evitar tráfego por firewalls e roteadores.
  • Usar Frames Jumbo.
  • Customizar o Kernel (Ref.: https://fasterdata.es.net/host-tuning/linux/. Exemplo:
echo "
# allow testing with buffers up to 128MB
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# increase Linux autotuning TCP buffer limit to 64MB
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
# recommended default congestion control is htcp
net.ipv4.tcp_congestion_control=htcp
# recommended for hosts with jumbo frames enabled
# net.ipv4.tcp_mtu_probing=1
# recommended for CentOS7+/Debian8+ hosts
net.core.default_qdisc = fq" >> /etc/sysctl.conf

reboot

Sistema Operacional

  • RAM (> 8GB)
  • vm.dirty_ratio = 2
  • vm.dirty_background_ratio = 1
  • vm.swappiness = 10
  • vm.zone_reclaim_node = 0

Acesso aos Discos

  • Use o sistema de arquivos XFS, pois ele se destaca na execução de operações paralelas de entrada/saída (E/S) devido ao seu design, que é baseado em grupos de alocação (um tipo de subdivisão dos volumes físicos nos quais o XFS é usado, encurtado para AGs). Por causa disso, o XFS permite extrema escalabilidade de threads de E/S, largura de banda do sistema de arquivos e tamanho dos arquivos e do sistema de arquivos em si, ao abranger vários dispositivos de armazenamento físico.
  • Usar o “deadline disk scheduler”.
  • Usar RAID com um bom controlador com bateria (ex.: ARECA).

 

 

Disponível em: pt-brPortuguêsenEnglish (Inglês)esEspañol (Espanhol)

Deixe uma resposta