Le meilleur moyen de copier des millions de fichiers entre 2 serveurs
J'ai environ 5 millions de petits fichiers (5-30k) dans un seul répertoire que je voudrais copier sur une autre machine sur le même réseau gigabit. J'ai essayé d'utiliser rsync, mais cela ralentirait au bout de quelques heures, je suppose en raison du fait que rsync doit vérifier le fichier source et le fichier de destination à chaque fois.
Ma deuxième pensée serait d’utiliser scp, mais je voulais obtenir un avis extérieur pour voir s’il existait un meilleur moyen. Merci!
Quelque chose comme ça devrait bien fonctionner:
tar c some/dir | gzip - | ssh Host2 tar xz
Peut-être aussi omettre gzip et l'indicateur "z" pour l'extraction, puisque vous êtes sur un réseau gigabit.
Je suis sûr que le fait que vous ayez tous les CINQ MILLIONS de fichiers dans un seul répertoire va jeter de nombreux outils dans tous leurs états. Je ne suis pas surpris que rsync n'ait pas géré cela avec grâce - c'est une situation assez "unique". Si vous pouviez trouver un moyen de structurer les fichiers en une sorte de structure de répertoire, je suis sûr que les outils de synchronisation standard tels que rsync seraient beaucoup plus réactifs.
Toutefois, pour vous donner un conseil concret, une solution consisterait peut-être à déplacer temporairement le lecteur physiquement dans la machine de destination afin de pouvoir effectuer une copie des fichiers sur le serveur lui-même (et non sur le réseau). Ensuite, déplacez le lecteur vers l'arrière et utilisez rsync pour maintenir les éléments à jour.
Pour copier des millions de fichiers sur un commutateur gigabit (dans un environnement sécurisé), vous pouvez également utiliser une combinaison de netcat (or nc) et tar, comme l'a déjà suggéré l'utilisateur55286. Cela diffusera tous les fichiers en un seul fichier volumineux (voir Copie rapide de fichiers - Linux! (39 Go) ).
# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf - # destination box
tar -cz /source/dir | nc Target_Box 2342 # source box
Nous avions environ 1 million de fichiers dans un répertoire (environ 4 ans).
Et nous avons utilisé robocopy pour déplacer les fichiers dans le répertoire AAAA/MM (environ 35 à 45 000 fichiers par mois). Nous avons mis le script robocopy dans un fichier .bat comme celui-ci:
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02
notes succinctes .. /ns /nc /nfl /np permet d'éviter de gonfler le fichier journal avec des informations supplémentaires. /log+... permet d'écrire des informations récapitulatives dans le fichier journal.
/minage and /maxage is to copy files modified with in that date range.
ainsi, par exemple, les fichiers modifiés> = 01/Nov/2008 (inclus) en fichiers modifiés <01/Dec/2008 (non inclus)
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
/mov pour déplacer les fichiers
puis vient le répertoire source
vient ensuite le répertoire de destination (les répertoires seront créés à la volée au fur et à mesure des besoins).
Cela a pris environ 40 à 60 minutes pour un mois de transfert (environ 35 à 45 000 fichiers). Nous estimons que cela prend environ 12 heures ou moins pour un an de transfert.
Utilisation de Windows Server 2003.
Tous les éléments sont enregistrés dans le fichier journal ... Heure de début, Heure de fin et Nombre de fichiers copiés.
Robocopy a sauvé la journée.
Je préfère utiliser lz4 comme outil de compression le plus rapide pour le moment. Option SSH -c arcfour128 utilise un algorithme de cryptage plus rapide que celui par défaut. [1]
Donc, le transfert de répertoire ressemble à quelque chose comme:
tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'
Veuillez noter que sur Debian, la commande lz4 est lz4c et sur CentOS, elle est lz4.
Vous savez, j'ai ajouté la solution tar à une solution, mais - en fonction de l'environnement - une autre idée se présente. Vous pourriez penser à utiliser dd (1) . Le problème de vitesse avec quelque chose comme ceci est qu'il faut beaucoup de mouvements de tête pour ouvrir et fermer un fichier, ce que vous ferez cinq millions de fois. Afin de vous assurer que ceux-ci sont assignés de manière contiguë, vous pouvez les dd les remplacer, ce qui réduirait le nombre de mouvements de la tête par un facteur de 5 ou plus.
Robocopy est idéal pour des choses comme celle-ci. Il essaiera de nouveau après les délais d'attente du réseau et vous permettra également de définir un délai d'intervalle entre paquets pour submerger le canal.
[Modifier]
Notez qu'il s'agit d'une application uniquement Windows.
Je sais que c'est peut-être stupide - mais avez-vous déjà pensé à les copier sur un disque externe et à les transférer sur l'autre serveur? C'est peut-être la solution la plus efficace et la plus simple.
Nous étudions actuellement ce problème. Nous devons transférer environ 18 millions de petits fichiers - environ 200 Go au total. Nous avons obtenu les meilleures performances avec XCopy, mais cela a quand même pris beaucoup de temps. Environ 3 jours d'un serveur à l'autre, environ 2 semaines sur un lecteur externe!
Par un autre processus, nous devions dupliquer le serveur. Cela a été fait avec Acronis. Cela a pris environ 3 heures !!!
Nous étudierons cela un peu plus. La suggestion dd ci-dessus donnerait probablement des résultats similaires.
Déjà des tonnes de bonnes suggestions, mais je voulais ajouter Au-delà de la comparaison . J'ai récemment transféré environ 750 000 fichiers entre 5 Ko et 20 Mo d'un serveur à un autre via un commutateur gigabit. Il n'a même pas eu le moindre hoquet. Certes, cela a pris du temps, mais je m'y attendais avec autant de données.
Contourner le système de fichiers.
Pouvez-vous démonter cette partition sur laquelle les fichiers sont stockés ou la monter en lecture seule? Faites cela, alors quelque chose comme:
dd if=/dev/PARTITION | ssh username@Host "dd of=diskimage.bin"
Vous pouvez ensuite monter diskimage.bin en tant que périphérique de bouclage du côté destination et en copier des fichiers dans votre système de fichiers de destination réel, ou peut-être utiliser les outils appropriés pour le réassembler dans une partition vide du côté destination (dangereux, mais probablement dangereux). possible, même si je ne l’ai jamais fait.)
Si vous êtes vraiment courageux, vous pouvez dd directement dans une partition du côté de la destination. Je ne recommande pas ça.
Je verrais comment un Zip-> copier-> décompresser fonctionne
ou quel que soit votre système de compression/archive préféré.
Rangez-les dans un seul fichier avant de le copier, puis décompressez-les une fois copié.
Dans une situation similaire, j'ai essayé d'utiliser tar pour regrouper les fichiers. J'ai écrit un petit script pour canaliser la sortie de la commande tar vers la machine cible directement vers un processus tar récepteur qui dégroupait les fichiers.
L’approche tar a presque doublé le taux de transfert par rapport à scp ou rsync (YMMV).
Voici les commandes tar. Notez que vous devez activer les commandes r en créant des fichiers .rhosts dans les répertoires de base de chaque ordinateur (supprimez-les une fois leur copie terminée. Ce sont des problèmes de sécurité notoires). Notez également que, comme d’habitude, HP-UX est délicat - alors que le reste du monde utilise "rsh" pour la commande remote-Shell, HP-UX utilise "remsh". "Rsh" est une sorte de Shell restreint dans le jargon de HP.
box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "
La première commande tar crée un fichier appelé "-", qui est un jeton spécial signifiant "sortie standard" dans ce cas. L'archive créée contient tous les fichiers du répertoire actuel (.) Ainsi que tous les sous-répertoires (tar est récursif par défaut). Ce fichier d'archive est dirigé vers la commande remsh qui l'envoie à la machine box2. Sur la case 2, je commence par passer au répertoire de réception approprié, puis j’extrais de ‘-’, ou ‘entrée standard’, les fichiers entrants.
J'avais 6 commandes tar en cours d'exécution simultanément pour m'assurer que le lien réseau était saturé de données, bien que je suspecte que l'accès au disque ait pu être le facteur limitant.
Il y a autre chose à considérer. Essaye ça:
- Créer un disque dur virtuel, dimensionné dynamiquement
- Montez-le, éventuellement comme un répertoire
- Définir l'attribut 'compresser tout le disque'
En faisant cela, il n'y a AUCUN surcharge pour l'itération ou la compression du répertoire, car cela a été fait au moment de l'écriture des fichiers. Il n'y a qu'un seul fichier à déplacer - le disque dur virtuel.
Sous Windows, je règle la taille de paquet TCP par défaut plus grande, comme 16348. Cela signifie moins de temps système pour les en-têtes IP.
Une chose que j’ai rencontrée, cependant, est qu’il est préférable de garder une taille de fichier inférieure à 100 Mo pour un transfert réseau ou USB. J'utilise Rar.exe pour cela - pour diviser les fichiers.
Fonctionne comme un champion. C'est l'équivalent de 'dd' sous Linux. Le concept de montage d'un système de fichiers compressé dans un répertoire est également normal pour Linux. La même logique s'applique donc. Vous devez vous assurer que tous les fichiers sont fermés avant le début de l'opération, comme dans les autres méthodes.
Cela présente l’avantage supplémentaire de permettre de définir un quota de taille dans un dossier. Si le disque dur virtuel a une taille fixe, le dépassement de cette limite ne fera pas baisser le serveur, cela provoquera simplement une erreur lors de la création ou de l'écriture du fichier.
Un disque dur virtuel formaté en NTFS peut également gérer des millions de fichiers dans un dossier.
vous pouvez essayer ce qui suit (il peut s'agir de lots de fichiers)
- tar le lot de fichiers
- gzip les
- copier en utilisant scp si possible
- gunzip
- décompresser les fichiers
Comme suggéré par qc, vous pouvez essayer tar over ssh.
Si vous n'avez pas besoin de cryptage (à l'origine, vous utilisiez rsync, mais vous n'avez pas mentionné qu'il s'agissait de rsync + ssh), vous pouvez utiliser tar over netcat pour éviter la surcharge ssh.
Bien sûr, vous pouvez également réduire le temps nécessaire en utilisant gzip ou une autre méthode de compression.