Quel est le moyen le plus rapide d'envoyer des quantités massives de données entre deux ordinateurs?
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 quelle machine Linux "raisonnable")
- J'ai un serveur de sauvegarde avec plusieurs téraoctets d'espace sur le disque dur ( 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 (en particulier, les données de /dev/sda).
- Les deux ordinateurs sont physiquement côte à côte, je peux donc faire passer des câbles entre eux.
- Je suis sur un LAN, et j'utilise un nouveau routeur , ce qui signifie que la vitesse de mon réseau devrait "idéalement" être de 1000 Mbits, non?
- 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.
- (facultatif) Je n'ai pas nécessairement besoin d'une somme de contrôle signée des données, mais d'une vérification d'erreur de base (comme les paquets perdus ou le lecteur devenant illisible) doit être détecté 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 le suivant:
ssh [email protected] 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz
Cette commande s'est avérée trop lente (elle a fonctionné pendant une heure, n'a obtenu qu'environ 80 Go à travers les données). Il a fallu environ 1 minute et 22 secondes pour le paquet de test de 1 Go, et a fini par être deux fois plus rapide lorsqu'il n'était pas compressé. 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 reçois des problèmes si j'utilise la commande gzip et dd; le fichier résultant a une somme de contrôle différente lorsqu'il est extrait sur la cible, que s'il est redirigé directement. J'essaie toujours de comprendre pourquoi cela se produit.
Étant donné que les serveurs sont physiquement côte à côte et que vous avez mentionné dans les commentaires que vous y avez physiquement accès, la manière la plus rapide serait de retirer le disque dur du premier ordinateur, de le placer dans le second, et transférez les fichiers via 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 dd de GNU coreutils, vous pouvez envoyer SIGUSR1 au processus et il émettra une progression vers stderr. Pour BSD dd, utilisez SIGINFO.
pv est encore plus utile pour rendre compte de la progression 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
Do utilisez rapide compression.
- Quel que soit votre support de transfert - en particulier pour le réseau ou l'USB - vous travaillerez avec des données rafales pour les lectures, les caches et les écritures, et celles-ci ne seront pas exactement synchronisées.
- Outre le firmware du disque, les caches de disque et les caches de noyau/RAM, si vous pouvez également utiliser les CPU des systèmes d'une manière ou d'une autre pour concentrer la quantité de données échangées par burst alors vous devrait le faire.
- N'importe quel algorithme de compression gèrera automatiquement les passages clairsemés le plus rapidement possible, mais il y en a très peu qui gèreront le reste aux débits du réseau.
lz4est votre meilleure option ici:LZ4 est un algorithme de compression sans perte très rapide, offrant une vitesse de compression à 400 Mo/s par cœur, évolutif avec un processeur multi-cœurs. Il dispose également d'un décodeur extrêmement rapide, avec une vitesse de plusieurs Go/s par cœur, atteignant généralement les limites de vitesse RAM sur les systèmes multicœurs).
De préférence ne pas chercher 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 été mis à zéro récemment, mais que tous les systèmes de fichiers source doivent être copiés, cela vaut probablement la peine de commencer 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 du début à la fin à partir de son
/dev/some_diskfichier de périphérique, car la lecture au niveau du système de fichiers impliquera généralement une recherche en va-et-vient et autour du disque de manière non séquentielle. Et donc votre commande de lecture devrait ressembler à ceci:</dev/source_device lz4 | ...Cependant, si votre système de fichiers source ne doit pas être transféré en entier, alors la lecture au niveau du système de fichiers est assez inévitable, et vous devez donc regrouper votre contenu d'entrée dans un flux.
paxest généralement la solution la meilleure et la plus simple dans ce cas, mais vous pouvez également envisagermksquashfs.pax -r /source/tree[12] | lz4 | ... mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
Ne pas crypter avec
ssh.- L'ajout d'une surcharge de chiffrement à un support de confiance n'est pas nécessaire et peut être gravement préjudiciable à la vitesse des transferts soutenu dans la mesure où les données lues doivent être lues - deux fois.
- Le PRNG a besoin des données lues, ou au moins certaines d'entre elles, pour maintenir l'aléatoire.
- Et bien sûr, vous devez également transférer les données.
- Vous devez également transférer la surcharge de chiffrement elle-même - ce qui signifie plus de travail pour moins de données transférées par rafale.
Et donc vous devriez plutôt utiliser
netcat( ou, comme je préfère, le projetnmapest plus capablencat) pour une simple copie réseau, comme cela a été suggéré ailleurs:### on tgt machine... nc -l 9999 > out.lz4 ### then on src machine... ... lz4 | nc tgt.local 9999
Il existe plusieurs limitations qui pourraient limiter la vitesse de transfert.
Il existe une surcharge réseau inhérente sur un canal 1 Gbit/s. Habituellement, cela réduit le débit RÉEL à 900 Mbps ou moins. Ensuite, vous devez vous rappeler qu'il s'agit d'un trafic bidirectionnel et que vous devez vous attendre à moins de 900 Mbps.
Même si vous utilisez un "nouveau routeur", êtes-vous certain que le routeur prend en charge 1 Gbit/s? Tous les nouveaux routeurs ne prennent pas en charge 1 Gbit/s. De plus, à moins qu'il ne s'agisse d'un routeur de niveau entreprise, vous allez probablement perdre une bande passante de transmission supplémentaire au routeur étant inefficace. Bien que basé sur ce que j'ai trouvé ci-dessous, il semble que vous atteigniez plus de 100 Mbps.
Il pourrait y avoir une congestion du réseau provenant d'autres appareils partageant votre réseau. Avez-vous essayé d'utiliser un câble directement connecté comme vous l'avez dit?
Quelle quantité de votre disque IO utilisez-vous? Vous êtes probablement limité, non pas par le réseau, mais par le lecteur de disque. La plupart des disques durs à 7200 tr/min n'obtiendront qu'environ 40 Mo/s. utilisez-vous raid du tout? Utilisez-vous des SSD? Qu'utilisez-vous à l'extrémité distante?
Je suggère d'utiliser rsync si cela devrait être réexécuté pour les sauvegardes. Vous pouvez également scp, ftp (s) ou http en utilisant un téléchargeur comme 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 sont sur un seul tuyau. Un seul tube/thread est toujours limité par le fait qu'il est à un seul 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, vous autorisez la compression, la conservation des autorisations et autorisez les transferts partiels. Il existe 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 fait rsync sous son logiciel comme mécanisme de livraison pour les sauvegardes.
Sur la base de votre exemple donné de 80 Go/h, vous obtenez environ 177 Mbps (22,2 Mo/s). Je pense que vous pouvez facilement doubler cela avec rsync sur une ligne Ethernet dédiée entre les deux boîtiers car j'ai réussi à l'obtenir dans mes propres tests avec rsync sur gigabit.
Nous en traitons régulièrement.
Les deux principales méthodes que nous avons tendance à utiliser sont:
- SATA/eSATA/sneakernet
- Montage NFS direct, puis
cpoursynclocal
Le premier dépend de la possibilité de déplacer physiquement le lecteur. Ce n'est pas toujours le cas.
Le second fonctionne étonnamment bien. Généralement, nous maximisons une connexion à 1 Gbit/s assez facilement avec des montages NFS directs. Vous ne vous rapprocherez pas de cela avec scp, dd over ssh, ou quelque chose de similaire (vous obtiendrez souvent un taux maximum étrangement proche de 100mpbs). Même sur des processeurs multicœurs très rapides, vous rencontrerez un goulot d'étranglement sur le débit cryptographique maximal de l'un des cœurs sur la plus lente des deux machines, ce qui est déprimant par rapport à cp ou rsync à passage intégral sur un montage réseau non chiffré. Parfois, vous frapperez un mur d'iops pendant un petit moment et serez coincé à 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 en fait un seul disque, alors vous pourriez être limité par le taux soutenu du disque lui-même (qui varie suffisamment pour des raisons aléatoires que vous ne saurez pas avant de l'essayer) - meh.
NFS peut être un peu ennuyeux à configurer s'il s'agit d'une distribution inconnue, mais en règle générale, il a été le moyen le plus rapide de remplir les tuyaux aussi complètement que possible. La dernière fois que j'ai fait cela à plus de 10 Gbit/s, je n'ai jamais vraiment découvert s'il maximisait la connexion, car le transfert était terminé avant que je revienne de prendre du café - il peut donc y avoir une limite naturelle que vous atteignez. Si vous avez quelques périphériques réseau entre la source et la destination, vous pouvez rencontrer de légers retards ou hoquets à cause de l'effet slinky du réseau, mais généralement cela fonctionnera à travers le bureau (sans autre trafic le détraquant) ou d'une extrémité du centre de données à l'autre (sauf si vous avez une sorte de filtrage/inspection se produisant en interne, dans ce cas, tous les paris sont désactivés).
MODIFIER
J'ai remarqué quelques bavardages sur la compression ... faites pas compressez la connexion. Cela vous ralentira de la même manière qu'une couche cryptographique. Le goulot d'étranglement sera toujours un cœur unique 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 dans votre situation est d'utiliser un canal compressé crypté entre deux ordinateurs assis côte à côte sur une connexion de 1 Gbit/s ou plus.
PREUVE FUTURE
Ce conseil est valable mi-2015. Ce ne sera presque pas certainement pas le cas avant trop d'années. Prenez donc tout avec un grain de sel, et si vous faites face à cette tâche régulièrement, essayez une variété de méthodes sur charges réelles au lieu d'imaginer que vous obtiendrez quelque chose de proche des optimaux théoriques, ou même de la compression observée/taux de débit crypto typiques pour des choses comme le trafic Web, beaucoup dont textuel (protip: les transferts en masse consistent généralement principalement en images, audio, vidéo, fichiers de base de données, code binaire, formats de fichiers bureautiques, etc. qui sont déjà compressés à leur manière et bénéficient très peu de l'exécution d'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 qu'à l'avenir des concepts tels que SCTP seront pris dans un endroit plus intéressant, où les connexions liées (ou les connexions fibre canalisées par spectre interne) sont typiques, et chaque canal peut recevoir un flux indépendant des autres, et chaque le flux peut être compressé/chiffré en parallèle, etc. etc. Ce serait merveilleux! Mais ce n'est pas le cas aujourd'hui en 2015, et bien que fantasmer et théoriser soit agréable, la plupart d'entre nous n'ont pas de clusters de stockage personnalisés fonctionnant dans une cryo-chambre 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 de manière exhaustive notre charge utile de données pour déterminer si la compression est une bonne idée ou non - le transfert lui-même serait terminé avant de terminer notre analyse, quelle que soit la gravité de la méthode choisie.
Mais...
Les temps changent et ma recommandation contre la compression et le chiffrement ne tiendra pas. J'aimerais vraiment que ce conseil soit renversé dans le cas typique très bientôt. Cela me faciliterait la vie.
Un outil astucieux que j'ai utilisé dans le passé est bbcp. Comme on le voit 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 un premier passage d'une manière ou d'une autre (via le fil/sneakernet/peu importe), vous pouvez examiner rsync avec certaines options qui peuvent accélérer considérablement les transferts ultérieurs. Une très bonne façon de procéder serait:
rsync -varzP sourceFiles destination
Les options sont: verbeux, mode archive, récursif, compresser, Progression partielle
Ajouté sur l'insistance de l'affiche originale dans les commentaires à la réponse de zackse, bien que je ne suis pas sûr que ce soit le plus rapide dans des circonstances typiques.
bash a une syntaxe de redirection spéciale:
Pour la sortie: > /dev/tcp/ [~ # ~] ip [~ # ~]/ port
Pour la saisie: < /dev/tcp/ [~ # ~] ip [~ # ~]/ port
[~ # ~] ip [~ # ~] interdire soit une IP décimale en pointillés, soit un nom d'hôte; port ban soit un nombre décimal soit 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 à bash de créer un socket TCP, connectez-le à la destination spécifiée, puis faites la même chose qu'une redirection de fichier habituelle (à savoir, remplacez le flux standard respectif par le socket à l'aide de dup2 (2)).
Par conséquent, on peut diffuser des données depuis dd ou tar sur la machine source directement via TCP. Ou, inversement, pour diffuser des données vers tar ou quelque chose de similaire directement via TCP. Dans tous les cas, un netcat superflu est éliminé.
Notes sur netcat
Il y a ne incohérence dans la syntaxe entre netcat classique et GNU netcat . J'utiliserai la syntaxe classique à laquelle je suis habitué. Remplacer -lp avec -l pour GNU netcat.
De plus, je ne sais pas si GNU netcat accepte -q commutateur.
Transfert d'une image disque
(Dans le sens de la réponse de Zackse.)
À destination:
nc -lp 9999 >disk_image
À la source:
dd if=/dev/sda >/dev/tcp/destination/9999
Création d'une archive tar.gz, avec tar
À destination:
nc -lp 9999 >backup.tgz
À la source:
tar cz files or directories to be transferred >/dev/tcp/destination/9999
Remplacer .tgz avec .tbz et cz avec cj pour obtenir un bzip2- archive compressée.
Transfert avec extension immédiate vers le système de fichiers
Aussi avec tar.
À destination:
cd backups
tar x </dev/tcp/destination/9999
À la 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 l'explication de la syntaxe et des mises en garde de tar. S'il existe de nombreux fichiers avec une redondance élevée (faible entropie), la compression (par exemple cz et xz au lieu de c et x) peut être essayé, mais si les fichiers sont typiques et que le réseau est assez rapide, cela ne ferait que ralentir le processus. Voir la réponse de mikeserv pour plus de détails sur la compression.
Style alternatif (le port d'écoute de destination)
À destination:
cd backups
nc -lp 9999 |tar x
À la source:
tar c files or directories to be transferred >/dev/tcp/destination/9999
Essayez les suggestions concernant les connexions directes et en évitant les protocoles chiffrés tels que ssh. Ensuite, si vous voulez toujours tirer le meilleur parti de la performance, lisez ce site: https://fasterdata.es.net/Host-tuning/linux/ pour quelques conseils sur l'optimisation de votre TCP fenêtres.
Si le budget n'est pas la principale préoccupation, vous pouvez essayer de connecter les disques avec un "connecteur de lecteur" Intel Xeon E5 12 cœurs. Ce connecteur est généralement si puissant que vous pouvez même y exécuter votre logiciel serveur actuel. Des deux serveurs!
Cela peut sembler une réponse amusante, mais vous devriez vraiment réfléchir à la raison pour laquelle vous déplacez les données entre les serveurs et si un gros avec mémoire et stockage partagés pourrait avoir plus de sens.
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?
J'utiliserais ce script J'ai écrit qui a besoin du package socat.
Sur la machine source:
tarnet -d wherefilesaretosend pass=none 12345 .
Sur la machine cible:
tarnet -d wherefilesaretogo pass=none sourceip/12345
Si le package vbuf (Debian, Ubuntu) est là, l'expéditeur du fichier affichera une progression des données. Le récepteur de fichiers montrera quels fichiers sont reçus. L'option pass = peut être utilisée là où les données peuvent être exposées (plus lentement).
Modifier:
Utilisez le -n option pour désactiver la compression, si le CPU est un goulot d'étranglement.
Je vais vous recommander de regarder NIC-teaming. Cela implique l'utilisation de plusieurs connexions réseau fonctionnant en parallèle. En supposant que vous ayez vraiment besoin de plus de 1 Go de transfert et que 10 Go sont prohibitifs, 2 Go fournis par l'association de cartes réseau seraient un coût mineur et vos ordinateurs pourraient déjà avoir les ports supplémentaires.
Plusieurs personnes recommandent d'ignorer ssh car le chiffrement vous ralentira. Les processeurs modernes peuvent en fait être assez rapides à 1 Go, mais OpenSSH a des problèmes avec son implémentation de fenêtrage interne qui peut considérablement vous ralentir.
Si vous voulez le faire avec ssh, jetez un œil à HPN SSH . Il résout les problèmes de fenêtrage et ajoute un chiffrement multithread. Malheureusement, vous devrez reconstruire ssh sur le client et le serveur.
FWIW, j'ai toujours utilisé ceci:
tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"
La chose à propos de 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) (Je fais généralement cela pour copier des images de disque virtuel car je peux utiliser un paramètre -S pour gérer des fichiers clairsemés. )
Je viens de tester cela entre deux serveurs occupés et de gérer ~ 14 Go en 216 s (environ 64 Mo/s) - pourrait mieux faire entre les machines dédiées et/ou la 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
Quel que soit le programme, j'ai généralement constaté que "tirer" des fichiers sur un réseau est plus rapide que "pousser". Autrement dit, la connexion à l'ordinateur de destination et la lecture sont plus rapides que la connexion à l'ordinateur source et l'écriture.
De plus, si vous prévoyez d'utiliser un lecteur intermédiaire, pensez à ceci: procurez-vous un lecteur externe (soit en tant que package, soit un lecteur séparé branché sur une station d'accueil) qui utilise eSATA plutôt que USB. Ensuite, sur chacun des deux ordinateurs, installez une carte avec un port eSATA ou procurez-vous un simple câble adaptateur qui amène l'un des ports SATA internes à un connecteur eSATA externe. Ensuite, branchez le lecteur sur l'ordinateur source, mettez-le sous tension et attendez qu'il se monte automatiquement (vous pouvez le monter correctement, mais si vous le faites à plusieurs reprises, vous pouvez tout aussi bien le mettre dans votre fichier fstab). Copiez ensuite; vous écrirez à la même vitesse que sur un lecteur interne. Démontez ensuite le lecteur, mettez-le hors tension, branchez-le sur l'autre ordinateur, mettez-le sous tension, attendez un montage automatique et lisez.
À moins que vous ne vouliez faire de la criminalistique du système de fichiers, utilisez un programme de vidage/restauration pour votre système de fichiers pour éviter de copier l'espace libre que le FS n'utilise pas. En fonction du système de fichiers que vous avez, cela conservent généralement tous les métadonnées, y compris ctime. les nombres d'inodes peuvent changer, cependant, encore une fois selon le système de fichiers (xfs, ext4, ufs ...).
La cible de restauration peut être un fichier sur le système cible.
Si vous voulez une image disque complète avec la table de partition, vous pouvez dd le premier 1M du disque pour obtenir la table de partition/bootloaders/stuff, mais ensuite xfsdump les partitions.
Je ne peux pas dire à partir de votre info-dump quel type de système de fichiers vous avez réellement. Si c'est BSD ufs, alors je pense qu'il a un programme de vidage/restauration. Si c'est ZFS, eh bien IDK, il pourrait y avoir quelque chose.
En règle générale, la copie complète des disques est trop lente pour quoi que ce soit, à l'exception des situations de récupération. Vous ne pouvez pas non plus effectuer de sauvegardes incrémentielles de cette façon.
Que diriez-vous d'un câble croisé Ethernet? Au lieu de compter sur des vitesses sans fil, vous êtes limité à la vitesse filaire de votre carte réseau.
Voici une question similaire avec quelques exemples de ce type de solution.
Apparemment, un simple câble Ethernet suffit de nos jours. De toute évidence, mieux votre NIC plus le transfert est rapide).
Pour résumer, si une configuration réseau est nécessaire, elle doit se limiter à simplement définir des 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
Si vous ne vous souciez que des sauvegardes, et non d'un octet pour une copie d'octets du disque dur, alors je recommanderais backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html C'est un peu pénible à installer mais ça se transfère très rapidement.
Mon temps de transfert initial pour environ 500 G de données était d'environ 3 heures. Les sauvegardes suivantes se produisent en 20 secondes environ.
Si vous n'êtes pas intéressé par les sauvegardes, mais que vous essayez de synchroniser les choses, alors rsync ou unisson répondrait mieux à vos besoins.
Un octet pour une copie octet d'un disque dur est généralement une idée horrible à des fins de sauvegarde (pas d'incrémentiels, pas d'économie d'espace, le lecteur ne peut pas être utilisé, vous devez sauvegarder "l'espace vide" et vous devez sauvegarder les déchets (comme un fichier d'échange de 16 G ou 200 G de vidages de mémoire ou certains autres). En utilisant rsync (ou backuppc ou autres), vous pouvez créer des "instantanés" à temps afin 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 l'obtention de données depuis le lecteur. Sans 400G de RAM un transfert de fichier de 320G va prendre un temps très long. Utiliser des protocoles qui ne sont pas cryptés est une option, mais quoi qu'il en soit, vous devrez simplement rester assis là et attendez plusieurs heures (sur le réseau).
Vous pouvez également configurer les systèmes pour avoir un stockage partagé!
Je considère que ceux-ci sont côte à côte, et vous risquez de le faire encore et encore ...
OK, j'ai essayé de répondre à cette question pour deux ordinateurs avec des "très gros tuyaux" (10Gbe) qui sont "proches" l'un de l'autre.
Le problème que vous rencontrez ici est: la plupart des compressions goulot d'étranglement au niveau du processeur, car les tuyaux sont si gros.
performances pour transférer un fichier de 10 Go (connexion réseau 6 Go [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îtiers sur 10 Gbe, versions légèrement plus anciennes de netcat (CentOs 6.7), fichier 10GB:
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, sur une instance, netcat a utilisé moins de CPU, sur l'autre socat, 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 comme "-w 10" peuvent également entraîner des fichiers tronqués.
Ce qui se passe dans presque tous ces cas, c'est que le processeur est au maximum, pas le réseau. scp atteint un maximum d'environ 230 Mo/s, fixant un cœur à 100% d'utilisation.
Iperf3 crée malheureusement des fichiers corrompus . Certaines versions de netcat semblent ne pas transférer l'intégralité du fichier, très bizarre. Surtout des versions plus anciennes de celui-ci.
Diverses incantations de "gzip comme un tuyau vers netcat" ou "mbuffer" semblaient également maximiser le processeur avec le gzip ou le mbuffer, donc n'entraînaient pas un transfert plus rapide avec des tuyaux aussi gros. lz4 pourrait aider. De plus, certains des trucs de tuyaux gzip que j'ai tentés ont entraîné des transferts corrompus pour les très gros fichiers (> 4 Go), alors faites attention là-bas :)
Une autre chose qui pourrait fonctionner en particulier pour une latence plus élevée (?) Est de régler 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 de une autre réponse) éventuellement des paramètres IRQ: https://fasterdata.es.net/Host-tuning/100g-tuning/
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
vaut la peine de vérifier après avoir peaufiné pour s'assurer que les changements ne causent pas trop de dommages.
Il peut également être utile de régler la taille de la fenêtre: https://iperf.fr/iperf-doc.php#tuningtcp
Avec des connexions lentes (er), la compression peut certainement aider. Si vous avez de gros tuyaux, une compression très rapide pourrait aider avec des données facilement compressibles, je ne l'ai pas essayé.
La réponse standard pour "synchroniser les disques durs" est de resynchroniser les fichiers, ce qui évite le transfert lorsque cela est possible.
Une autre option: utilisez "parallèle scp" (d'une manière ou d'une autre), alors il utilisera plus de cœurs ...