Esta nota continúa
el ciclo sobre copias de seguridad
- Copias de seguridad, parte 2: Revisión y pruebas de herramientas de copia de seguridad basadas en rsync
- Copia de seguridad, parte 3: Revisión y prueba de duplicity, duplicaty, deja dup
- Copia de seguridad, parte 4: Revisión y prueba de zbackup, restic, borgbackup
- Copia de seguridad, parte 5: Prueba de bacula y veeam backup for linux
- Copia de seguridad, parte 6: Comparación de herramientas de copia de seguridad
- Copia de seguridad, parte 7: Conclusiones
Como ya mencionamos en el primer artículo, hay una gran cantidad de programas de copia de seguridad basados en rsync.
De aquellos que se adaptan mejor a nuestras condiciones, consideraré 3: rdiff-backup, rsnapshot y burp.
Conjuntos de archivos de prueba
Los conjuntos de archivos para las pruebas serán los mismos para todos los candidatos, incluidas las futuras artículos.
Primer conjunto: 10 GB de archivos multimedia, y aproximadamente 50 MB — el código fuente del sitio en php, con tamaños de archivo que van desde unos pocos kilobytes para el código fuente, hasta decenas de megabytes para los archivos multimedia. El objetivo es simular un sitio estático.
Segundo conjunto: se obtiene del primero al renombrar el subdirectorio con archivos multimedia de 5 GB. El objetivo es estudiar el comportamiento del sistema de copia de seguridad al renombrar un directorio.
Tercer conjunto: se obtiene del primero eliminando 3 GB de archivos multimedia y añadiendo 3 GB nuevos. El objetivo es estudiar el comportamiento del sistema de copia de seguridad durante una operación típica de actualización del sitio.
Obtención de resultados
Cualquier copia de seguridad se realiza al menos 3 veces y se acompaña de una descarga de cachés del sistema de archivos mediante los comandos sync y echo 3 > /proc/sys/vm/drop_caches tanto en el lado del servidor de prueba como en el servidor de almacenamiento de copias de seguridad.
En el servidor que será la fuente de las copias de seguridad, se ha instalado un software de monitoreo — netdata, con la ayuda del cual se evaluará la carga del servidor durante la copia, lo cual es necesario para evaluar la carga del servidor durante el proceso de copia de seguridad.
También considero que el servidor de almacenamiento de copias de seguridad es más lento en procesamiento que el servidor principal, pero tiene discos de mayor capacidad con una velocidad de escritura aleatoria relativamente baja — la situación más común durante la copia de seguridad, y dado que el servidor de copias de seguridad no debería realizar otras tareas además de copias de seguridad, no haré un seguimiento de su carga con netdata.
Además, he cambiado los servidores en los que probaré diferentes sistemas para copias de seguridad.
Ahora tienen las siguientes característicasProcesador
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (usando system LuaJIT 2.0.4)
Ejecutando la prueba con las siguientes opciones:
Número de hilos: 2
Inicializando el generador de números aleatorios a partir del tiempo actual
Límite de números primos: 20000
Inicializando hilos de trabajo...
¡Hilos iniciados!
Velocidad de CPU:
eventos por segundo: 1081.62
Estadísticas generales:
tiempo total: 30.0013s
número total de eventos: 32453
Latencia (ms):
min: 1.48
avg: 1.85
max: 9.84
percentil 95: 2.07
suma: 59973.40
Equidad de hilos:
eventos (avg/stddev): 16226.5000/57.50
tiempo de ejecución (avg/stddev): 29.9867/0.00
Memoria, lectura…
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 system LuaJIT 2.0.4)
Ejecutando la prueba con las siguientes opciones:
Número de hilos: 4
Inicializando el generador de números aleatorios a partir del tiempo actual
Ejecutando prueba de velocidad de memoria con las siguientes opciones:
tamaño de bloque: 1KiB
tamaño total: 102400MiB
operación: lectura
ámbito: global
Inicializando hilos de trabajo...
¡Hilos iniciados!
Total de operaciones: 104857600 (5837637.63 por segundo)
102400.00 MiB transferidos (5700.82 MiB/sec)
Estadísticas generales:
tiempo total: 17.9540s
número total de eventos: 104857600
Latencia (ms):
min: 0.00
avg: 0.00
max: 66.08
percentil 95: 0.00
suma: 18544.64
Equidad de hilos:
eventos (avg/stddev): 26214400.0000/0.00
tiempo de ejecución (avg/stddev): 4.6362/0.12
… y escritura
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 system LuaJIT 2.0.4)
Ejecutando la prueba con las siguientes opciones:
Número de hilos: 4
Inicializando el generador de números aleatorios a partir del tiempo actual
Ejecutando prueba de velocidad de memoria con las siguientes opciones:
tamaño de bloque: 1KiB
tamaño total: 102400MiB
operación: escritura
ámbito: global
Inicializando hilos de trabajo...
¡Hilos iniciados!
Total de operaciones: 91414596 (3046752.56 por segundo)
89272.07 MiB transferidos (2975.34 MiB/sec)
Estadísticas generales:
tiempo total: 30.0019s
número total de eventos: 91414596
Latencia (ms):
min: 0.00
avg: 0.00
max: 1022.90
percentil 95: 0.00
suma: 66430.91
Equidad de hilos:
eventos (avg/stddev): 22853649.0000/945488.53
tiempo de ejecución (avg/stddev): 16.6077/1.76
Disco en el servidor fuente de datos
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (usando el sistema LuaJIT 2.0.4)
Ejecutando la prueba con las siguientes opciones:
Número de hilos: 4
Inicializando el generador de números aleatorios desde el tiempo actual
Banderas adicionales de apertura de archivos: (ninguna)
128 archivos, 8MiB cada uno
1GiB tamaño total del archivo
Tamaño del bloque 4KiB
Número de solicitudes de I/O: 0
Relación de lectura/escritura para la prueba de I/O aleatorio combinado: 1.50
FSYNC periódico habilitado, llamando a fsync() cada 100 solicitudes.
Llamando a fsync() al final de la prueba, habilitado.
Usando modo de I/O sincrónico
Realizando prueba aleatoria de r/w
Inicializando hilos de trabajo...
¡Hilos iniciados!
Operaciones de archivo:
lecturas/s: 4587.95
escrituras/s: 3058.66
fsyncs/s: 9795.73
Rendimiento:
lectura, MiB/s: 17.92
escrita, MiB/s: 11.95
Estadísticas generales:
tiempo total: 60.0241s
número total de eventos: 1046492
Latencia (ms):
min: 0.00
avg: 0.23
max: 14.45
percentil 95: 0.94
suma: 238629.34
Equidad entre hilos:
eventos (avg/stddev): 261623.0000/1849.14
tiempo de ejecución (avg/stddev): 59.6573/0.00
Disco en el servidor de almacenamiento de copias de seguridad
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (usando el sistema LuaJIT 2.0.4)
Ejecutando la prueba con las siguientes opciones:
Número de hilos: 4
Inicializando el generador de números aleatorios desde el tiempo actual
Banderas adicionales de apertura de archivos: (ninguna)
128 archivos, 8MiB cada uno
1GiB tamaño total del archivo
Tamaño del bloque 4KiB
Número de solicitudes de I/O: 0
Relación de lectura/escritura para la prueba de I/O aleatorio combinado: 1.50
FSYNC periódico habilitado, llamando a fsync() cada 100 solicitudes.
Llamando a fsync() al final de la prueba, habilitado.
Usando modo de I/O sincrónico
Realizando prueba aleatoria de r/w
Inicializando hilos de trabajo...
¡Hilos iniciados!
Operaciones de archivo:
lecturas/s: 11.37
escrituras/s: 7.58
fsyncs/s: 29.99
Rendimiento:
lectura, MiB/s: 0.04
escrita, MiB/s: 0.03
Estadísticas generales:
tiempo total: 73.8868s
número total de eventos: 3104
Latencia (ms):
min: 0.00
avg: 78.57
max: 3840.90
percentil 95: 297.92
suma: 243886.02
Equidad entre hilos:
eventos (avg/stddev): 776.0000/133.26
tiempo de ejecución (avg/stddev): 60.9715/1.59
Velocidad de red entre servidores
iperf3 -c backup
Conectando al host backup, puerto 5201
[ 4] local x.x.x.x puerto 59402 conectado a y.y.y.y puerto 5201
[ ID] Intervalo Transferencia Ancho 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 Transferencia Ancho de banda Retr
[ 4] 0.00-10.00 seg 3.78 GBytes 3.25 Gbits/seg 8100 emisor
[ 4] 0.00-10.00 seg 3.78 GBytes 3.25 Gbits/seg receptor
Método de prueba
- Se está preparando el sistema de archivos en el servidor de prueba con el primer conjunto de pruebas, el repositorio en el servidor de almacenamiento de copias de seguridad se inicializa si es necesario.
Se inicia el proceso de copia de seguridad y se mide su tiempo. - Se realiza la migración de archivos en el servidor de prueba al segundo conjunto de pruebas. Se inicia el proceso de copia de seguridad y se mide su tiempo.
- Se realiza la migración en el servidor de prueba al tercer conjunto de pruebas. Se inicia el proceso de copia de seguridad y se mide su tiempo.
- El tercer conjunto de pruebas obtenido se acepta como el nuevo primero; los puntos 1-3 se repiten otras 2 veces.
- Los datos se registran en una tabla resumen, se añaden gráficos con netdata.
- Se elabora un informe sobre cada método de copia de seguridad.
Resultados esperados
Dado que los 3 candidatos se basan en la misma tecnología (rsync), se espera que los resultados sean similares a los de rsync normal, incluyendo todas sus ventajas, a saber:
- Los archivos en el repositorio se mantendrán 'tal cual'.
- El tamaño del repositorio solo crecerá incluyendo la diferencia entre las copias de seguridad.
- Habrá una carga relativamente alta en la red durante la transferencia de datos, así como una pequeña carga en el procesador.
La prueba de ejecución de rsync normal se aplicará como referencia, sus resultados
son los siguientes
El cuello de botella estaba en el servidor de almacenamiento de copias de seguridad en forma de un disco basado en HDD, lo cual es claramente visible en los gráficos en forma de sierra.
Se copiaron los datos en 4 minutos y 15 segundos.
Prueba de rdiff-backup
El primer candidato es rdiff-backup, un script en python que realiza copias de seguridad de un directorio a otro. La copia de seguridad actual se almacena "tal cual", mientras que las copias de seguridad anteriores se agrupan en un subdirectorio especial de manera incremental, lo que ahorra espacio.
Verificaremos el modo operativo típico, es decir, el proceso de copia de seguridad se inicia por el cliente, mientras que en el servidor se lanza un proceso que recibe los datos para la copia de seguridad.
Veamos de lo que es capaz en nuestras condiciones.
El tiempo de cada ejecución de prueba:
Primera ejecución
Segundo lanzamiento
Tercer lanzamiento
Primer conjunto
16m32s
16m26s
16m19s
Segundo conjunto
2h5m
2h10m
2h8m
Tercer conjunto
2h9m
2h10m
2h10m
Rdiff-backup reacciona muy negativamente a cualquier cambio grande en los datos y no utiliza completamente la red.
Prueba de rsnapshot
El segundo candidato es rsnapshot, un script en perl cuyo principal requisito para un funcionamiento efectivo es el soporte de enlaces duros. Esto ahorra espacio en disco. Además, los archivos que no han cambiado desde la última copia de seguridad se enlazan al archivo original mediante enlaces duros.
También se ha invertido la lógica del proceso de copia de seguridad: el servidor va activamente "a sus clientes" y recoge los datos.
No voy a escribir mucho texto explicativo aquí, solo compartiré los resultados obtenidos. Las pruebas se realizaron en 3 máquinas físicas (12 CPU, 384GB RAM, 15k SAS DISK, 10GBit/s Net), los brokers y zookeeper se desplegaron en lxc.
se obtuvieron los siguientes
Primera ejecución
Segundo lanzamiento
Tercer lanzamiento
Primer conjunto
4m22s
4m19s
4m16s
Segundo conjunto
2m6s
2m10s
2m6s
Tercer conjunto
1m18s
1m10s
1m10s
Funcionó muy, muy rápido, mucho más rápido que rdiff-backup y muy cerca de rsync puro.
Prueba de burp
Otra opción es implementar en C sobre librsync — burp, que tiene una arquitectura cliente-servidor que incluye la autorización de clientes, así como una interfaz web (no incluida en el paquete básico). Otra característica interesante es la copia de seguridad sin derechos de recuperación para los clientes.
Veamosrendimiento.
Primera ejecución
Segundo lanzamiento
Tercer lanzamiento
Primer conjunto
11m21s
11m10s
10m56s
Segundo conjunto
5m37s
5m40s
5m35s
Tercer conjunto
3m33s
3m24s
3m40s
Funcionó dos veces más lento que rsnapshot, sin embargo, también es bastante rápido y definitivamente más rápido que rdiff-backup. Los gráficos son un poco irregulares, la productividad se ve afectada nuevamente por el subsistema de disco del servidor de copia de seguridad, aunque no tanto como en rsnapshot.
Resultados
El tamaño de los repositorios de todos los candidatos era aproximadamente el mismo, es decir, primero un crecimiento hasta 10 GB, luego un crecimiento hasta 15 GB, luego hasta 18 GB, etc., lo cual está relacionado con las características de funcionamiento de rsync. También es importante señalar que todos los candidatos eran de un solo hilo (carga en el procesador de aproximadamente el 50% en una máquina de dos núcleos). Los 3 candidatos ofrecían la posibilidad de restaurar la última copia de seguridad "tal cual", es decir, se podía restaurar archivos sin el uso de ningún programa externo, incluyendo aquellos que se utilizaron para crear los repositorios. Esto también es una "herencia genética" de rsync.
Conclusiones
Cuanto más compleja sea la sistema de copias de seguridad y cuantas más funciones tenga, más lenta será su funcionamiento, pero para proyectos que no son demasiado exigentes, cualquiera de ellas servirá, excepto quizás rdiff-backup.
Anuncio
Esta nota continúa el ciclo sobre copias de seguridad
Copia de seguridad, parte 2: Revisión y pruebas de herramientas de copia de seguridad basadas en rsync
Copia de seguridad, parte 3: Revisión y prueba de duplicity, duplicaty, deja dup
Copia de seguridad, parte 4: Revisión y prueba de zbackup, restic, borgbackup
Copia de seguridad, parte 5: Prueba de bacula y veeam backup for linux
Copia de seguridad, parte 6: Comparación de herramientas de copia de seguridad
Copia de seguridad, parte 7: Conclusiones
Autor de la publicación: Pavel Demkovich
Fuente: habr.com
