Quel est le moyen le plus rapide d’envoyer d’énormes quantités de données entre deux ordinateurs? [fermé]

111

C’est une situation dans laquelle je me trouve fréquemment:

  • J'ai un serveur source avec un disque dur de 320 Go à l'intérieur, et 16 Go de RAM ( spécifications exactes disponibles ici , mais comme c'est un problème que je rencontre fréquemment sur d'autres machines, je préférerais que la réponse fonctionne sur n'importe quel ordinateur. machine Linux "raisonnable")
  • J'ai un serveur de sauvegarde avec plusieurs téraoctets d'espace disque ( spécifications exactes ici , voir l'avertissement ci-dessus)

Je souhaite transférer 320 Go de données du serveur source vers le serveur cible (plus précisément, les données depuis /dev/sda).

  1. Les deux ordinateurs étant physiquement côte à côte, je peux faire passer des câbles entre eux.
  2. Je suis sur un réseau local et j'utilise un nouveau routeur , ce qui signifie que la vitesse de mon réseau devrait "idéalement" être de 1 000 Mbits, n'est-ce pas?
  3. La sécurité n'est pas un problème. Je suis sur un réseau local et je fais confiance à toutes les machines du réseau, y compris le routeur.
  4. (facultatif) Je n'ai pas nécessairement besoin d'une somme de contrôle signée des données, mais la vérification des erreurs élémentaires (telles que les paquets perdus ou le lecteur qui devient illisible) doit être détectée plutôt que simplement disparaître dans la sortie.

J'ai cherché cette question en ligne et j'ai testé plusieurs commandes. Celui qui apparaît le plus souvent est celui-ci:

ssh [email protected] 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Cette commande s’est révélée trop lente (elle a fonctionné pendant une heure et n’a reçu que 80 Go environ dans les données). Cela a pris environ 1 minute et 22 secondes pour le paquet de test de 1 Go, et a fini par être deux fois plus rapide sans compression. Les résultats peuvent également avoir été faussés par le fait que le fichier transféré est inférieur à la quantité de RAM sur le système source.

De plus (et cela a été testé sur des éprouvettes de 1 Go), je rencontre des problèmes si j'utilise la gzipcommande et dd; le fichier résultant a une somme de contrôle différente lors de l'extraction sur la cible, que s'il est directement acheminé. J'essaie encore de comprendre pourquoi cela se produit.

IQAndreas
la source
54
Ne oubliez pas sneakernet
gwillie
4
Voulez-vous transférer /dev/sdasous forme d'image ou uniquement les fichiers. Pourquoi rsync n'est pas une option? Est /dev/sdamonté pendant que vous dded?
Jodka Lemon
15
Vos données de performance (1 Go / 80 secondes, 80 Go / 1h) correspondent parfaitement à ce que nous devrions attendre de 100 Mo. Vérifiez votre matériel. ... et gerrit a raison, la taille de 320 Go peut être volumineuse, mais une "grande quantité de données" suscite de mauvaises attentes.
Blafasel
8
"Ne sous-estimez jamais la bande passante d'un train de marchandises rempli de disques." .. Voulez-vous parler du débit, de la latence ou d’un mélange des deux?
Keshlam
8
Un de mes amis a toujours dit: "Ne sous-estimez jamais la bande passante d’une pile de disques durs sur un camion".
AMADANON Inc.

Réponses:

139

Étant donné que les serveurs sont physiquement côte à côte et que vous avez indiqué dans les commentaires que vous y avez accès physiquement, le moyen le plus rapide consiste à extraire le disque dur du premier ordinateur, à le placer dans le second et à transférer les fichiers. sur la connexion SATA.

BlueRaja - Danny Pflughoeft
la source
15
+1: Le transfert via physique semble être le chemin le plus rapide, même si cela signifie obtenir un gros disque dur externe quelque part. C'est environ £ 40, et vous avez probablement déjà passé beaucoup de temps à cela,
deworde
3
Je suis complètement en désaccord avec cette idée si l’on accède à la vitesse maximale sur un réseau gigabit. Les tests sur NFS / SMB via un commutateur Zyxel Gigabit entre un microserveur HP Gen 7 et une machine Pentium G630 me permettent un transfert de ~ 100 Mo / s. (Jusqu'à ce que je quitte le bord extérieur des plateaux d'entraînement.) Donc, je pense que cela devrait être fait en moins de 3 heures. À moins que vous n'utilisiez des disques SSD ou des disques / systèmes de stockage extrêmement hautes performances, je ne pense pas que deux copies puissent produire un débit de 100 Mo / s, ce qui exigerait que chaque opération de copie soit de 200 Mo / s juste pour atteindre le seuil de rentabilité.
Phizes
3
@Phizes: évidemment, vous ne copiez pas sur un temporaire. C'était la mauvaise idée de deword, pas ce dont tout le monde parle. Le point de connexion du lecteur source à la machine cible est d’utiliser SATA-> SATA avec dd(ou une copie de l’arborescence du système de fichiers).
Peter Cordes
10
"Ne sous-estimez jamais la bande passante d'un camion rempli de disques durs. Une sacrée latence cependant"
Kevin
3
@ Kevin: oui, je voulais dire qu'une copie directe entre les disques d'un même ordinateur est au moins aussi rapide que toute autre méthode possible. J'ai évoqué des chiffres réels sur la bande passante pour souligner le point de vue de Phize selon lequel le dépassement de gigE est acceptable pour l'ancien disque dur des OP, mais constitue un goulot d'étranglement pour les nouveaux disques. (Un cas où les deux lecteurs d'un ordinateur n'est pas la meilleure option est lorsqu'il est important d'avoir des ordinateurs distincts utilisant leur RAM pour mettre en cache les métadonnées de la source et de la destination, par exemple pour la synchronisation de milliards de fichiers.)
Peter Cordes
69

netcat est idéal pour des situations comme celle-ci où la sécurité n’est pas un problème:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Notez que si vous utilisez dddepuis GNU coreutils, vous pouvez envoyer SIGUSR1au processus et celui-ci émettra la progression vers stderr. Pour BSD dd, utilisez SIGINFO.

pv est encore plus utile pour rendre compte des progrès réalisés lors de la copie:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999
zackse
la source
2
Pour le deuxième exemple, est-il ddmême nécessaire ou peut pv- on / nctraiter /dev/sdatout seul? (J'ai remarqué que certaines commandes "vomissaient" lorsque j'essayais de lire des fichiers spéciaux comme celui-ci, ou des fichiers avec des 0x00octets)
IQAndreas
5
@ user1794469 La compression aidera-t-elle? Je pense que le réseau n'est pas là où se trouve le goulot d'étranglement.
IQAndreas
17
Ne pas oublier que dans bashon peut utiliser > /dev/tcp/IP /ports et < /dev/tcp/IP /ports redirections au lieu de la tuyauterie en provenance et à netcat respectivement.
Incnis Mrsi
5
Bonne réponse. Gigabit Ethernet est souvent plus rapide que la vitesse du disque dur, la compression est donc inutile. Pour transférer plusieurs fichiers, considérez tar cv sourcedir | pv | nc dest_host_or_ip 9999et cd destdir ; nc -l 9999 | pv | tar xv. De nombreuses variantes sont possibles, par exemple, vous voudrez peut-être conserver un .tar.gzcôté destination plutôt que des copies. Si vous copiez un répertoire à un autre, vous pouvez effectuer une opération rsync ultérieurement, pour une sécurité accrue. Par exemple, votre destination rsync --inplace -avP [email protected]:/path/to/source/. /path/to/destination/.garantit que tous les fichiers sont bien des copies exactes.
Stéphane Gourichon le
3
Au lieu d'utiliser IPv4, vous pouvez obtenir un meilleur débit en utilisant IPv6 car sa charge utile est plus grande. Vous ne le configurez même pas, si les machines sont compatibles IPv6, elles ont probablement déjà une adresse de lien local IPv6
David Costa
33
  1. N'utiliser rapidement la compression.

    • Quel que soit votre support de transfert - en particulier pour le réseau ou l'usb -, vous travaillerez avec des rafales de données pour les lectures, les caches et les écritures, qui ne seront pas exactement synchronisées.
    • Outre les microprogrammes de disque, les caches de disque et les caches de noyau / ram, si vous pouvez également utiliser les processeurs des systèmes de manière à concentrer la quantité de données échangées par rafale, vous devriez le faire .
    • N'importe quel algorithme de compression traitera automatiquement aussi rapidement que possible des séries d'entrées éparses, mais très peu d'entre elles gèrent le reste aux débits du réseau.
    • lz4 est votre meilleure option ici:

      LZ4 est un algorithme de compression sans perte très rapide, offrant une vitesse de compression de 400 Mo / s par cœur, évolutif avec un processeur multicœurs. Il comporte également un décodeur extrêmement rapide, avec une vitesse de plusieurs Go / s par cœur, atteignant généralement les limites de vitesse de la RAM sur les systèmes multicœurs.

  2. De préférence, ne cherchez pas inutilement.

    • Cela peut être difficile à évaluer.
    • S'il y a beaucoup d'espace libre sur le périphérique à partir duquel vous copiez et que le périphérique n'a pas encore été mis à zéro, mais que tous les systèmes de fichiers source doivent être copiés, il est probablement utile de commencer par le faire. quelque chose comme:

      </dev/zero tee >empty empty1 empty2; sync; rm empty*
    • Mais cela dépend du niveau auquel vous devriez lire la source. Il est généralement souhaitable de lire le périphérique de bout en bout à partir de son /dev/some_diskfichier de périphérique, car la lecture au niveau du système de fichiers implique généralement de rechercher une séquence de va-et-vient autour du disque. Et si votre commande de lecture devrait être quelque chose comme:

      </dev/source_device lz4 | ...
    • Toutefois, si votre système de fichiers source ne doit pas être transféré intégralement, la lecture au niveau du système de fichiers est relativement inévitable. Vous devez donc regrouper le contenu de votre entrée dans un flux. paxest généralement la solution la meilleure et la plus simple dans ce cas, mais vous pouvez également envisager mksquashfsde le faire.

      pax -r /source/tree[12] | lz4 | ...
      mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
  3. Ne pas chiffrer avec ssh.

    • L'ajout d'une surcharge de cryptage sur un support approuvé n'est pas nécessaire et peut nuire gravement à la vitesse des transferts continus, car la lecture des données doit être lue deux fois .
    • Le PRNG a besoin des données lues, ou au moins d’une partie de celles-ci, pour maintenir le caractère aléatoire.
    • Et bien sûr, vous devez également transférer les données.
    • Vous devez également transférer la surcharge de cryptage elle-même, ce qui signifie plus de travail pour moins de données transférées par rafale .
    • Et vous devriez plutôt utiliser netcat( ou, comme je préfère, le nmapprojet le plus capablencat ) pour une copie réseau simple, comme cela a été suggéré ailleurs:

      ###  on tgt machine...
      nc -l 9999 > out.lz4
      ###  then on src machine...
      ... lz4 | nc tgt.local 9999
Mikeserv
la source
1
Réponse fantastique. Un point grammatical mineur - "réduisez la quantité de données à échanger par rafale" - je pense que vous utilisez la compression pour augmenter la densité d'informations car les "rafales" ont une largeur fixe et que, par conséquent, la quantité de données échangées reste constante. bien que les informations transférées par rafale puissent varier.
Ingénieur Dollery
@EngineerDollery - oui, c'était idiot. Je pense que c'est mieux,
mikeserv
@IQAndreas - Je considérerais sérieusement cette réponse. Personnellement, j'utilise pigz, et l'augmentation de la vitesse est incroyable . Le parallélisme est une victoire énorme. Les processeurs étant beaucoup plus rapides que toute autre partie du pipeline de données, je doute que la compression parallèle vous ralentisse (gzip n’est pas parallélisable). Vous constaterez peut-être que cela est suffisamment rapide pour que rien ne l’incite à jongler avec les disques durs; Je ne serais pas surpris si celui-ci est globalement plus rapide (y compris le temps d'échange de disque). Vous pouvez comparer avec et sans compression. Dans tous les cas, la réponse à un échange de disques de BlueRaja ou celle-ci devrait être votre réponse acceptée.
Mike S
Une compression rapide est un excellent conseil. Il convient toutefois de noter que cela n’aide que si les données sont raisonnablement compressibles, ce qui signifie, par exemple, qu’elles ne doivent pas déjà être dans un format compressé.
Walter Tross
@WalterTross - cela aidera si une entrée est compressible, quel que soit le rapport, tant que le travail de compression surpasse celui du transfert. Sur un système moderne à quatre cœurs, un lz4travail devrait facilement cadrer, même avec un GIG ouvert, et l’USB 2.0 n’a aucune chance. En outre, il lz4n’a été conçu que pour fonctionner quand il le devrait - c’est en partie très rapide car il sait à quel moment la compression doit être tentée et quand il ne le faut pas. Et s'il s'agit d'un fichier de périphérique en cours de transfert, alors même une entrée précompressée peut compresser quelque peu quand même s'il y a une fragmentation dans le système de fichiers source.
mikeserv
25

Plusieurs limitations pourraient limiter la vitesse de transfert.

  1. Il existe une surcharge de réseau inhérente sur un tuyau de 1 Gbps. Habituellement, cela réduit le débit réel à 900 Mbps ou moins. Ensuite, rappelez-vous qu'il s'agit d'un trafic bidirectionnel et que vous devez vous attendre à beaucoup moins de 900 Mbps.

  2. Même si vous utilisez un "routeur new-ish", êtes-vous certain que le routeur prend en charge 1 Gbps? Tous les nouveaux routeurs ne prennent pas en charge 1 Gbps. De plus, à moins qu'il s'agisse d'un routeur de niveau entreprise, vous allez perdre de la bande passante de transmission supplémentaire vers le routeur, ce qui est inefficace. Bien que basé sur ce que j'ai trouvé ci-dessous, il semble que vous obteniez au-dessus de 100Mbps.

  3. Il se peut que d’autres appareils partageant votre réseau soient encombrés. Avez-vous essayé d'utiliser un câble directement connecté, comme vous l'avez dit, capable de le faire?

  4. Quelle quantité de votre disque IO utilisez-vous? Probablement, vous êtes limité, pas par le réseau, mais par le lecteur de disque. La plupart des disques durs à 7 200 tr / min n’auront qu’environ 40 Mo / s. Utilisez-vous le raid du tout? Utilisez-vous des SSD? Qu'utilisez-vous à distance?

Je suggère d'utiliser rsync si cela est censé être ré-exécuté pour les sauvegardes. Vous pouvez également utiliser scp, ftp (s) ou http en utilisant un programme de téléchargement tel que filezilla à l’autre extrémité, car il parallélisera les connexions ssh / http / https / ftp. Cela peut augmenter la bande passante car les autres solutions utilisent un seul canal. Un seul tuyau / thread est toujours limité par le fait qu'il est mono-thread, ce qui signifie qu'il pourrait même être lié au processeur.

Avec rsync, vous supprimez une grande partie de la complexité de votre solution et vous permettez la compression, la conservation des autorisations et les transferts partiels. Il y a plusieurs autres raisons, mais c'est généralement la méthode de sauvegarde préférée (ou exécute les systèmes de sauvegarde) des grandes entreprises. Commvault utilise en réalité rsync sous son logiciel comme mécanisme de livraison pour les sauvegardes.

Selon votre exemple de 80 Go / h, vous obtenez environ 177 Mbps (22,2 Mo / s). Je pense que vous pourriez facilement doubler ce nombre avec rsync sur une ligne Ethernet dédiée entre les deux boîtiers, car j’ai réussi à obtenir cela lors de mes propres tests avec RSync sur gigabit.

Khrystoph
la source
12
+1 pour rsync. Cela ne sera peut-être pas plus rapide la première fois que vous l'exécuterez, mais ce le sera certainement pour toutes les fois ultérieures.
Skrrp
4
> La plupart des disques durs à 7 200 tr / min n’auront qu’environ 40 Mo / s. IME, vous êtes plus susceptible de voir plus de 100 Mo / s séquentiels avec un lecteur moderne (et cela comprend ~ 5 000 lecteurs). Bien que cela puisse être un disque plus ancien.
Bob le
2
@Bob: Ceux encore modernes ne peuvent lire que 5 400 pistes circulaires par minute. Ces disques sont toujours rapides car chaque piste contient plus d'un mégaoctet. Cela signifie que ce sont aussi des disques assez gros. Un petit disque de 320 Go ne peut pas contenir trop de kilo-octets par piste, ce qui limite nécessairement leur vitesse.
MSalters
1
40 Mo / s est définitivement très pessimiste en lecture séquentielle pour n’importe quel lecteur fabriqué au cours de la dernière décennie. Les disques actuels à 7 200 tr / min peuvent dépasser 100 Mo / s, comme le dit Bob.
Hobbs
3
Gigabit Ethernet est un duplex intégral à 1 000 Mbits / s . Vous obtenez 1000 Mbps (ou, comme vous dites, environ 900 Mbps en réalité) dans chaque direction . Deuxièmement ... les disques durs ont maintenant régulièrement 100 Mo / s. 40 Mo / s est lent, sauf s’il s’agit d’un disque dur d’une décennie.
derobert
16

Nous traitons cela régulièrement.

Les deux méthodes principales que nous avons tendance à utiliser sont:

  1. SATA / eSATA / Sneakernet
  2. Montage direct NFS, puis local cpoursync

Le premier dépend de si le lecteur peut être physiquement déplacé. Ce n'est pas toujours le cas.

La seconde fonctionne étonnamment bien. Généralement, nous maximisons assez facilement une connexion à 1 Gbit / s avec des montages directs NFS. Avec scp, dd over ssh ou quelque chose de similaire, vous ne vous approcherez de rien (vous obtiendrez souvent un débit maximal étrangement proche de 100mpbs). Même sur des processeurs multicœurs très rapides, vous rencontrerez un goulot d'étranglement sur le débit de cryptage maximal de l'un des cœurs sur la plus lente des deux machines, ce qui est extrêmement lent comparé à cp ou rsync intégral sur un montage réseau non crypté. De temps en temps, vous frappez un mur Iops pendant un petit moment et restez bloqué à environ ~ 53 Mo / s au lieu des ~ 110 Mo / s plus typiques, mais cela est généralement de courte durée, sauf si la source ou la destination est réellementun seul lecteur, vous pourriez alors être limité par le taux soutenu du lecteur lui-même (ce qui varie suffisamment pour des raisons aléatoires que vous ne saurez pas tant que vous ne l’essayerez pas) -

NFS peut être un peu ennuyeux à installer si sa distribution est inconnue, mais en général, il s’est avéré le moyen le plus rapide de remplir les tuyaux autant que possible. La dernière fois que j'ai fait cela à plus de 10 Gbit / s, je n’avais jamais découvert si la connexion était au maximum, car le transfert était terminé avant que je ne revienne prendre un café - il est donc possible que vous ayez une limite naturelle. Si vous avez quelques périphériques réseau entre la source et la destination, vous pouvez rencontrer de légers retards ou des ratés dus à l’effet «slinky» du réseau, mais cela fonctionnera généralement au bureau (sans que tout le trafic ne le gomme) ou à une extrémité du centre de données. l'autre (à moins que vous n'ayez une sorte de filtrage / inspection interne, auquel cas tous les paris sont désactivés ).

MODIFIER

J'ai remarqué des discussions sur la compression ... ne compressez pas la connexion. Cela vous ralentira de la même manière qu'une couche cryptographique. Le goulot d'étranglement sera toujours constitué d'un seul cœur si vous compressez la connexion (et vous n'obtiendrez même pas une utilisation particulièrement bonne du bus de ce cœur). La chose la plus lente que vous puissiez faire, selon votre situation, consiste à utiliser un canal crypté et compressé entre deux ordinateurs assis l'un à côté de l'autre sur une connexion de 1 Gbps ou supérieure.

FUTURE PREUVE

Ce conseil est valable pour mi-2015. Ce ne sera presque certainement pas le cas pendant encore trop d'années. Alors prenez tout avec un grain de sel, et si vous faites face à cette tâche régulièrement, alors essayez différentes méthodes sur des charges réelles au lieu de vous imaginer, vous obtiendrez des résultats proches des optimums théoriques, ou même des débits de compression / cryptage observés typiques pour le Web. le trafic, dont une grande partie est textuelle (protip: les transferts groupés sont généralement constitués principalement d'images, d'audio, de vidéos, de fichiers de base de données, de code binaire, de formats de fichiers bureautiques, etc. déjà compressésà leur manière et bénéficient très peu d’être exécutées à travers une autre routine de compression, dont la taille du bloc de compression est presque garantie de ne pas s’aligner sur vos données binaires déjà compressées ...).

J'imagine que dans le futur, des concepts tels que SCTP seront transférés dans un endroit plus intéressant, où les connexions liées (ou les connexions fibre canalisées par un lien interne) sont typiques et où chaque canal peut recevoir un flux indépendant des autres, et chacun flux peut être compressé / crypté en parallèle, etc. etc. Ce serait merveilleux! Mais ce n’est pas le cas aujourd’hui en 2015, et même si fantasmer et théoriser est une bonne chose, la plupart d’entre nous n’ont pas de grappes de stockage personnalisées fonctionnant dans une cryo-chambre et fournissant des données directement aux entrailles d’un Blue Gene / Q générant des réponses pour Watson. Ce n'est tout simplement pas la réalité. Nous n'avons pas non plus le temps d'analyser notre charge de données de manière exhaustive pour déterminer si la compression est une bonne idée ou non - le transfert lui-même serait terminé avant la fin de notre analyse,

Mais...

Les temps changent et ma recommandation contre la compression et le cryptage ne tiendra pas. J'aimerais vraiment que ce conseil soit renversé dans un cas typique très bientôt. Cela me faciliterait la vie.

zxq9
la source
1
@jofel Uniquement lorsque la vitesse du réseau est inférieure au débit de compression du processeur, ce qui n'est jamais le cas pour les connexions de 1 Go ou plus. Dans le cas typique, cependant, le réseau constitue le goulot d'étranglement et la compression accélère effectivement les choses - mais ce n'est pas le cas, comme décrit dans l'OP.
Zxq9
2
lz4est assez rapide pour ne pas goulot d’étranglement gigE, mais en fonction de ce que vous voulez faire avec la copie, vous pourriez avoir besoin de le décompresser. Lzop est assez rapide aussi. Sur mon Sandybridge i5-2500k (3,8 GHz), lz4 < /dev/raid0 | pv -a > /dev/nullpasse à environ 180 Mo / s en entrée, ~ 105 Mo / s en sortie, juste ce qu'il faut pour gigE. La décompression côté réception est encore plus simple pour le processeur.
Peter Cordes
1
En outre, la fréquence 3,8 GHz est légèrement supérieure à celle de la plupart des processeurs de serveur (ou de nombreux systèmes de classe entreprise, quelle que soit leur saveur, du moins celle que je connais habituellement). Il est plus courant de voir des nombres de cœurs beaucoup plus élevés avec des vitesses d'horloge beaucoup plus basses dans les centres de données. La parallélisation des charges de transfert n'a pas été un problème depuis longtemps , nous sommes donc bloqués dans la plupart des cas avec la vitesse maximale d'un cœur - mais je suppose que cela va changer maintenant que les vitesses d'horloge sont généralement dépassées, mais les vitesses du réseau ont toujours un long chemin à parcourir avant d'atteindre leurs maximums.
zxq9
2
Je suis complètement en désaccord avec vos commentaires concernant la compression. Cela dépend complètement de la compressibilité des données. Si vous pouviez obtenir un taux de compression de 99,9%, il serait insensé de ne pas le faire. Pourquoi transférer 100 Go alors que vous pouvez vous en passer à 100 Mo? Je ne dis pas que ce niveau de compression est le cas pour cette question, mais simplement qu'il faut en tenir compte au cas par cas et qu'il n'y a pas de règles absolues.
Engineer Dollery
1
@EngineerDollery Cela ne joue pas dans le transfert en vrac du tout dans le monde réel. Je le fais presque tous les jours et j'ai testé une variété de méthodes et de paramètres. Dans le cas général, les transferts volumineux de données inconnues (tout ce pour quoi vous n’avez pas le temps d’exécuter des tests de réglage de la compression - ce qui signifie pratiquement tout dans un centre de données, une infrastructure d’entreprise, un serveur de petite entreprise ou un réseau domestique) sont beaucoup plus rapide avec une connexion de 1gbps ou supérieure. Allez l'essayer. Le texte est généralement le meilleur cas pour la compression. Le texte comprend une infime fraction d'une charge utile de transfert en bloc typique.
zxq9
6

Un outil astucieux que j'ai utilisé dans le passé est bbcp . Comme vu ici: https://www.slac.stanford.edu/~abh/bbcp/ .

Voir aussi http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

J'ai eu des vitesses de transfert très rapides avec cet outil.

Cœur sombre
la source
1
Le deuxième lien de cette réponse explique comment ajuster les paramètres du noyau pour atteindre des vitesses plus élevées. L'auteur y a reçu 800 mégaoctets par seconde avec des liens de 10 G et certaines choses semblent applicables aux liens de 1 Gbps.
Stéphane Gourichon le
5

Si vous obtenez une première passe en quelque sorte (sur le fil / sneakernet / peu importe), vous pouvez examiner rsynccertaines options qui peuvent considérablement accélérer les transferts ultérieurs. Un très bon chemin à parcourir serait:

rsync -varzP sourceFiles destination

Les options sont les suivantes: verbose, mode archive, récursif, compresser, progression partielle

Hopping Bunny
la source
2
Rsync est plus fiable que netcat, mais l'archive implique récursif, donc r est redondant.
Tanath
En outre, cela -zpeut être très lent en fonction de votre processeur et des données que vous traitez. J'ai constaté des transferts allant de 30 Mo / s à 125 Mo / s en désactivant la compression.
Lindhe
4

Ajout de l'insistance de l'affiche originale dans les commentaires à la réponse de zackse, bien que je ne sois pas sûr que ce soit le plus rapide dans des circonstances typiques.

basha une syntaxe de redirection spéciale:
Pour la sortie:      > /dev/tcp/IP /Port
Pour l' entrée:       < /dev/tcp/IP /Port
IP interdiction soit soit IP décimale pointée ou un nom d' hôte; Portinterdiction de soit un nombre décimal ou un nom de port de /etc/services.

Il n'y a pas de réel /dev/tcp/ répertoire . C'est un kludge syntaxique spécial qui commande bashde créer un socket TCP, de le connecter à la destination spécifiée, puis de faire la même chose qu'une redirection de fichier habituelle (à savoir, remplacer le flux standard respectif par le socket en utilisant dup2 (2)).

Par conséquent, on peut diffuser des données depuis ddou tarvers la machine source directement via TCP. Ou, inversement, pour diffuser des données verstar ou quelque chose de similaire directement via TCP. Dans tous les cas, un netcat superflu est éliminé.

Notes sur netcat

Il existe une incohérence dans la syntaxe entre netcat classique et GNU netcat . J'utiliserai la syntaxe classique à laquelle je suis habitué. Remplacer -lppar-l pour GNU netcat.

De plus, je ne sais pas si GNU netcat accepte -q commutateurs.

Transférer une image disque

(Dans les lignes de la réponse de zackse.)
Sur la destination:

nc -lp 9999 >disk_image

Sur source:

dd if=/dev/sda >/dev/tcp/destination/9999
 

Créer une archive tar.gz, avec tar

Sur la destination:

nc -lp 9999 >backup.tgz

Sur source:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Remplacez .tgzpar .tbzet czavec cjpour obtenir une bzip2archive compressée.

Transfert avec expansion immédiate vers le système de fichiers

Aussi avec tar.
Sur la destination:

cd backups
tar x </dev/tcp/destination/9999

Sur source:

tar c files or directories to be transferred |nc -q 1 -lp 9999

Cela fonctionnera sans -q 1, mais netcat restera bloqué à la fin des données. Voir tar (1) pour une explication de la syntaxe et des mises en garde de tar. S'il existe de nombreux fichiers avec une redondance élevée (entropie faible), la compression (par exemple, czet xzau lieu de cetx ) peut être essayée, mais si les fichiers sont typiques et que le réseau est suffisamment rapide, le processus ne sera que ralentit. Voir la réponse de mikeserv pour plus de détails sur la compression.

Style alternatif (le port d'écoute de destination)

Sur la destination:

cd backups
nc -lp 9999 |tar x

Sur source:

tar c files or directories to be transferred >/dev/tcp/destination/9999
Incnis Mrsi
la source
bash ne peut apparemment pas "écouter" sur un socket, apparemment pour pouvoir attendre et recevoir un fichier: unix.stackexchange.com/questions/49936/… , vous devrez donc utiliser autre chose pour au moins la moitié de la connexion. ...
rogerdpack
3

Essayez les suggestions concernant les connexions directes et l’évitement des protocoles chiffrés tels que ssh. Ensuite, si vous souhaitez toujours améliorer vos performances, donnez au site la lecture suivante: https://fasterdata.es.net/host-tuning/linux/ pour obtenir des conseils sur l'optimisation de vos fenêtres TCP.

Brandon Xavier
la source
2

Je voudrais utiliser ce script que j'ai écrit qui a besoin du socatpaquet.

Sur la machine source:

tarnet -d wherefilesaretosend pass=none 12345 .

Sur la machine cible:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Si le vbufpaquet (Debian, Ubuntu) est là, l'expéditeur du fichier affichera une progression des données. Le récepteur de fichier montrera quels fichiers sont reçus. L'option pass = peut être utilisée lorsque les données peuvent être exposées (plus lentement).

Modifier:

Utilisez l' -noption pour désactiver la compression, si le processeur est un goulot d'étranglement.

Skaperen
la source
2

Si le budget ne vous préoccupe pas, essayez de connecter les lecteurs à un "connecteur de lecteur" Intel Xeon E5 12 core. Ce connecteur est généralement si puissant que vous pouvez même y exécuter le logiciel de votre serveur actuel. Des deux serveurs!

Cela peut sembler une réponse amusante, mais vous devez vraiment prendre en compte la raison pour laquelle vous déplacez les données entre serveurs et savoir si une solution volumineuse avec mémoire et stockage partagés est plus logique.

Vous n'êtes pas sûr des spécifications actuelles, mais le transfert lent peut être limité par la vitesse du disque, pas par le réseau?

utilisateur133111
la source
1

Si vous ne vous souciez que des sauvegardes, et non d'un octet pour une copie d'octet du disque dur, alors je vous recommanderais backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html Il est un peu difficile à installer, mais le transfert est très rapide.

Mon temps de transfert initial pour environ 500 G de données était d'environ 3 heures. Les sauvegardes suivantes ont lieu en 20 secondes environ.

Si vous n'êtes pas intéressé par les sauvegardes, mais que vous essayez de synchroniser les éléments, alors rsync ou l'unisson conviendrait mieux à vos besoins.

Un octet pour une copie d'octet d'un disque dur est généralement une idée horrible à des fins de sauvegarde (aucune sauvegarde incrémentielle, aucune économie d'espace, le lecteur ne peut être utilisé, vous devez sauvegarder "l'espace vide", et vous devez sauvegarder des déchets (comme un fichier d'échange de 16 G ou 200 G de fichiers de base ou autres). Avec rsync (ou backuppc ou autres), vous pouvez créer des "instantanés" à temps pour que vous puissiez aller à "à quoi ressemblait votre système de fichiers il y a 30 minutes" avec très peu de frais généraux.

Cela dit, si vous voulez vraiment transférer un octet pour une copie d’octets, votre problème va résider dans le transfert et non dans la récupération des données du lecteur. Sans 400 G de RAM, un transfert de fichier de 320 G prend un temps considérable. Utiliser des protocoles qui ne sont pas cryptés est une option, mais quoi qu’il en soit, vous devrez rester assis et attendre plusieurs heures (sur le réseau).

coteyr
la source
1
Comment 400G de RAM accélèrent-ils le transfert de données?
Skaperen
Je ne suis pas sûr que ce soit le but recherché, mais je le lis comme "tout support plus lent que le transfert de RAM à RAM prendra un certain temps", plutôt que "acheter 400 Go de RAM et votre transfert de disque dur à disque dur ira plus vite".
MichaelS
Ouais, la mémoire tampon sera pour vous, et cela semblera plus rapide. Vous pouvez effectuer un transfert HD à HD avec la mise en mémoire tampon RAM complètement et cela semblera très rapide. Il faudra également un certain temps pour vider le disque, mais HD à RAM à RAM à HD est plus rapide que HD à HD. (N'oubliez pas que vous devez quand même utiliser HD à RAM à RAM à HD mais si vous avez moins de mémoire vive (RAM), vous devrez "purger" par segments.)
coteyr le
Une autre façon de dire est que pour compresser ou même simplement envoyer tout le lecteur source, il faut le lire dans la RAM. S'il ne convient pas tout à la fois, il doit lire un segment, envoyer, ignorer un segment, chercher, lire un segment, etc. S'il s'adapte à la fois, il doit simplement lire tout en même temps. Même sur la destination.
coteyr
1
HD to RAM to RAM to HD est plus rapide que HD to HD Comment peut-il être plus rapide?
AL le
1

Quel que soit le programme, j'ai généralement constaté que "extraire" des fichiers sur un réseau est plus rapide que "pousser". C'est-à-dire que la connexion à l'ordinateur de destination et la lecture sont plus rapides que la connexion à l'ordinateur source et l'écriture.

De même, si vous envisagez d'utiliser un lecteur intermédiaire, tenez compte des points suivants: Procurez-vous un lecteur externe (sous forme de package ou un lecteur séparé branché sur une station d'accueil) utilisant le protocole eSATA plutôt que le lecteur USB. Puis, sur chacun des deux ordinateurs, installez une carte avec un port eSATA ou procurez-vous un simple câble d’adaptateur qui connecte l’un des ports SATA internes à un connecteur eSATA externe. Branchez ensuite le lecteur sur l’ordinateur source, mettez-le sous tension et attendez qu’il se monte automatiquement (vous pouvez le monter manuellement, mais si vous le faites de manière répétée, vous pouvez également le placer dans votre fichier fstab). Puis copier; vous écrivez à la même vitesse que sur un lecteur interne. Puis démontez le lecteur, mettez-le hors tension, branchez-le sur l'autre ordinateur, mettez-le sous tension, attendez le montage automatique et lisez.

Mike Ciaraldi
la source
2
Pouvez-vous préciser comment vous "extrayez" des fichiers? Quels utilitaires utilisez-vous et pouvez-vous fournir un exemple montrant cet effet?
STW
Je ne sais pas si ce sera une réponse plus complète, mais considérons le scénario suivant: supposons que vous ayez deux ordinateurs, foo et bar, et que vous souhaitiez copier des données de foo à bar. (1) Vous vous connectez à foo, puis montez à distance le lecteur qui est physiquement attaché à bar. Ensuite, vous copiez du disque de foo sur le répertoire monté à distance (qui est physiquement sur le bouton). J'ai appelé cela pour transmettre les données à l'autre ordinateur. (2) Comparez cela à l’autre façon de copier les mêmes données. Connectez-vous à bar, montez à distance le répertoire attaché à foo et lisez à partir de foo sur le lecteur de bar. C'est en train de tirer.
Mike Ciaraldi
Cette copie peut être effectuée à l'aide de la commande Linux cp, à partir d'un gestionnaire de fichiers à interface graphique ou de tout autre moyen de copier des fichiers. Je pense que tirer s’avère plus rapide, car l’écriture est plus lente que la lecture et les décisions sur la manière d’écrire sur le disque de destination sont prises sur le même ordinateur auquel le lecteur est connecté, ce qui permet de réduire les frais généraux. Mais peut-être que ce n'est plus le cas avec les systèmes plus modernes.
Mike Ciaraldi
1

Je vais vous recommander de regarder le regroupement de cartes réseau. Cela implique l'utilisation de plusieurs connexions réseau fonctionnant en parallèle. En supposant que vous ayez réellement besoin de plus d'un transfert de 1 Go et que le coût de 10 Go soit prohibitif, les 2 Go fournis par le regroupement de cartes réseau représenteraient un coût mineur et vos ordinateurs disposeraient peut-être déjà de ports supplémentaires.

Byron Jones
la source
Si vous vous référez au protocole de contrôle d'agrégation de liens (LACP), vous n'allez pas voir une augmentation de la vitesse. Il offrait une redondance et une certaine capacité à desservir plus de connexions simultanées, mais cela ne donnerait pas un coup de pouce supplémentaire à ce type de transfert.
STW
@STW: Il faut un commutateur pour regrouper deux liaisons d'une machine en une liaison de 2 Gbits, mais c'est possible. Utile que si les deux machines ont un lien de 2gbits au commutateur, cependant. Si vous avez deux câbles sous NIC <-> NIC, sans commutateur, cela devrait également fonctionner, mais cela n’est pas très utile (à moins d’avoir une 3ème NIC sur une machine pour les garder connectés à Internet).
Peter Cordes
Existe-t-il un nom spécifique pour cette fonctionnalité dans les commutateurs?
STW
Il existe plusieurs variantes d'association de cartes réseau, d'EtherChannel, etc. STW convient pour certaines configurations, cela ne changera rien, mais pour certaines configurations, ce serait le cas. Cela dépend du fait que le canal lié accélère ou non les performances pour un seul socket IP. Vous aurez besoin de rechercher les détails pour déterminer s'il s'agit d'une solution viable pour vous.
Byron Jones
802.3ad est le standard ouvert que vous recherchez sur vos commutateurs. En guise de solution rapide, vous pouvez simplement connecter des cartes réseau supplémentaires au réseau et leur attribuer les adresses IP appropriées sur des sous-réseaux distincts dans un espace d'adressage privé. (hôte 1 port a et hôte 2 obtenez un sous-réseau, hôte 1 port b et hôte 2 port b obtenez un autre sous-réseau). Ensuite, exécutez deux tâches parallèles pour effectuer le transfert. Ce sera beaucoup plus simple que d'apprendre les tenants et les aboutissants d'Etherchannel, du 802.3ad, etc.
Dan Pritts le
1

FWIW, j'ai toujours utilisé ceci:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

Le problème avec cette méthode est qu’elle conservera les autorisations de fichiers / dossiers entre les machines (en supposant que les mêmes utilisateurs / groupes existent sur les deux) (en général, je le fais pour copier des images de disque virtuel car je peux utiliser un paramètre -S pour gérer les fichiers fragmentés. )

Je viens de tester cela entre deux serveurs occupés et de gérer environ 14 Go sur 216 (environ 64 Mo / s) - pourrait mieux faire entre des machines dédiées et / ou de compression ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers
ttstooge
la source
1

Sauf si vous souhaitez effectuer des analyses judiciaires de système de fichiers, utilisez un programme de vidage / restauration pour votre système de fichiers afin d'éviter de copier l'espace disponible que le système de fichiers n'utilise pas. En fonction de votre système de fichiers, cela préservera généralement toutes les métadonnées, y compris ctime. Les numéros d'inode peuvent changer, encore une fois, en fonction du système de fichiers utilisé (xfs, ext4, ufs ...).

La cible de restauration peut être un fichier sur le système cible.

Si vous voulez une image de disque complet avec la table de partition, vous pouvez ddutiliser le premier 1M du disque pour obtenir la table de partition / bootloaders / stuff, mais ensuite xfsdumples partitions.

Votre info-dump ne permet pas de savoir quel type de système de fichiers vous avez. Si c’est le cas, alors je pense qu’il existe un programme de sauvegarde / restauration. Si c'est ZFS, IDK, il y a peut-être quelque chose.

Généralement, la copie complète des disques est trop lente, sauf dans des situations de récupération. Vous ne pouvez pas faire de sauvegardes incrémentielles de cette façon non plus.

Peter Cordes
la source
1

Vous pouvez également configurer les systèmes pour qu'ils aient un stockage partagé!

Je considère que ceux-ci sont côte à côte, et vous êtes susceptible de le faire encore et encore ....

utilisateur133526
la source
1

Que diriez-vous d'un câble Ethernet croisé? Au lieu de vous fier aux vitesses sans fil, vous êtes limité à la vitesse câblée de votre carte réseau.

Voici une question similaire avec quelques exemples de ce type de solution.

Apparemment, un câble Ethernet typique suffira de nos jours. Évidemment, plus votre carte réseau est performante, plus le transfert est rapide.

Pour résumer, si une configuration réseau est nécessaire, vous devez vous limiter à la définition d'adresses IP statiques pour votre serveur et votre ordinateur de sauvegarde avec un masque de sous-réseau 255.255.255.0.

Bonne chance!

Modifier:

@Khrystoph en a parlé dans sa réponse


la source
Comment cela va-t-il améliorer les taux de vitesse? Pouvez-vous s'il vous plaît expliquer votre réponse?
AL
1
Cela améliorerait potentiellement la vitesse, car vous n'auriez pas à vous soucier du ralentissement du réseau intermédiaire. En ce qui concerne les câbles Ethernet "typiques" et "croisés" - 1 Gigabit Ethernet se croisera automatiquement si nécessaire. Les commutateurs Ethernet HP le feront à 100 Mo. Les autres marques, généralement pas, et vous aurez besoin d'un crossover si vous êtes bloqué à 100Mo.
Dan Pritts
1

Plusieurs personnes recommandent de ne pas utiliser ssh car le cryptage vous ralentira. Les processeurs modernes peuvent en réalité être assez rapides à 1 Go, mais OpenSSH rencontre des problèmes de mise en œuvre de son interface de fenêtrage interne qui peuvent vous ralentir considérablement.

Si vous voulez faire cela avec ssh, jetez un coup d’œil à HPN SSH . Il résout les problèmes de fenêtrage et ajoute un cryptage multithread. Malheureusement, vous devrez reconstruire SSH sur le client et le serveur.

Dan Pritts
la source
0

OK, j'ai tenté de répondre à cette question pour deux ordinateurs dotés de "très gros tuyaux" (10Gbe) "proches" l'un de l'autre.

Le problème que vous rencontrez ici est le suivant: la plupart des compressions créeront un goulot d'étranglement au niveau du processeur, car les tuyaux sont très gros.

performance pour transférer un fichier de 10 Go (connexion réseau de 6 Gb [linode], données non compressibles):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

Et deux boîtes sur 10 Gbe, versions légèrement plus anciennes de netcat (CentOs 6.7), fichier 10 Go:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

Donc, dans un cas, Netcat utilisait moins de CPU, dans l'autre cas, donc YMMV.

Avec netcat, s’il n’a pas d’option "-N -q 0", il peut transférer des fichiers tronqués, soyez prudent ... d’autres options telles que "-w 10" peuvent également entraîner des fichiers tronqués.

Ce qui se passe dans presque tous ces cas, c’est que le cpu est au maximum, et non le réseau. scpatteint environ 230 Mo / s, un noyau étant utilisé à 100%.

Iperf3 crée malheureusement des fichiers corrompus . Certaines versions de netcat semblent ne pas transférer l'intégralité du fichier, ce qui est très étrange. Surtout les anciennes versions de celui-ci.

Diverses incantations de "gzip en tant que pipe à netcat" ou "mbuffer" semblaient également dépasser le cpu avec gzip ou mbuffer. Lz4 pourrait aider. En outre, certains des tuyaux gzip que j'ai essayés ont abouti à des transferts corrompus pour les très gros fichiers (> 4 Go), soyez donc prudent :)

Une autre chose qui pourrait fonctionner spécialement pour une latence plus élevée (?) Est d’ajuster les paramètres TCP. Voici un guide qui mentionne les valeurs suggérées:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm et https://fasterdata.es.net/host-tuning/linux/ (à partir d'une autre réponse), éventuellement paramètres IRQ: https://fasterdata.es .net / réglage de l'hôte / réglage 100g /

suggestions de linode, ajoutez à /etc/sysctl.conf:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

De plus, ils aimeraient que vous exécutiez:

 /sbin/ifconfig eth0 txqueuelen 10000 

Cela vaut la peine de vérifier deux fois après avoir peaufiné pour nous assurer que les changements ne causent pas de préjudice également.

Cela vaut également la peine d’ajuster la taille de la fenêtre: https://iperf.fr/iperf-doc.php#tuningtcp

Avec des connexions plus lentes, la compression peut certainement aider. Si vous avez de gros tuyaux, une compression très rapide pourrait vous aider avec des données facilement compressibles. Ne l'avez pas essayée.

La réponse standard pour "la synchronisation des disques durs" est de rsync les fichiers, ce qui évite le transfert lorsque cela est possible.

Une autre option: utilisez "parallel scp" (d'une manière ou d'une autre), alors il utilisera plus de cœurs ...

rogerdpack
la source