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

J'ai envoyé une grande quantité de données d'une machine à une autre. Si j'envoie avec rsync (ou toute autre méthode), il ira à 320kb / sec. Si j'initie deux ou trois transferts à la fois, chacun ira à 320, et si j'en fais quatre à la fois, ils maximiseront le lien.

Je dois être en mesure d'envoyer des données aussi rapidement que possible, j'ai donc besoin d'un outil capable de faire du multiplexage inverse avec des transferts de fichiers. J'ai besoin d'une solution générale, il n'est donc pas pratique d'exécuter le fractionnement sur la machine source et de les regrouper à l'autre extrémité. J'ai besoin de cela pour travailler de manière automatisée.

Existe-t-il un outil qui fait cela, ou dois-je créer le mien? L'expéditeur est CentOS, le récepteur est FreeBSD.

La preuve que tout cela s'additionne - je présente le «Saint-Graal» des commandes de miroir à distance. Merci à davr pour la lftpsuggestion.

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

Ce qui précède reflétera récursivement un répertoire distant, divisant chaque fichier en 10 threads lors de son transfert!

Il existe quelques outils qui pourraient fonctionner.

• LFTP - prend en charge FTP, HTTP et SFTP. Prend en charge l'utilisation de plusieurs connexions pour télécharger un seul fichier. 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 de nombreux outils d'accélérateur de téléchargement, mais ils ne prennent généralement en charge que HTTP ou FTP, que vous ne voudrez peut-être pas configurer sur le serveur distant. Quelques exemples sont Axel , aria2 et ProZilla

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

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

Vous pouvez utiliser --continuepour reprendre le travail :) et l' -Roption de télécharger au lieu de télécharger (puis basculer l'ordre des arguments sur <local_dir> <remote_dir>).

Vous pourrez peut-être modifier vos paramètres TCP pour éviter ce problème, en fonction de la cause de la limite de connexion de 320 Ko / s. Je suppose que ce n'est pas une limitation explicite du débit par connexion par le FAI. Il y a deux coupables probables pour la limitation:

1. Un lien entre les deux machines est saturé et laisse tomber des paquets.
2. Les fenêtres TCP sont saturées car le produit de retard de bande passante est trop important.

Dans le premier cas, chaque connexion TCP concurrencerait efficacement le contrôle de congestion TCP standard. Vous pouvez également améliorer cela en modifiant les algorithmes de contrôle de congestion ou en réduisant la quantité d'interruption.

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

Vous pouvez déterminer approximativement la taille de la fenêtre en multipliant le temps de "ping" aller-retour par la vitesse totale de la connexion. 1280 Ko / s nécessitent 1280 (1311 pour 1024 = 1 Ko) octets par milliseconde d'aller-retour. Un tampon de 64 Ko sera maximisé à environ 50 ms de latence, ce qui est assez typique. Un tampon de 16 Ko saturerait alors environ 320 Ko / s.

Comment vos données sont-elles structurées? Quelques gros fichiers? Quelques gros répertoires? 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 source sont structurées. Il existe des tonnes d'outils Unix pour découper, découper et réassembler des fichiers.

Si vous pouvez configurer une connexion ssh sans mot de passe, cela ouvrira 4 connexions scp simultanées (-n) avec chaque connexion gérant 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 l'inode (find / mydir -type f -print | xargs ls -i | sort -n) et transférez-les avec par exemple cpio sur ssh. Cela maximisera votre disque et fera du réseau votre goulot d'étranglement. Plus rapide que cela, il est difficile d'aller lorsque vous traversez un réseau.

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

Vous pouvez créer des scripts bash simples pour automatiser la création de fichiers "* .torrent" et envoyer une commande ssh à la machine distante afin qu'elle la télécharge. 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 pouvoir maximiser votre lien réseau. (Notez que des considérations spéciales sont requises 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 qui prend en charge plusieurs connexions, mais je ne sais pas si SFTP prend en charge plusieurs connexions pour un seul fichier. Cela devrait faire ce dont vous avez besoin la plupart du temps, mais peut ne pas vous donner le débit maximal lorsque vous ne devez transférer qu'un seul fichier volumineux.

Solution 1: je ne sais pas si cela est pratique dans votre cas, mais vous pouvez créer une archive fractionnée (par exemple, un fichier tar divisé en morceaux ou une archive 7zip fractionnée), puis utiliser plusieurs instances de rsync pour les envoyer le réseau et les remonter / 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 aurez la surcharge supplémentaire 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 la grande arborescence de répertoires en sous-arbres en fonction de la taille, puis copie ces sous-arbres en parallèle. Cela pourrait simplifier les choses si vous copiez d'abord la structure complète du répertoire (sans les fichiers).

Êtes-vous deux machines fonctionnant dans un environnement de confiance? Vous pouvez essayer netcat . Côté serveur:

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

et sur le client:

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

Vous pouvez demander à la connexion client d'utiliser 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é qui soit, mais dans le bon environnement, il peut être rapide car il a des frais généraux si bas.

HowtoForge a une bonne page d'exemples .