Sincronizar estructuras de carpetas muy grandes

Tenemos una estructura de carpetas en nuestra intranet que contiene alrededor de 800,000 archivos divididos en alrededor de 4,000 carpetas. Necesitamos sincronizar esto con un pequeño grupo de máquinas en nuestras DMZ. La profundidad de la estructura es muy superficial (nunca excede los dos niveles de profundidad).

La mayoría de los archivos nunca cambian, cada día hay unos pocos miles de archivos actualizados y 1-2 mil archivos nuevos. Los datos son datos de informes históricos que se mantienen donde se han purgado los datos de origen (es decir, estos son informes finalizados para los cuales los datos de origen son lo suficientemente antiguos como para archivarlos y eliminarlos). Sincronizar una vez al día es suficiente dado que puede suceder en un plazo razonable. Los informes se generan durante la noche y sincronizamos a primera hora de la mañana como una tarea programada.

Obviamente, dado que muy pocos de los archivos cambian regularmente, podemos beneficiarnos enormemente de la copia incremental. Hemos probado Rsync, pero eso puede llevar entre ocho y doce horas solo para completar la operación de "lista de archivos de construcción". Está claro que estamos superando rápidamente lo que rsync es capaz de hacer (el período de tiempo de 12 horas es demasiado largo).

Habíamos estado usando otra herramienta llamada RepliWeb para sincronizar las estructuras, y puede hacer una transferencia incremental en aproximadamente 45 minutos. Sin embargo, parece que hemos excedido su límite, ha comenzado a ver que los archivos se muestran como eliminaciones cuando no lo están (tal vez se haya agotado parte de la estructura de la memoria interna, no estamos seguros).

¿Alguien más se ha encontrado con un proyecto de sincronización a gran escala de este tipo? ¿Hay algo diseñado para manejar estructuras de archivos masivas como esta para la sincronización?

Si puede confiar en las marcas de tiempo modificadas por última vez en el sistema de archivos, puede acelerar las cosas combinando Rsync con la utilidad UNIX / Linux 'find'. 'find' puede armar una lista de todos los archivos que muestran los últimos tiempos modificados en el último día, y luego canalizar SOLAMENTE esa lista abreviada de archivos / directorios a Rsync. Esto es mucho más rápido que hacer que Rsync compare los metadatos de cada archivo en el remitente con el servidor remoto.

En resumen, el siguiente comando ejecutará Rsync SOLAMENTE en la lista de archivos y directorios que han cambiado en las últimas 24 horas: (Rsync NO se molestará en verificar otros archivos / directorios).

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

En caso de que no esté familiarizado con el comando 'buscar', se repite a través de un subárbol de directorio específico, buscando archivos y / o directorios que cumplan con los criterios que especifique. Por ejemplo, este comando:

find . -name '\.svn' -type d -ctime -0 -print

comenzará en el directorio actual (".") y recurrirá a todos los subdirectorios, buscando:

• cualquier directorio ("-tipo d"),
• llamado ".svn" ("-name '.svn'"),
• con metadatos modificados en las últimas 24 horas ("-ctime -0").

Imprime el nombre de ruta completo ("-print") de cualquier cosa que coincida con esos criterios en la salida estándar. Las opciones '-name', '-type' y '-ctime' se llaman "pruebas", y la opción '-print' se llama "acción". La página del manual para 'buscar' tiene una lista completa de pruebas y acciones.

Si quiere ser realmente inteligente, puede usar la prueba '-cnewer' del comando 'find', en lugar de '-ctime' para hacer que este proceso sea más tolerante a fallas y flexible. '-cnewer' prueba si cada archivo / directorio en el árbol ha modificado sus metadatos más recientemente que algún archivo de referencia. Use 'tocar' para crear el archivo de referencia de la ejecución SIGUIENTE al comienzo de cada ejecución, justo antes de 'buscar ... | Se ejecuta el comando rsync ... '. Aquí está la implementación básica:

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

Este script sabe automáticamente cuándo se ejecutó por última vez y solo transfiere archivos modificados desde la última ejecución. Si bien esto es más complicado, lo protege contra situaciones en las que podría haber perdido la ejecución del trabajo durante más de 24 horas, debido al tiempo de inactividad o algún otro error.

Pruebe al unísono , se diseñó específicamente para resolver este problema manteniendo las listas de cambios (lista de archivos de construcción), localmente para cada servidor, acelerando el tiempo para calcular el delta y la cantidad reducida que se envía a través del cable después.

http://oss.linbit.com/csync2/ está diseñado para este tipo de cosas, lo probaría.

Si está utilizando el modificador -z en rsync, intente ejecutarlo sin él. Por alguna razón, he visto que esto acelera incluso la enumeración inicial de archivos.

Al quitar -z del comando rsync, que no es compresión, la "lista de archivos de recepción" se hizo mucho más rápida y tuvimos que transferir unos 500 GB. Antes de que tomara un día con el modificador -z.