Transférez 15 To de fichiers minuscules


79

J'archive les données d'un serveur à un autre. Au départ, j'ai commencé un rsynctravail. Il a fallu deux semaines pour que la liste de fichiers ne soit constituée que pour 5 To de données et une autre semaine pour transférer 1 To de données.

Ensuite, je devais tuer le travail car nous avions besoin de temps d’arrêt sur le nouveau serveur.

Il a été convenu que nous allons le garder, car nous n’aurons probablement pas besoin d’y accéder à nouveau. Je pensais le diviser en morceaux de 500 Go. Après tarcela, j'allais le copier ssh. J'utilisais taret pigzc'est encore trop lent.

Y a-t-il une meilleure façon de le faire? Je pense que les deux serveurs sont sur Redhat. Ancien serveur est Ext4 et le nouveau est XFS.

La taille des fichiers varie de quelques kb à quelques mb et il y a 24 millions de jpeg dans 5 To. Donc, je suppose environ 60-80 millions pour 15 To.

edit: Après avoir joué avec rsync, nc, tar, mbuffer et pigz pendant quelques jours. Le goulot d'étranglement va être le disque IO. Les données étant réparties sur 500 disques SAS et environ 250 millions de fichiers jpeg. Cependant, maintenant, j'ai découvert tous ces outils utiles que je pourrai utiliser à l'avenir.



2
Une option consiste à créer les fichiers tar compressés sur un lecteur externe et à les transférer vers le nouveau système. Le disque supplémentaire accélérera la création des fichiers tar (il ne sera pas écrit sur les disques existants du système, éventuellement en essayant de lire 15 To), et ne bloque pas le nouveau serveur.
Brian

4
Y a-t-il une meilleure façon de le faire? - Oui, la réplication DFS de Windows Server 2012 R2 préparerait cela en 10 heures environ . Et il synchroniserait les modifications et reprendrait là où il s'était arrêté après les redémarrages.
TessellatingHeckler

27
@TessellatingHeckler: vous proposez donc à OP de migrer de Redhat vers Windows avant l'archivage?
Thomas Weller

12
@ThomasWeller Ils ont demandé "Y a-t-il une meilleure façon?", Et il y en a. Je ne recommande pas qu'ils utilisent le meilleur moyen. Ils sont libres d'utiliser des commandes dans un tube qui ne peuvent pas récupérer d'interruption, ne vérifient pas le contenu du fichier, ne peuvent pas signaler le statut de la copie, ne peuvent pas utiliser les blocs copiés précédemment pour éviter de copier des parties de fichiers, n'ont aucune implicite prend en charge la copie à faible priorité, ne peut pas être suspendu, ne mentionne pas la copie des listes de contrôle d'accès et a besoin de quelqu'un qui reste connecté pour l'exécuter. Cependant, toute autre personne intéressée pourrait être intéressée ou invitée à dire "x le fait sous Linux".
TessellatingHeckler

Réponses:


64

J'ai eu de très bons résultats en utilisant tar, pigz(gzip parallèle) et nc.

Machine source:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Machine de destination:

Extraire:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Pour conserver les archives:

nc source_machine_ip 9876 > smallstuff.tar.gz

Si vous voulez voir le taux de transfert, dirigez-le pvensuite pigz -d!


3
Pour votre information, vous pouvez remplacer pigzavec gzipou supprimer complètement, mais la vitesse sera nettement plus lente.
h0tw1r3

10
Comment cela peut-il être accepté si OP a déjà essayé taret pigz? Je ne comprends pas ...
Thomas Weller

5
@ThomasWeller où avez-vous eu qu'il a essayé pigz? D'après la question, il semble n'avoir essayé rsyncque jusqu'à présent et envisageait d' utiliser tarle fractionnement et le regroupement des données. Surtout s'il n'a pas utilisé l' option -z/ --compresssur rsync, pigzpourrait théoriquement aider de manière significative.
Doktor J

1
@ThomasWeller oui en effet j'ai déjà essayé tar et pigz mais pas nc. J'utilisais ssh donc cela ajoutait beaucoup plus de frais généraux.
lbanz

2
@lbanz signifie simplement que tarles données ne sont pas produites assez rapidement pour pigzutiliser beaucoup de ressources processeur pour la compression. Lire un grand nombre de petits fichiers implique beaucoup plus d'appels système, beaucoup plus de recherches de disque et beaucoup plus de temps système que de lire le même nombre d'octets de fichiers plus volumineux.
Hobbs

21

Je m'en tenais à la solution rsync. Moderne (3.0.0+) rsync utilise une liste de fichiers incrémentielle, il n’a donc pas besoin de créer une liste complète avant le transfert. Donc, le redémarrer ne vous obligera pas à refaire tout le transfert en cas de problème. Le fractionnement du transfert par répertoire de premier ou deuxième niveau optimisera encore cette opération. (J'utiliserais rsync -a -Pet ajouterais --compresssi votre réseau est plus lent que vos lecteurs.)


J'utilise rsync 2.6.8 sur l'ancien serveur. Comme il s’agit d’une de ces boîtes où nous ne sommes pas autorisés à installer / mettre à jour quoi que ce soit comme indiqué par le vendeur ou cela annule la garantie. Je pourrais le mettre à jour et voir si c'est plus rapide.
lbanz

18
Recherchez (ou créez) un fichier binaire rsync lié statiquement et exécutez-le simplement à partir de votre domicile. Espérons que cela ne gâchera aucune garantie.
Fox

Que diriez- unisonvous Comment ça se compare rsync?
Gwyneth Llewelyn

15

Configurez un VPN (s'il s'agit d'Internet), créez un lecteur virtuel d'un format quelconque sur le serveur distant (rendez-le ext4), montez-le sur le serveur distant, puis montez-le sur le serveur local (à l'aide d'un protocole de niveau bloc, tel que iSCSI). ) et utilisez dd ou un autre outil au niveau du bloc pour effectuer le transfert. Vous pouvez ensuite copier les fichiers du lecteur virtuel sur le lecteur réel (XFS) à votre convenance.

Deux raisons:

  1. Pas de surcharge du système de fichiers, qui est le principal responsable des performances
  2. Aucune recherche, vous regardez en lecture / écriture séquentielle des deux côtés

3
Ignorer le système de fichiers est une bonne chose. Copier au niveau du bloc d'un système de fichiers monté en lecture-écriture est une très mauvaise idée. Démontez ou montez en lecture seule en premier.
JB.

Avoir une copie de 15 To craint aussi. Cela signifie que le nouveau serveur nécessite au minimum 30.
Arthur Kay

3
Si le serveur utilise LVM, vous pouvez créer un instantané en lecture seule du système de fichiers et le copier à la place. Espace supplémentaire uniquement pour les modifications apportées au système de fichiers pendant la lecture de l'instantané.
Liori

9

Si l'ancien serveur est en cours de déclassement et que les fichiers peuvent être hors ligne pendant quelques minutes, il est souvent plus rapide de simplement extraire les disques de l'ancien boîtier, de les connecter au nouveau serveur, de les monter (en ligne maintenant) et de copier les fichiers. aux nouveaux disques natifs des serveurs.


2
C'est environ 1Po de disques de 2 To, donc c'est beaucoup trop.
lbanz

3

Utilisez mbuffer et s’il est sur un réseau sécurisé, vous pouvez éviter l’étape de chiffrement.


3

(Plusieurs réponses différentes peuvent fonctionner. En voici une autre.)

Générez la liste de fichiers avec find -type f(cela devrait prendre quelques heures), divisez-la en petits morceaux et transférez chaque morceau avec rsync --files-from=....


3

Avez-vous envisagé de sneakernet? Par cela, je veux dire tout transférer sur le même lecteur, puis le déplacer physiquement.

Il y a environ un mois, Samsung a dévoilé un disque dur de 16 To (techniquement, il s'agit de 15,36 To), qui est aussi un disque SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -drive-16tb

Je pense que ce lecteur ferait presque pour cela. Vous devez toujours copier tous les fichiers, mais comme vous n’avez pas de latence sur le réseau et que vous pouvez probablement utiliser SATA ou une technique similaire, cela devrait être beaucoup plus rapide.


2

S'il y a une chance d'obtenir un taux de réussite élevé lors de la déduplication, j'utiliserais quelque chose comme borgbackup ou attique.

Sinon, vérifiez la solution netcat + tar + pbzip2 , adaptez les options de compression en fonction de votre matériel - vérifiez quel est le goulot d'étranglement (CPU? Réseau? IO?). Le pbzip2 s'étendrait sur tous les processeurs, offrant de meilleures performances.


lzma ( xz) décompresse plus rapidement que bzip2 et fonctionne bien sur la plupart des entrées. Malheureusement, xzl'option multithread n'est pas encore implémentée.
Peter Cordes

Généralement, la compression nécessite plus de puissance que la décompression. Par conséquent, si le processeur est le facteur limitant, pbzip2 entraînerait de meilleures performances globales. La décompression ne devrait pas affecter le processus si les deux machines sont similaires.
neutrinus

Oui, ce que je voulais dire, c’est dommage qu’il n’y ait pas de lzma multi-thread à flux unique. Bien que pour ce cas d'utilisation, le transfert de systèmes de fichiers entiers de données pigzserait prob. soyez le compresseur le plus lent que vous voudriez utiliser. Ou même lz4. (Il y a un lz4mtmulti-thread-for-a-single-stream disponible. Il ne thread pas très efficacement (génère de nouveaux threads très souvent), mais il y a une accélération solide)
Peter Cordes

2

Vous utilisez RedHat Linux, cela ne s'appliquerait donc pas, mais comme une autre option:

J'ai eu beaucoup de succès à utiliser ZFS pour contenir des millions de fichiers car les inodes ne sont pas un problème.

Si c'était une option pour vous, vous pourriez alors prendre des instantanés et utiliser zfs pour envoyer des mises à jour incrémentielles. J'ai eu beaucoup de succès en utilisant cette méthode pour transférer ainsi que des données d'archives.

ZFS est principalement un système de fichiers Solaris, mais peut être trouvé dans illumos (fork open source de Sun OpenSolaris). Je sais que l’utilisation de ZFS sous BSD et Linux (avec FUSE?) A également eu de la chance - mais je n’ai aucune expérience en la matière.


3
Il existe un port Linux natif non-FUSE de ZFS: zfsonlinux.org
EEAA

1

Démarrez un rsyncdémon sur la machine cible. Cela accélérera beaucoup le processus de transfert.


-1

Vous pouvez faire cela avec juste tar et ssh, comme ceci:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

Ou, si vous souhaitez conserver des fichiers individuels:

tar zcf - <your files> | ssh <destination host> "tar zxf -"


1
Il ne fera pas de déduplication, pas moyen de reprendre, en compressant en utilisant un seul processeur.
neutrinus
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.