Quelle est la meilleure façon de transférer un seul fichier volumineux sur une liaison WAN haut débit et à latence élevée?

21

Cela semble lié à celui-ci , mais c'est quelque peu différent.

Il existe ce lien WAN entre deux sites de l'entreprise et nous devons transférer un seul fichier très volumineux (vidage Oracle, ~ 160 Go).

Nous avons une bande passante complète de 100 Mbps (testée), mais il semble qu'une seule connexion TCP ne puisse tout simplement pas la maximiser en raison du fonctionnement de TCP (ACK, etc.). Nous avons testé le lien avec iperf , et les résultats changent considérablement lors de l'augmentation de la taille de la fenêtre TCP: avec les paramètres de base, nous obtenons un débit de ~ 5 Mbps, avec un WS plus grand, nous pouvons obtenir jusqu'à ~ 45 Mbps, mais pas plus. La latence du réseau est d'environ 10 ms.

Par curiosité, nous avons exécuté iperf en utilisant plusieurs connexions, et nous avons constaté qu'en exécutant quatre d'entre elles, elles atteindraient en effet une vitesse de ~ 25 Mbps chacune, remplissant toute la bande passante disponible; de sorte que la clé semble être d'exécuter plusieurs transferts simultanés.

Avec FTP, les choses empirent: même avec des paramètres TCP optimisés (taille de fenêtre élevée, MTU max, etc.), nous ne pouvons pas obtenir plus de 20 Mbps sur un seul transfert. Nous avons essayé de FTPer de gros fichiers en même temps, et en effet les choses se sont beaucoup améliorées que lors du transfert d'un seul; mais le coupable est devenu E / S disque, car très bientôt la lecture et l'écriture de quatre gros fichiers à partir des mêmes goulots d'étranglement de disque; De plus, nous ne semblons pas être en mesure de diviser ce grand fichier unique en plus petits, puis de le fusionner à nouveau, du moins pas dans des délais acceptables (évidemment, nous ne pouvons pas dépenser l'épissage / la fusion du fichier à un moment comparable à celui de le transférer).

La solution idéale ici serait un outil multithread qui pourrait transférer plusieurs morceaux du fichier en même temps; un peu comme des programmes peer-to-peer comme eMule ou BitTorrent le font déjà, mais d'une seule source à une seule destination. Idéalement, l'outil nous permettrait de choisir le nombre de connexions parallèles à utiliser, et bien sûr d'optimiser les E / S disque pour ne pas (trop) sauter follement entre les différentes sections du fichier.

Quelqu'un connaît-il un tel outil?

Ou, quelqu'un peut-il suggérer une meilleure solution et / ou quelque chose que nous n'avons pas déjà essayé?

PS Nous avons déjà pensé à sauvegarder cela sur bande / disque et à l'envoyer physiquement à destination; ce serait notre mesure extrême si le WAN ne le coupe pas, mais, comme l'a dit AS Tanenbaum, "Ne sous-estimez jamais la bande passante d'un break rempli de bandes qui dévalent l'autoroute."

networking bandwidth tcp file-transfer Massimo
la source
1
Par curiosité, le temps que cela prend est-il vraiment critique? De plus, la saturation du lien pendant la durée d'un transfert de 160 Go n'aurait-elle pas un impact sur le reste de votre réseau?
Bryan
6
Je me souviens avoir livré des chargeurs automatiques DLT et quelques centaines de cartouches à un client en 1999. Nous avons calculé la capacité brute de ma voiture avec environ 200 cartouches DLT IV chargées (35 Go de capacité brute chacune) à environ 6,3 To. J'ai conduit de notre bureau au site du client en environ 55 minutes, donnant au mécanisme de transport de secours «Evan dans un Geo Metro conduisant comme un fou de l'Interstate» un débit effectif d'environ 118 Go / min. Bon débit, mais la latence a été un tueur ...> sourire <
Evan Anderson
Bryan: oui, le temps est critique (cela prend environ VINGT HEURES avec le FTP standard et les paramètres réseau standard), et non, il n'y aura aucun problème à saturer le lien, car le transfert sera planifié en dehors du travail.
Massimo
Evan: c'est exactement ce que je voulais dire ;-)
Massimo
J'ai eu affaire à une situation similaire, avec environ 200 Go de SQL .bak, sauf que la seule façon dont j'ai pu obtenir le lien WAN pour saturer est avec FTP. J'ai fini par utiliser 7-zip sans compression pour le diviser en morceaux de 512 Mo. Les temps de «compression» et de «décompression» étaient agréablement courts; dans l'ensemble beaucoup mieux que de pelleter les médias physiques à travers le pays. (Les sites sont situés sur des côtes opposées des États-Unis)
Adrien

Réponses:

15

La recherche de "transfert de fichiers à latence élevée" fait apparaître de nombreux résultats intéressants. De toute évidence, c'est un problème dans lequel la communauté CompSci et la communauté commerciale se sont penchées.

Quelques offres commerciales qui semblent correspondre à la facture:

  • FileCatalyst propose des produits qui peuvent diffuser des données sur des réseaux à latence élevée en utilisant UDP ou plusieurs flux TCP. Ils ont aussi beaucoup d'autres fonctionnalités (compression à la volée, transferts delta, etc.).

  • La «technologie» de transfert de fichiers fasp d'Aspera semble également convenir à ce que vous recherchez.

Dans le monde open-source, le projet uftp semble prometteur. Vous n'avez pas particulièrement besoin de ses capacités de multidiffusion, mais l'idée de base de dynamiter un fichier vers les récepteurs, de recevoir des NAK pour les blocs manqués à la fin du transfert, puis de dynamiter les blocs NAK (mousser, rincer, répéter) semble qu'il ferait ce dont vous avez besoin, car il n'y a pas d'accusé de réception (ou de NAK) du récepteur tant que le transfert de fichier n'est pas terminé une fois. En supposant que le réseau est juste latent et non avec perte, cela pourrait aussi faire ce dont vous avez besoin.

Evan Anderson
la source
uftp semble vraiment prometteur, j'ai pu atteindre 30 Mbps entre deux ordinateurs de bureau (qui ne sont certainement pas excellents en termes de performances de disque); Je vais bientôt le tester sur les "vrais" serveurs. Je n'ai pas pu obtenir une licence de démonstration FileCatalyst en raison d'un bogue dans le formulaire d'inscription (il continue de dire que le numéro de demande a déjà été utilisé), et fasp ne les propose tout simplement pas.
Massimo
60 Mbps entre deux ordinateurs avec des disques appropriés et un grand tampon de réception. Génial!
Massimo
J'adore les logiciels libres / open source! > sourire <je vais certainement essayer uftp avec des trucs que je fais. Je me demande comment cela fonctionnerait dans une solution d'imagerie de disque multicast basée sur Linux que j'ai créée il y a quelques années en utilisant "udpcast".
Evan Anderson
il y a quelque temps, j'ai demandé à serverfault.com/questions/173358/multicast-file-transfers Finalement, je suis arrivé à la conclusion que uftp et mrsync étaient les outils de choix. Veuillez poster dans les commentaires là-bas si vous faites quoi que ce soit d'utile avec l'uftp, car j'utiliserai à nouveau l'un ou l'autre cette année (préparation pour une conférence).
Jed Daniels
2
Lorsque je travaillais avec UFTP, UDT et Tsunami UDP, UFTP avait la pire performance des trois. Bien sûr, c'est probablement le protocole le plus mature. UDT ne fournit qu'un simple protocole de transfert et a été conçu pour servir de bibliothèque pour développer des logiciels personnalisés et l'auteur de Tsunami nous a en fait pointé vers UDT car Tsunami n'a pas été développé activement récemment par manque de temps.
Thomas Owens
9

Suggestion vraiment étrange celle-ci .. Mettre en place un simple serveur Web pour héberger le fichier sur votre réseau (je suggère nginx, soit dit en passant), puis configurer un PC avec Firefox à l'autre extrémité, et installer l' extension DownThemAll .

Il s'agit d'un accélérateur de téléchargement qui prend en charge la segmentation et le réassemblage.
Vous pouvez diviser chaque téléchargement en 10 morceaux pour le réassemblage, et cela rend les choses plus rapides!

(mise en garde: je ne l'ai jamais essayé sur quelque chose d'aussi gros que 160 Go, mais cela fonctionne bien avec des fichiers iso de 20 Go)

Tom O'Connor
la source
40 Mbps entre les mêmes ordinateurs. Ça a l'air vraiment bien aussi.
Massimo
1
remplacez firefox par axel.alioth.debian.org et ce n'est pas si mal qu'une suggestion.
Justin
7

Le transport UDT est probablement le transport le plus populaire pour les communications à latence élevée. Cela mène à leur autre logiciel appelé Sector / Sphère, un «système de fichiers distribués haute performance et moteur de traitement de données parallèle» qui pourrait valoir la peine d'être examiné.

Steve-o
la source
1
J'ai travaillé avec UDT pour les transferts sur des réseaux avec une latence élevée et une perte de paquets élevée. L'UDT résiste beaucoup mieux à la latence et à la perte de paquets que les protocoles basés sur TCP, en particulier une fois que vous avez décidé de modifier l'algorithme de contrôle de congestion pour l'adapter à la topographie de votre réseau.
Thomas Owens
Il existe même une version de rsync avec UDT intégré, elle s'appelle "UDR". github.com/LabAdvComp/UDR
Max
5

Ma réponse est un peu tardive, mais je viens de trouver cette question, en cherchant du fasp. Au cours de cette recherche, j'ai également trouvé ceci: http://tsunami-udp.sourceforge.net/ , le "Tsunami UDP Protocol".

Depuis leur site Web:

Un protocole de transfert de fichiers rapide dans l'espace utilisateur qui utilise le contrôle TCP et les données UDP pour le transfert sur des réseaux longue distance à très haut débit (≥ 1 Gbit / s et même 10 GE), conçu pour fournir plus de débit que possible avec TCP sur les mêmes réseaux. les réseaux.

En ce qui concerne la vitesse, la page mentionne ce résultat (en utilisant un lien entre Helsinki, Finlande à Bonn, Allemagne via un lien 1 Go:

Figure 1 - Transfert international sur Internet, en moyenne 800 Mbit / seconde

Si vous souhaitez utiliser un accélérateur de téléchargement, jetez un œil à lftp, c'est le seul accélérateur de téléchargement qui peut faire un miroir récursif, pour autant que je sache.

Jan van Haarst
la source
1
Dans le projet que j'ai commenté plus tôt dans la réponse de Steve-o, nous avons comparé UDT, Tsunami UDP et UFTP. Nous avons constaté que la latence avait un impact énorme sur les performances, contrairement à la perte de paquets (contrairement à la documentation du tsunami). L'ajout de 100 ms de latence au réseau de test a fait chuter les performances de Tsunami d'environ 250 Mbits / seconde à environ 50 Mbits / seconde (je pense avoir mes chiffres et mes unités corrects - cela fait longtemps, mais ce fut une énorme baisse). L'ajout de 10% de perte de paquets sans réseau de latence minimale, en revanche, n'a fait que réduire les performances de 250 Mbits / seconde à environ 90 Mbits / seconde.
Thomas Owens