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

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 user@192.168.1.100 '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.

É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.

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

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

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.

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.

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.

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

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

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.

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.

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?

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).

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.

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.

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

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.

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 ....

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

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.

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 ...