Fondo
Tengo un servidor que aloja máquinas virtuales y un NAS Synology DS1512+ antiguo utilizado como destino de copia de seguridad para esas máquinas virtuales. El servidor utiliza ZFS, crea instantáneas y transfiere los archivos de las instantáneas al NAS. El NAS utiliza BTRFS con compresión habilitada y también admite instantáneas. El objetivo final sería que el servidor realmente solo envíe DELTA usando RSYNC para minimizar la cantidad de datos modificados recibidos por el NAS y también hacer un uso eficiente de las instantáneas.
Problema
Sin embargo, usar RSYNC con DELTA no funciona en mi caso, porque transferir los datos simplemente requieredemasiado tiempo. Cuando se utiliza RSYNC con --inplace --whole-file, los datos tardan aproximadamente 2 horas en transferirse. Al eliminar --whole-filepara utilizar DELTA, el mismo proceso de copia de seguridad lleva mucho más tiempo; a menudo finalizo el proceso después de ejecutar más de 12 horas. Por razones históricas, necesito incluir diferentes copias de seguridad en períodos de tiempo mucho más pequeños.
El único cuello de botella que tiene sentido es el NAS, porque el servidor es mucho más potente y está inactivo la mayor parte del tiempo. El NAS OTOH tiene una carga bastante alta en CPU y E/S durante la copia de seguridad. Sin embargo, los números tampoco son tan malos, solo que son peores que cuando se usa --whole-file. Con eso, el NAS prácticamente simplemente escribe ~100+ MiB/s, mientras que con los DELTA lee más lento la mayor parte del tiempo, abarcando entre ~50 y 100 MiB/s. Pensé que la cantidad de datos que NO se debían escribir debido a los DELTA superaría fácilmente el hecho del NAS más lento, pero ese no parece ser el caso. Y la cantidad modificada de datos en las máquinas virtuales no es demasiado alta en su mayoría.
Observación
Lo que reconocí en el NAS fue que RSYNC parece procesar dos archivos al mismo tiempo en algún momento. Esto parece una lectura anticipada o similar:
root@amds1512-01:~# lsof | grep [d]asi_
rsync 6883 root cwd DIR 0,33 290 259 /volume1/[...]
rsync 6883 root 0r REG 0,33 2142633984 580 /volume1/[...]/[...]-s024.vmdk
rsync 6884 root cwd DIR 0,33 290 259 /volume1/[...]
rsync 6884 root 1r REG 0,33 2143748096 579 /volume1/[...]/[...]-s023.vmdk
rsync 6884 root 3w REG 0,33 2143748096 579 /volume1/[...]/[...]-s023.vmdk
HTOP muestra claramente que ambas instancias de RSYNC se leen. Simplemente ignore los otros procesos RSYNC, no están relacionados y el problema persiste incluso cuando se ejecuta una copia de seguridad exclusivamente.
Preguntas
Entonces, ¿cuál es el propósito de que esos dos ejecuten RSYNC con archivos diferentes en el destino de la copia de seguridad? ¿Hay alguna forma de decirle a RSYNC que solo procese un archivo tras otro?
Eso podría aumentar el tiempo total de procesamiento con menos carga simultánea. No pude encontrar nada parecido a lectura anticipada o similar en la página de manual. Si hay alguna diferencia, las siguientes son las opciones utilizadas:
--owner \
--numeric-ids \
--compress-level=0 \
--group \
--perms \
--rsh=rsh \
--devices \
--hard-links \
--inplace \
--links \
--recursive \
--times \
--delete \
--delete-during \
--delete-excluded \
--rsync-path=[...] \
--specials
¡Gracias!
Respuesta1
Echa un vistazo aCómo funciona Rsync. Específicamente, hay un proceso generador y un proceso remitente que operan como una canalización. El remitente lee el archivo para enviarlo al control remoto. El generador es responsable de generar la lista de archivos para enviar, y también "las sumas de verificación en bloque se crean para el archivo base y se envían al remitente inmediatamente después del número de índice del archivo".
Definitivamente, esto parece que tiene el potencial de causar daños en el sistema de archivos si lo utiliza --inplacepara enviar varios archivos grandes.y no tengo suficiente RAM disponible para que el kernel almacene dos archivos consecutivos en caché.
Como prueba, puedes intentar transferir archivos individuales rsync --inpacey ver si el rendimiento es significativamente mejor. (Algo como for i in *.vmdk; do rsync [...]; done...) Eso debería ayudar a determinar si tener dos lectores separados realmente está causando el problema de rendimiento.
Si varios lectoresescausando el problema de rendimiento, entonces una posible ruta sería mejorar la capacidad del kernel para almacenar en caché las lecturas, ya sea haciendo que haya más RAM disponible para el kernel host o reduciendo el tamaño de los archivos vmdk individuales.
Desafortunadamente, no veo ninguna forma obvia de cambiar el comportamiento de la canalización del generador/remitente en rsync, salvo escribir su propio script para llamar a rsync una vez para cada archivo. Quizás quieras preguntar sobre esto en ellista de correo rsync.