J'ai besoin de transférer une énorme quantité de mp3s entre deux serveurs (Ubuntu). Par énorme, j'entends environ un million de fichiers qui font 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 MB/s, mais je ne sais pas comment les transférer tous.
Existe-t-il un moyen de les transférer tous rapidement ?
Je recommande le goudron. Lorsque les arborescences de fichiers sont déjà similaires, rsync effectue muy bien. Cependant, comme rsync effectue plusieurs passages d'analyse sur chaque fichier, puis copie les modifications, il est beaucoup plus lent que tar pour la copie initiale. Cette commande fera probablement ce que vous voulez. Elle copiera les fichiers entre les machines, tout en préservant les permissions et les droits de propriété des utilisateurs et des groupes.
tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'Selon le commentaire de Mackintosh ci-dessous, voici la commande à utiliser pour rsync
rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir
Si vous faites -avW, il ne fait pas le bloc-deltas, il copie juste le fichier entier s'il trouve une différence. C'est plus lent, oui, mais c'est redémarrable.
+1 L'option tar est beaucoup plus efficace pour un grand nombre de petits fichiers car scp et rsync auront beaucoup plus d'allers-retours par fichier sur le réseau.
J'ai vérifié. Le protocole scp nécessite des messages aller-retour pour confirmer chaque transfert de fichier, ce qui va ajouter à la latence par fichier, quelle que soit la largeur de votre bande passante. Je ne sais pas si rsync gère bien ce problème. Réf : blogs.sun.com/janp/entry/how_the_scp_protocol_works
Heh heh... aucune technologie de mise en réseau ne bat la bande passante d'un break chargé de cassettes roulant à 90 MPH, hein ? (ricanement) J'ai supposé qu'il était sur un réseau local car il a dit qu'il obtenait 9-10MB/sec avec HTTP.
J'ai ce genre de vitesse sur internet, mais j'ai juste de la chance là où je vis ! Si c'est sur un réseau local, c'est encore moins cher !
Ahh-- je n'ai pas regardé votre emplacement. Ouais... j'ai entendu dire que la connectivité Internet en Corée est assez spectaculaire. Coincé ici aux USA, je suis heureux d'avoir 900KB/sec sur le net...
Malheureusement, d'après ce que j'ai remarqué, netcat est très inefficace même s'il ne devrait pas l'être.
Je te descends parce que c'est vraiment, vraiment un mauvais conseil. Il n'y a qu'une seule bonne réponse : rsync. Je pourrais énumérer toutes les raisons pour lesquelles il est meilleur, mais cela ne tiendrait pas sur cette page, et encore moins dans cette minuscule boîte de commentaires.
@niXar : Si tout ce que vous voulez faire est un transfert de fichier unique (sans besoin de synchronisation supplémentaire), alors tarpipe est vraiment tout ce dont vous avez besoin.
J'utiliserais rsync.
Si vous les avez exportés via HTTP avec des listes de répertoires disponibles, vous pouvez également utiliser wget et l'argument --mirror.
Vous constatez déjà que HTTP est plus rapide que SCP parce que SCP crypte tout (et engorge donc le CPU). HTTP et rsync vont aller plus vite parce qu'ils ne chiffrent pas.
Voici quelques documents sur la configuration de rsync sur Ubuntu : https://help.ubuntu.com/community/rsync
Ces documents parlent de tunneling rsync sur SSH, mais si vous ne faites que déplacer des données sur un LAN privé, vous n'avez pas besoin de SSH. (Je suppose que vous êtes sur un réseau local privé. Si vous obtenez 9-10MB/sec sur Internet alors je veux savoir quel type de connexions vous avez).
Voici d'autres documents très basiques qui vous permettront de configurer un serveur rsync relativement peu sécurisé (sans dépendance à SSH) : http://transamrit.net/docs/rsync/
Bien que SCP utilise effectivement un peu de CPU pour crypter les données, je ne pense pas qu'il utilise le CPU à 100%, donc le CPU n'est pas un goulot d'étranglement. J'ai aussi remarqué à plusieurs reprises que SCP est inefficace lorsqu'il s'agit de transferts rapides.
Étant donné qu'il voyait 300K pour SCP et 9MB pour HTTP, j'ai supposé qu'un goulot d'étranglement lié à SCP (normalement le CPU) entrait en jeu. Mais cela pourrait certainement être autre chose. Sans connaître les spécifications matérielles des machines en question, il est difficile de se prononcer.
Rsync utilisera presque certainement ssh pour le transport, car c'est le comportement par défaut, donc toute surcharge causée par le cryptage dans scp sera également présente dans rsync.
En déplaçant 80 To de données (des millions de minuscules fichiers) hier, le passage de l'ordinateur à l'ordinateur s'est fait en douceur. rsync a tar s'est avéré être beaucoup plus rapide car nous avons arrêté d'essayer
# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01et est passé à tar au lieu de...
# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ Comme ces serveurs sont sur le même réseau local, la destination est montée en NFS sur le système source, qui effectue le push. Pour rendre le processus encore plus rapide, nous avons décidé de ne pas conserver l'option atime de fichiers :
mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01Le graphique ci-dessous montre la différence entre rsync et tar. C'était mon du patron idée et mon collègue l'ont exécuté et ont fait le grand sur son blog . J'aime juste de belles images . :)
Un hacker en qui j'ai confiance m'a dit "tar over tc instead of nfs might even be faster" (tar sur tc au lieu de nfs). tar cf - directory | ttcp -t dest_machine から ftp.arl.mil/mike/ttcp.html
C'est cool. Le graphique provient probablement d'un outil appelé 'Munin', je pense. Une chose que cela ne mentionne pas est que tar et rsync font des choses totalement différentes. Rsync est bon pour pousser uniquement les changements, ce qui permet d'économiser d'énormes quantités de bande passante et de temps en fonction de votre connexion. Il n'est cependant pas parfait ou n'est pas l'outil idéal pour tout (comme on peut le voir ici).
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
1 votes
Quel type de réseau avez-vous entre les serveurs ? J'ai utilisé un croisement Ethernet GB entre 1 NIC dans chaque machine. J'ai obtenu un très bon résultat avec cette configuration en utilisant SCP.
0 votes
Vous pouvez chercher à savoir pourquoi scp est si lent. Il est peut-être plus lent que des choses comme ftp à cause du cryptage, mais il ne devrait pas être beaucoup plus lent.
0 votes
J'ai 100 mbps entre eux. scp est plus lent sur les petits fichiers (la plupart d'entre eux sont petits).