Synchronisation de structures de dossiers très volumineuses

14

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?

MightyE
la source
Avez-vous essayé de répartir le travail sur plusieurs instances de rsync exécutées en même temps? Je n'ai pas vraiment une bonne image de la structure du répertoire mais vous pouvez le diviser par nom de répertoire ou nom de fichier.
Embrayage
Nous y avions pensé, mais avec une structure aussi plate, il est difficile de trouver de bonnes lignes de séparation sur lesquelles répartir le travail. C'est compliqué par le fait que les dossiers sont pour la plupart très similaires (il existe une convention de dénomination qui fait que la plupart des dossiers commencent par le même ensemble initial de 6 caractères).
MightyE
Avez-vous déjà trouvé une bonne solution, Dave? J'envisage lsyncd pour un répertoire avec 65535 sous-répertoires, chacun pouvant avoir 65 ^ 16 fichiers.
Mike Diehn
1
@MikeDiehn Je n'ai jamais trouvé d'outil dont j'étais totalement satisfait ici. Nous avons obtenu cet outil propriétaire RepliWeb pour corriger le bogue où ils voyaient les fichiers comme des suppressions qui n'étaient pas, c'était une structure interne débordée. J'ai quitté ce poste il y a des années, je suppose qu'ils l'utilisent toujours. Pour vos besoins, si vos répertoires sont distribués de manière raisonnable, vous pouvez opter pour quelque chose comme la solution de Ryan. Il ne remarquera pas les suppressions de niveau supérieur, mais 65535 sous-répertoires me suggèrent que vous ne les avez probablement pas.
MightyE

Réponses:

9

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.

Ryan B. Lynch
la source
C'est une solution extrêmement intelligente! Je pense que tu veux dire touch $next_ref_fileà la fin? Cela nous laisse cependant sans la capacité de faire face aux chemins supprimés (même ces rapports d'archivage statiques deviennent finalement assez vieux pour être archivés et supprimés). Ce n'est peut-être pas un bouchon d'exposition.
MightyE
Je trouve cependant que même juste find . -ctime 0est assez lent sur cette structure de répertoires (toujours en attente de terminer pour signaler son heure). En fait, cela me décourage un peu, car il semble que cela puisse être une opération de bas niveau qui place probablement la barre pour le plus rapide auquel nous pourrions nous attendre. Il se peut que les E / S disque soient ici le facteur limitant.
MightyE
Quant à ce scriptlet, oui, j'ai fait une erreur. Je voulais dire exécuter 'touch' sur 'next_ref_file' (PAS 'curr_ref_file') juste avant d'exécuter le 'find ... | commande rsync ... '. (Je vais corriger ma réponse.)
Ryan B. Lynch
3
Quant à la commande lente «find»: quel type de système de fichiers utilisez-vous? Si vous utilisez Ext3, vous voudrez peut-être envisager deux réglages FS: 1) Exécutez 'tune2fs -O dir_index <DEVICE_NODE>' pour activer la fonction 'dir_index' d'Ext3, afin d'accélérer l'accès aux répertoires avec un grand nombre de fichiers. 2) Exécutez 'mount -o remount, noatime, nodiratime' pour désactiver les mises à jour du temps d'accès, ce qui accélère généralement la lecture. 'dumpe2fs -h <DEVICE_NODE> | grep dir_index 'vous indique si' dir_index 'est déjà activé (sur certaines distributions, c'est la valeur par défaut), et' mount | grep <DEVICE_NODE> 'vous informe sur les mises à jour du temps d'accès.
Ryan B. Lynch, le
Malheureusement, c'est NTFS - Windows 2003 Server utilisant Cygwin pour la commande find. Je me souviendrai de ces options de réglage (excellents conseils) pour ext3 au cas où nous rencontrerions quelque chose de similaire sur l'un de nos clusters Debian.
MightyE
7

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.

Dave Cheney
la source
J'essaye Unison. Cela fonctionne depuis environ 2 heures maintenant sur l'étape "Recherche de changements", et sur la base des fichiers sur lesquels il travaille actuellement, il semble que ce soit à mi-chemin (donc peut-être 4 heures au total avant le début du transfert). Il semble que ce sera mieux que rsync, mais toujours en dehors de la fenêtre opérationnelle souhaitée.
MightyE
2
La première fois que vous créez un index des deux côtés, les temps de reconstruction sont similaires à rsync car il doit hacher chaque fichier. Une fois cela fait, unison utilise la dernière heure modifiée du répertoire pour identifier quand un fichier a changé, et n'a qu'à analyser ce fichier pour les changements.
Dave Cheney
Malheureusement, j'ai été victime d'un administrateur des opérations trop zélé qui a forcé la fin de ma session avant la création du catalogue (nous limitons le nombre de connexions simultanées aux serveurs de production). J'ai perdu les progrès réalisés dans la construction du catalogue initial, je dois donc recommencer. Je vous ferai savoir comment ça se passe.
MightyE
Cela prend environ 2 heures maintenant que le catalogue initial est construit pour analyser les modifications. Je suis assez surpris de la quantité de RAM que Unison utilise pour cela. Pour notre collection de fichiers, le serveur source utilise 635M et le client distant utilise 366M. Synchroniser plusieurs machines dans un cluster serait une empreinte assez lourde, en particulier pour le serveur source!
MightyE
1
Êtes-vous en mesure de structurer vos données d'une manière qui facilite l'identification des données modifiées récemment? C'est-à-dire, le stocker au format année / mois / jour / ...?
Dave Cheney
2

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.

Chris Thorpe
la source
Nous avons essayé avec et sans le drapeau -z. Cela ne semble pas avoir eu d'impact sur la durée d'exécution de la "liste des fichiers de construction".
MightyE
2

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.

ryand32
la source