Blog

Ajuste: Mejor Rendimiento y Tratamiento de Cuellos de Botella de Respaldo

Ajuste: Mejor Rendimiento y Tratamiento de Cuellos de Botella de Respaldo

Bacula

  • Algunas empresas utilizan Antivirus para Windows e incluso para Linux. Ponga los Daemons de Bacula como excepciones.
  • Divida el FileSet en dos al realizar copias de seguridad de más de 20 millones de archivos.

Los sistemas de archivos de Windows, especialmente, no manejan bien volúmenes con cantidades gigantescas de archivos pequeños. En este caso, lo ideal es crear múltiples FileSets y Jobs (ej .: uno para cada Volumen o algunos directorios), con el fin de paralelizar las operaciones de copia. Por ejemplo, un servidor con volúmenes C: y E :

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

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

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

El uso de alldrives es importante para realizar copias de seguridad de todas las demás unidades excepto C :, que ya está respaldada por Job1. Si alguien crea un nuevo volumen en este servidor, Job2 realizará una copia de seguridad automáticamente.

Job3 sería para una copia de seguridad exclusiva del estado del sistema de Windows (si también desea separar). Vss: es un complemento exclusivo para empresas, pero también es posible usar scripts para generar el estado del sistema de Windows en un volumen separado.

En algunas interfaces gráficas (como Bweb), es posible agrupar Trabajos del mismo cliente para una mejor gestión y estadísticas.

  • Disminuya el nivel de compresión GZIP (si está habilitado, siempre menos de 6) o use LZO. No utilice la compresión a través del software Bacula para cintas.
  • Ejecute varios trabajos de copia de seguridad simultáneos (Maximum Concurrent Jobs).

Asegúrese de habilitar la competencia en los 4 lugares:

a) Recurso Director en bacula-dir.conf

b) Recurso Storage en bacula-dir.conf

c) Recurso Storage en bacula-sd.conf

d) Recurso Device en bacula-sd.conf

  • Realice copias de seguridad en varios discos, cintas o diferentes demonios de almacenamiento simultáneamente.
  • Cintas: habilite el spooling de disco SSD/NVME. Los discos HD tradicionales pueden ser más lentos que las cintas.
  • Cintas: aumente el tamaño de bloque mínimo (por ejemplo, 256 K) y máximo de 256 K a 512 K (* para LTO4. 1 M es demasiado grande y puede causar problemas. Especificado en: bacula-sd.conf, función del dispositivo). Es necesario volver a crear todos los volúmenes con el nuevo tamaño máximo de bloque, de lo contrario Bacula no podrá leer los anteriores.
  • Cintas: aumente el tamaño máximo de archivo de 10 GB a 20 GB (especificado en: bacula-sd.conf, función de dispositivo).
  • Deshabilite AutoPrunning para clientes y trabajos (poda de volúmenes una vez al día a través de un trabajo de administrador).
  • Active el Attribute Spooling para todos los trabajos (predeterminado para la versión 7.0 en adelante).
  • Use la inserción por lotes en la base de datos (generalmente es estándar, se define en la compilación y debe ser respaldada por la base de datos).

Catalog (database)

a) PostgreSQL

  • Evite la creación de índices adicionales.
  • Use configuraciones especiales para 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

  • Realizando un vacuumdb periódico en la base de datos (postgreSQL), con el paso del tiempo el gran cambio de registros acaba haciendo que la inserción en la base de datos consuma más tiempo. [1]

[1] Sugerencia de Edmar Araújo. Referencias: 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

  • Utilice configuraciones especiales para MySQL:

sort_buffer_size = 2MB
innodb_buffer_pool_size = 128MB

innodb_flush_log_at_trx_commit = 0

innodb_flush_method = O_DIRECT

De forma predeterminada, innodb_flush_log_at_trx_commit sería 1, lo que significa que el registro de transacciones se almacena en el disco en cada confirmación en el banco y las transacciones no se perderán en caso de una falla del sistema operativo. Dado que Bacula utiliza muchas transacciones pequeñas, puede reducir la E/S de registro y aumentar el rendimiento de la copia de seguridad exponencialmente configurándolo en 0, lo que significa que no habrá almacenamiento de registro para cada transacción. Como en caso de interrupción del trabajo sería necesario reiniciar el trabajo de respaldo de cualquier forma, por lo que es una opción muy interesante.

  • Ejecute mysqltuner (apt-get install mysql tuner) e implemente los cambios sugeridos.

Red (SD y FD)

  • Agregue más interfaces (bonding / NIC Teaming) y conmutadores más rápidos (puede usar el comando de red de estado de Bacula o la aplicación ethtool para verificar la velocidad de su conexión ethernet).
  • Establezca el Network Buffer Size = bytes, que especifica el tamaño inicial del búfer de red. Este tamaño se ajusta a la baja si el sistema operativo operativo no lo acepta, a costa de muchas llamadas al sistema (no deseadas). El valor predeterminado es 32,768 bytes. Se eligió el estándar para que sea lo suficientemente amplio para la transmisión a través de Internet, pero en una red local se puede aumentar para mejorar el rendimiento. Algunos usuarios han notado una mejora de 10 veces en la transferencia de datos usando 65,536 bytes en este valor.
  • Evite el tráfico a través de firewalls y enrutadores.
  • Utilice Jumbo Frames.
  • Personaliza el Kernel (Ref.: Https://fasterdata.es.net/host-tuning/linux/). Ejemplo:
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 Operativo

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

Disk Access

  • Utilice el sistema de archivos XFS, ya que sobresale en la realización de operaciones de entrada / salida (E/S) en paralelo debido a su diseño, que se basa en grupos de asignación (un tipo de subdivisión de los volúmenes físicos en los que se utiliza XFS, abreviado para AG) . Debido a esto, XFS permite una escalabilidad extrema de los subprocesos de E/S, el ancho de banda del sistema de archivos y el tamaño de los archivos y el sistema de archivos en sí, mientras abarca múltiples dispositivos de almacenamiento físico.
  • Utilice el “deadline disk schedulere”.
  • Utilice RAID con un buen controlador de batería (por ejemplo, ARECA).

 

Leave a Reply

Tuning: Better Backup Performance and Bottlenecks Treatment

Tuning: Better Backup Performance and Bottlenecks Treatment

Bacula

  • Some companies use Antivirus for Windows and Even for Linux. Put Bacula’s Daemons as exceptions.
  • Split FileSet in two when backing up more than 20 million files.

Windows file systems especially do not handle volumes with gigantic amounts of small files well. In this case, the ideal is to create multiple FileSets and Jobs (ex .: one for each Volume or some directories), in order to parallelize the copy operations. For example, a server with C: and E: volumes.

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

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

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

Using alldrives is important for backing up all other drives except C:, which is already backed up by Job1. If someone creates a new Volume on this server, Job2 will automatically back up.

Job3 would be for exclusive backup of Windows System State (if you want to separate too). Vss: is an exclusive plugin for Enterprise, but it is also possible to use scripts to generate Windows System State in a separate volume.

In some graphical interfaces (such as Bweb), it is possible to group Jobs from the same client for better management and statistics.

  • Decrease the GZIP compression level (if enabled – always less than 6) or use LZO. Do not use compression via Bacula software for tapes.
  • Run multiple simultaneous backup jobs (Maximum Concurrent Jobs).

Be sure to enable competition in the 4 places:

a) Director resource in bacula-dir.conf

b) Storage feature in bacula-dir.conf

c) Storage feature in bacula-sd.conf

d) Device stanza in bacula-sd.conf resource

  • Back up to multiple disks, tapes or different storages daemons simultaneously.
  • Tapes: Enable SSD / NVME Disk Spooling. Traditional HD discs can be slower than tapes.
  • Tapes: Increase the Minimum (eg 256K) and Maximum Block Size to 256K to 512K (* for LTO4. 1M too large and can cause problems. Specified in: bacula-sd.conf, Device feature). It is necessary to recreate all volumes with the new maximum block size, otherwise Bacula will not be able to read the previous ones.
  • Tapes: Increase the Maximum File Size to 10GB to 20GB (Specified in: bacula-sd.conf, Device feature).
  • Disable AutoPrunning for Clients and Jobs (Pruning volumes once a day through an Admin Job).
  • Turn on Attribute Spooling for all Jobs (Default for version 7.0 onwards).
  • Use batch insert in the database (it is usually standard, defined in the compilation and needs to be supported by the database).

Catalog (database)

a) PostgreSQL

  • Avoid creating additional indexes.
  • Use special settings for 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

  • Performing a periodic vacuumdb in the database (postgreSQL), with the passage of time the major change of records ends up making insertion in the database more time consuming. [1]

[1] Tip from Edmar Araújo. References: 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

  • Use special configurations for MySQL:

sort_buffer_size = 2MB
innodb_buffer_pool_size = 128MB

innodb_flush_log_at_trx_commit = 0

innodb_flush_method = O_DIRECT

By default, innodb_flush_log_at_trx_commit would be 1, meaning that the transaction log is stored on disk at each commit in the bank and transactions would not be lost in the event of an operating system crash. Since Bacula uses many small transactions, you can reduce log I/O and increase backup performance exponentially by setting it to 0, meaning that there will be no log storage for each transaction. As in case of job interruption it would be necessary to restart the backup job in any way, so it is a very interesting option.

  • Run mysqltuner (apt-get install mysql tuner) and implement the suggested changes.

Network (SD and FD)

  • Add more interfaces (bonding / NIC Teaming) and faster switches (you can use the Bacula status network command or the ethtool application to check the speed of your ethernet connection).
  • Set the Maximum Network Buffer Size = bytes, which specifies the initial size of the network buffer. This size is adjusted downward if the operating OS does not accept it, at the cost of many system calls (unwanted). The default value is 32,768 bytes. The standard was chosen to be wide enough for transmission over the internet, but on a local network it can be increased to improve performance. Some users have noticed a 10-fold improvement in data transfer using 65,536 bytes in this value.
  • Avoid traffic through firewalls and routers.
  • Use Jumbo Frames.
  • Customize the Kernel (Ref .: https://fasterdata.es.net/host-tuning/linux/). Example:
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

Operating System

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

Disk Access

  • Use the XFS file system as it excels in performing parallel input / output (I/O) operations due to its design, which is based on allocation groups (a type of subdivision of the physical volumes on which XFS is used, shortened for AGs). Because of this, XFS allows for extreme scalability of I/O threads, bandwidth of the file system and size of the files and the file system itself, while spanning multiple physical storage devices.
  • Use the “deadline disk scheduler”.
  • Use RAID with a good battery controller (eg ARECA).

 

This Post Has One Comment

Leave a Reply