Synchronisation de structures de dossiers très volumineuses

Nous avons une structure de dossiers sur notre intranet qui contient environ 800 000 fichiers divisés en environ 4 000 dossiers. Nous devons synchroniser cela avec un petit cluster de machines dans nos DMZ. La profondeur de la structure est très peu profonde (elle ne dépasse jamais deux niveaux de profondeur).

La plupart des fichiers ne changent jamais, il y a chaque jour quelques milliers de fichiers mis à jour et 1 à 2 000 nouveaux fichiers. Les données sont des données de rapport historiques conservées là où les données source ont été purgées (c'est-à-dire qu'il s'agit de rapports finalisés pour lesquels les données source sont suffisamment anciennes pour être archivées et supprimées). La synchronisation une fois par jour est suffisante étant donné qu'elle peut se produire dans un délai raisonnable. Les rapports sont générés du jour au lendemain et nous synchronisons dès le matin en tant que tâche planifiée.

De toute évidence, si peu de fichiers changent régulièrement, nous pouvons grandement bénéficier de la copie incrémentielle. Nous avons essayé Rsync, mais cela peut prendre jusqu'à huit à douze heures juste pour terminer l'opération de "création de la liste des fichiers". Il est clair que nous dépassons rapidement les capacités de rsync (le délai de 12 heures est beaucoup trop long).

Nous utilisions un autre outil appelé RepliWeb pour synchroniser les structures, et il peut effectuer un transfert incrémentiel en 45 minutes environ. Cependant, il semble que nous ayons dépassé sa limite, il a commencé à voir des fichiers apparaître comme des suppressions quand ils ne le sont pas (peut-être qu'une structure de mémoire interne a été épuisée, nous ne sommes pas sûrs).

Quelqu'un d'autre a-t-il rencontré un projet de synchronisation à grande échelle de ce type? Existe-t-il quelque chose conçu pour gérer des structures de fichiers massives comme celle-ci pour la synchronisation?

Si vous pouvez faire confiance aux derniers horodatages du système de fichiers, vous pouvez accélérer les choses en combinant Rsync avec l'utilitaire de recherche UNIX / Linux. 'find' peut assembler une liste de tous les fichiers qui affichent les heures de dernière modification au cours de la dernière journée, puis diriger UNIQUEMENT cette liste raccourcie de fichiers / répertoires vers Rsync. C'est beaucoup plus rapide que de demander à Rsync de comparer les métadonnées de chaque fichier de l'expéditeur avec le serveur distant.

En bref, la commande suivante exécutera Rsync UNIQUEMENT sur la liste des fichiers et répertoires qui ont changé au cours des dernières 24 heures: (Rsync ne prendra PAS la peine de vérifier les autres fichiers / répertoires.)

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

Dans le cas où vous n'êtes pas familier avec la commande 'find', elle revient par le biais d'un sous-arbre de répertoire spécifique, à la recherche de fichiers et / ou de répertoires qui répondent aux critères que vous spécifiez. Par exemple, cette commande:

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

commencera dans le répertoire courant (".") et recursera dans tous les sous-répertoires, en recherchant:

• tous les répertoires ("-type d"),
• nommé ".svn" ("-name '.svn'"),
• avec des métadonnées modifiées au cours des dernières 24 heures ("-ctime -0").

Il imprime le nom de chemin complet ("-print") de tout ce qui correspond à ces critères sur la sortie standard. Les options '-name', '-type' et '-ctime' sont appelées "tests", et l'option '-print' est appelée "action". La page de manuel de 'find' contient une liste complète de tests et d'actions.

Si vous voulez être vraiment intelligent, vous pouvez utiliser le test «-cnewer» de la commande «find» au lieu de «-ctime» pour rendre ce processus plus tolérant aux pannes et plus flexible. '-cnewer' teste si chaque fichier / répertoire de l'arborescence a vu ses métadonnées modifiées plus récemment que certains fichiers de référence. Utilisez «touch» pour créer le fichier de référence de l'analyse NEXT au début de chaque analyse, juste avant «find ... | La commande rsync ... 's'exécute. Voici l'implémentation de base:

#!/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

Ce script sait automatiquement quand il a été exécuté pour la dernière fois et il transfère uniquement les fichiers modifiés depuis la dernière exécution. Bien que cela soit plus compliqué, il vous protège contre les situations où vous pourriez avoir manqué l'exécution du travail pendant plus de 24 heures, en raison d'un temps d'arrêt ou d'une autre erreur.

Essayez à l' unisson , il a été spécialement conçu pour résoudre ce problème en conservant les listes de modifications (liste des fichiers de construction), localement sur chaque serveur, en accélérant le temps de calcul du delta et en réduisant la quantité envoyée sur le câble par la suite.

http://oss.linbit.com/csync2/ est conçu pour ce genre de chose, j'essaierais.

Si vous utilisez le commutateur -z sur rsync, essayez de l'exécuter sans lui. Pour une raison quelconque, j'ai vu cela accélérer même l'énumération initiale des fichiers.

La suppression de -z de la commande rsync, qui n'est pas une compression, a rendu la "liste des fichiers reçus" beaucoup plus rapide et nous avons dû transférer environ 500 Go. Avant cela prenait une journée avec le commutateur -z.