Multiplexage inverse pour accélérer le transfert de fichiers

Tout cela s'ajoute: je présente le «saint graal» des commandes miroir à distance. Merci à davr pour la suggestion lftp .

 lftp -c "mirror --use-pget-n=10 --verbose sftp://username:[email protected]/directory" 

Ce qui précède reflètera de manière récursive un répertoire distant, en séparant chaque fichier en 10 threads lorsqu'il est transféré!

Il y a quelques outils qui pourraient fonctionner.

• LFTP – prend en charge FTP, HTTP et SFTP. Supporte l'utilisation de connexions multiples pour télécharger un fichier unique. En supposant que vous souhaitez transférer un fichier de remoteServer vers localServer, installez LFTP sur localServer et exécutez:

  lftp -e 'pget -n 4 sftp://[email protected]/some/dir/file.ext'

  Le '-n 4' est le nombre de connexions à utiliser en parallèle.

• Ensuite, il existe les nombreux outils d'accélérateur de téléchargement, mais ils ne supportent généralement que HTTP ou FTP, ce que vous ne devriez peut-être pas configurer sur le serveur distant. Quelques exemples sont Axel , aria2 et ProZilla

Si vous avez des fichiers peu ou grands, utilisez lftp -e 'mirror --parallel=2 --use-pget-n=10 <remote_dir> <local_dir>' <ftp_server> : vous allez télécharger 2 fichiers avec chaque fichier divisé en 10 segments Avec un total de 20 connexions ftp à <ftp_server> ;

Si vous disposez d'une grande quantité de petits fichiers, utilisez lftp -e 'mirror --parallel=100 <remote_dir> <local_dir>' <ftp_server> : vous téléchargez 100 fichiers en parallèle sans segmentation, puis. Un total de 100 connexions seront ouvertes. Cela peut exoust les clients disponibles sur le serveur, ou peut vous interdire sur certains serveurs.

Vous pouvez utiliser – --continue de reprendre le travail 🙂 et l'option -R à télécharger au lieu de télécharger (puis passer l'ordre des arguments à <local_dir> <remote_dir> ).

Comment vos données sont-elles structurées? Quelques fichiers importants? Quelques répertoires importants? Vous pouvez générer plusieurs instances de rsync sur des branches spécifiques de votre arborescence de répertoires.

Tout dépend de la façon dont vos données sources sont structurées. Il existe des tonnes d'outils Unix pour découper, couper et rassembler des fichiers.

Vous pouvez modifier vos paramètres TCP pour éviter ce problème, en fonction de ce qui entraîne la limite de connexion de 320 Ko / s. Je suppose que ce n'est pas une limitation explicite par limite de connexion par le FAI. Il y a deux coupables possibles pour l'étranglement:

1. Certains liens entre les deux machines sont saturés et déposent des paquets.
2. Les fenêtres TCP sont saturées car le produit à retard de bande passante est trop grand.

Dans le premier cas, chaque connexion TCP serait effectivement concurrencé de manière égale dans le contrôle de congestion TCP standard. Vous pourriez également améliorer cela en changeant les algorithmes de contrôle de congestion ou en réduisant la quantité de backoff.

Dans le deuxième cas, vous n'êtes pas limité par une perte de paquets. L'ajout de connexions supplémentaires est un moyen brut d'étendre la taille totale de la fenêtre. Si vous pouvez augmenter manuellement les tailles des fenêtres, le problème disparaîtra. (Cela pourrait exiger la mise à l'échelle de la fenêtre TCP si la latence de la connexion est suffisamment élevée).

Vous pouvez indiquer approximativement la grandeur de la fenêtre en multipliant le temps de "ping" par la vitesse totale de la connexion. 1280KB / s a ​​besoin de 1280 (1311 pour 1024 = 1K) octets par milliseconde de trajet aller-retour. Un tampon de 64 Ko sera dépassé à environ 50 ms de latence, ce qui est assez typique. Un tampon 16K saturerait environ 320KB / s.

Si vous pouvez configurer la connexion ssh sans mot de passe, cela ouvrira 4 connexions scp simultanées (-n) à chaque connexion traitant 4 fichiers (-L):

trouver . -type f | Xargs -L 4 -n 4 /tmp/scp.sh user @ host: chemin

Fichier /tmp/scp.sh:

 #!/bin/bash #Display the help page function showHelp() { echo "Usage: $0 <destination> <file1 [file2 ... ]>" } #No arguments? if [ -z "$1" ] || [ -z "$2" ]; then showHelp exit 1 fi #Display help? if [ "$1" = "--help" ] || [ "$1" = "-h" ]; then showHelp exit 0 fi #Programs and options SCP='scp' SCP_OPTS='-B' DESTINATION="$1";shift; #Check other parameters if [ -z "$DESTINATION" ]; then showHelp exit 1 fi echo "$@" #Run scp in the background with the remaining parameters. $SCP $SCP_OPTS $@ $DESTINATION & 

Essayez de trier tous les fichiers sur inode (trouver / mydir -type f -print | xargs ls -i | sort -n) et les transférer avec par exemple cpio sur ssh. Cela augmentera votre disque et fera du réseau votre goulot d'étranglement. Plus vite que ça, il est difficile d'y aller en passant par le réseau.

Je connais un outil qui peut transférer des fichiers en morceaux. L'outil s'appelle 'rtorrent' package / port qui est disponible sur les deux hôtes;) Les clients BitTorrent souvent réservent de l'espace disque avant le transfert, et les morceaux sont écrits directement depuis les sockets vers le disque. De plus, vous pourrez passer en revue les états de tous les transferts dans un bon écran ncurses.

Vous pouvez créer des scripts Bash simples pour automatiser la création de fichier "* .torrent" et une commande ssh a vers la machine distante afin de la télécharger. Cela semble un peu moche, mais je ne pense pas que vous trouverez une solution simple sans développer 🙂

FTP utilise plusieurs connexions pour les téléchargements. Si vous pouvez configurer un canal sécurisé pour FTP sur un VPN ou FTP sur SSH , vous devriez maximiser votre lien réseau. (Notez que des considérations spéciales sont nécessaires pour FTP sur SSH – voir le lien.)

FTPS (FTP sur SSL) peut également faire ce dont vous avez besoin.

Vous pouvez également utiliser un client SFTP prenant en charge plusieurs connexions, mais je ne sais pas si SFTP supporte plusieurs connexions pour un seul fichier. Cela devrait faire ce dont vous avez besoin la plupart du temps, mais vous ne pouvez pas vous donner le débit maximum lorsque vous ne devez transférer qu'un seul fichier de grande taille.

Solution 1: je ne sais pas si cela est pratique dans votre cas, mais vous pouvez créer une archive étendue (par exemple, un fichier tarfile en morceaux ou une archive 7zip étendue), puis utilisez plusieurs instances de rsync pour les envoyer Le réseau et les remonter / les extraire de l'autre côté. Vous pouvez écrire un script à usage général dont les arguments sont le répertoire à transférer et le nombre de connexions à utiliser. L'inconvénient évident est que vous aurez besoin de deux fois plus d'espace libre des deux côtés, et que vous disposerez des frais généraux additionnels d'archivage / extraction des fichiers aux deux extrémités.

Solution 2: une meilleure solution serait d'écrire un script ou un programme qui divise l'arborescence du répertoire en sous-arborescence en fonction de la taille, puis copie ces sous-arborescences en parallèle. Cela pourrait simplifier les choses si vous copiez d'abord la structure de répertoire entière (sans les fichiers).

Vous deux machines fonctionnant dans un environnement de confiance? Vous pouvez essayer netcat . Du côté du serveur:

 tar -czf - ./yourdir | nc -l 9999 

Et sur le client:

 nc your.server.net 9999 > yourdir.tar.gz 

Vous pouvez utiliser la connexion client à l'aide d'un tunnel ssh:

 ssh -f -L 23333:127.0.0.1:9999 [email protected] sleep 10; \ nc 127.0.0.1 23333 > yourdir.tar.gz 

Même une partition entière peut être déplacée de cette façon:

 dd if=/dev/sda1 | gzip -9 | nc -l 9999 

Et sur le client:

 nc your.server.net 9999 > mysda1.img.gz 

.

Remarque

Netcat n'est pas l'outil de transfert le plus sécurisé là-bas, mais dans le bon environnement, il peut être rapide car il a une surcharge trop faible.

HowtoForge a une bonne page d'exemples .