Question Comment copier rapidement un grand nombre de fichiers entre deux serveurs


J'ai besoin de transférer une quantité énorme de mp3 entre deux services (Ubuntu). J'entends par énorme environ un million de fichiers qui sont en moyenne 300K. J'ai essayé avec scp mais cela aurait pris environ une semaine. (environ 500 KB / s) Si je transfère un seul fichier par HTTP, j'obtiens 9-10 Mo / s, mais je ne sais pas comment tous les transférer.

Existe-t-il un moyen de les transférer tous rapidement?


81
2018-06-02 19:55


origine


Quel type de réseau avez-vous entre les serveurs? J'ai utilisé un croisement Ethernet GB entre 1 carte réseau sur chaque machine. J'ai très bien mis dans cette configuration en utilisant SCP - Jim Blizard
Vous voudrez peut-être rechercher pourquoi SCP est si lent. C’est peut-être plus lent que des choses comme ftp à cause du cryptage, mais cela ne devrait pas être beaucoup plus lent. - Zoredache
J'ai 100 mbps entre eux. scp est plus lent sur les petits fichiers (la plupart d'entre eux sont petits) - nicudotro


Réponses:


Je recommanderais tar. Lorsque les arborescences de fichiers sont déjà similaires, rsync effectue très bien. Cependant, comme rsync effectue plusieurs analyses sur chaque fichier, puis copie les modifications, le processus est beaucoup plus lent que la version initiale. Cette commande fera probablement ce que vous voulez. Il copiera les fichiers entre les ordinateurs et préservera les autorisations et les droits de propriété des utilisateurs / groupes.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Selon le commentaire de Mackintosh ci-dessous, il s'agit de la commande que vous utiliseriez pour rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

109
2018-06-02 20:04



+1 L'option tar est beaucoup plus efficace pour un grand nombre de petits fichiers, car scp et rsync auront beaucoup plus d'allers et retours par fichier sur le réseau. - Sekenre
rsync a fonctionné mieux pour moi que tar - nicudotro
De même, si vous disposez de beaucoup de CPU (aux deux extrémités), mais (au moins) d'un lien lent entre les hôtes, il peut être intéressant d'activer la compression (gzip ou bzip) dans la commande tar. - Vatine
@Jamie: Si vous utilisez ssh-agent, alors il devrait être utilisé. Sinon, utilisez simplement l'option '-i' pour spécifier où trouver la clé privée. Voir la page de manuel pour plus de détails. - Scott Pack
@niXar Le ~ Le caractère d'échappement n'est activé que si SSH utilise un terminal. Ce n'est pas le cas lorsque vous spécifiez une commande à distance (à moins que vous ne transmettiez la commande -t option). Donc, votre préoccupation est invalide. - Gilles


Disque dur externe et livraison par courrier le jour même.


32
2018-06-02 20:00



Heh heh ... aucune technologie de réseau ne bat la bande passante d'un break chargé de bandes de 90 MPH, hein? (Snicker) J'ai supposé qu'il était sur un réseau local parce qu'il disait qu'il obtenait 9-10 Mo / sec avec HTTP. - Evan Anderson
J'ai ce genre de vitesse sur Internet, mais j'ai de la chance là où je vis! Si c'est sur un réseau local, alors moins cher encore! - Adam
Ahh-- n'a pas regardé votre emplacement. Ouais, j'ai entendu dire que la connectivité Internet en Corée est assez spectaculaire. Coincé ici aux États-Unis, je suis heureux d'avoir 900 Ko / s sur le net ... - Evan Anderson
Oui, mais vous pouvez obtenir de délicieux burritos en attendant que le téléchargement soit terminé et il n'y a que trois restaurants mexicains presque décents même à Séoul ... - Adam


J'utiliserais rsync.

Si vous les avez exportées via HTTP avec des listes de répertoires disponibles, vous pouvez également utiliser wget et l'argument --mirror.

Vous voyez déjà que HTTP est plus rapide que SCP car SCP crypte tout (et donc des goulots d'étranglement sur le processeur). HTTP et rsync vont se déplacer plus rapidement car ils ne chiffrent pas.

Voici quelques documents sur la configuration de rsync sur Ubuntu: https://help.ubuntu.com/community/rsync

Ces documents parlent de la tunnellisation de rsync sur SSH, mais si vous ne déplacez que des données sur un réseau local privé, vous n'avez pas besoin de SSH. (Je suppose que vous êtes sur un réseau local privé. Si vous obtenez 9-10 Mo / s sur Internet, je veux savoir quel type de connexion vous avez!)

Voici quelques autres documents très basiques qui vous permettront de configurer un serveur rsync relatif non sécurisé (sans dépendance à SSH): http://transamrit.net/docs/rsync/


16
2018-06-02 19:57



Bien que SCP utilise en effet du processeur pour chiffrer les données, je ne pense pas qu'il utilise le processeur à 100%, le processeur n'est donc pas un goulot d'étranglement. J'ai trop souvent remarqué que SCP était inefficace en matière de transferts rapides. - Cristian Ciupitu
Étant donné qu'il voyait 300 Ko pour SCP et 9 Mo pour HTTP, j'ai supposé qu'un goulet d'étranglement lié à SCP (normalement le processeur) entrait en jeu. Cela pourrait certainement être autre chose, cependant. Il est difficile de dire si nous ne connaissons pas les spécifications matérielles des machines en question. - Evan Anderson
rsync utilisera presque certainement ssh pour le transport, car il s’agit du comportement par défaut. Ainsi, toute surcharge causée par le chiffrement dans scp sera également présente dans rsync. - Daniel Lawson
"Vous constatez déjà que HTTP est plus rapide que SCP car SCP crypte tout" "WRONG. À moins qu'il n'ait des serveurs âgés de 10 ans, il n'est pas lié au processeur pour cette tâche. - niXar
@RamazanPOLAT - Vous avez une ligne de commande trop longue. Spécifiez la sélection de fichier différemment et cela fonctionnera bien pour vous. En règle générale, vous pouvez simplement spécifier le répertoire source avec un caractère générique à la fin. Vous pouvez également utiliser le --include et --exclude arguments pour obtenir plus de nuances. - Evan Anderson


Sans plus de discussion, utilisez netcat, couteau suisse de réseau. Pas de surcharge de protocole, vous copiez directement sur le socket réseau. Exemple

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

14
2018-06-02 20:17



Malheureusement, netcat est très inefficace, même si cela ne devrait pas être le cas. - Cristian Ciupitu
Je vous vote contre parce que c'est vraiment un très mauvais conseil. Il y a une bonne réponse: rsync. Je pourrais énumérer toutes les raisons pour lesquelles c'est mieux mais cela ne tient pas sur cette page, sans parler de cette petite boîte à commentaires. - niXar
@niXar: Si tout ce que vous voulez faire est un seul transfert de fichier (aucune synchronisation supplémentaire n'est nécessaire), alors tarpipe est tout ce dont vous avez besoin. - Witiko
@niXar netcat convient si vous le faites dans un environnement sécurisé comme vlan privé et / ou sur un réseau privé virtuel. - Lester Cheung


Avec beaucoup de fichiers si vous y allez avec rsync, J'essayerais d'obtenir la version 3 ou plus aux deux extrémités. La raison en est qu'une version moindre énumérera chaque fichier avant qu'il ne commence le transfert. La nouvelle fonctionnalité s'appelle récursion incrémentale.

Un nouvel algorithme de récursion incrémentielle   est maintenant utilisé quand rsync parle         vers une autre version 3.x. Cela commence le transfert plus rapidement         (avant que tous les fichiers aient été trouvés), et nécessite beaucoup moins de mémoire.         Voir l'option --recursive dans la page de manuel pour connaître certaines restrictions.


8
2018-06-02 20:41





rsync, comme d'autres l'ont déjà recommandé. Si l'encombrement de la CPU généré par le cryptage est un goulot d'étranglement, utilisez un autre algorithme moins gourmand en ressources CPU, tel que blowfish. Par exemple. quelque chose comme

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path


7
2018-06-02 20:56



+1 pour le point sur le changement de chiffrement - Daniel Lawson
Le processeur ne sera pas un goulot d'étranglement, à moins que vous n'ayez un Ethernet 10G et un processeur vieux de 10 ans. - niXar
juste commenter: cipher "-c arcfour" est plus rapide. - Arman
@niXar: Mais si vous avez déjà une tâche consommant beaucoup de temps sur votre ordinateur, c'est un problème. - Isaac


Lors de la copie d'un grand nombre de fichiers, j'ai constaté que des outils tels que tar et rsync sont plus inefficaces qu'ils ne devraient l'être en raison de la surcharge liée à l'ouverture et à la fermeture de nombreux fichiers. J'ai écrit un outil open source appelé fast-archiver qui est plus rapide que tar pour ces scénarios: https://github.com/replicon/fast-archiver; cela fonctionne plus rapidement en effectuant plusieurs opérations de fichier simultanées.

Voici un exemple d'archiveur rapide par rapport à tar sur une sauvegarde de plus de deux millions de fichiers; l'archivage rapide prend 27 minutes, contre 1 heure 23 pour le goudron.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Pour transférer des fichiers entre serveurs, vous pouvez utiliser fast-archiver avec ssh, comme ceci:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

4
2017-08-26 20:51





En déplaçant 80 To de données (des millions de fichiers minuscules) hier, passant de rsync à tar  s'est avéré être beaucoup plus rapide, comme nous avons cessé d'essayer

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

et passé à tar au lieu...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Étant donné que ces serveurs se trouvent sur le même réseau local, la destination est montée sur NFS sur le système source, ce qui effectue le transfert. Pas le faire encore plus vite, nous avons décidé de ne pas conserver le atime de fichiers:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

Le graphique ci-dessous illustre la différence entre le passage de rsync à tar. C'était mon le patron idée et mon collègue à la fois exécuté et fait le grand écrire sur son blog. J'aime juste jolies images. :)

rsync_vs_tar


3
2018-04-04 10:32



Un hacker de confiance me dit que "tar over tc au lieu de nfs pourrait même être plus rapide". c'est à dire. tar cf - directory | ttcp -t dest_machine de ftp.arl.mil/mike/ttcp.html - Philip Durbin
Question sans rapport, mais d'où vient ce graphique? - CyberJacob


J'utilise le goudron netcat approche aussi, sauf que je préfère utiliser socat - beaucoup plus de puissance pour optimiser votre situation - par exemple, en peaufinant mss. (Rire aussi si tu veux, mais je trouve socat arguments plus faciles à retenir car ils sont cohérents). Donc, pour moi, c'est très courant ces derniers temps, car j'ai déplacé des choses sur de nouveaux serveurs:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Les alias sont facultatifs.


3
2018-06-03 06:38