Multiplo inverso per velocizzare il trasferimento dei file

Ho inviato una grande quantità di dati da una macchina all'altra. Se invio con rsync (o qualsiasi altro metodo), andrà a 320kb / sec costanti. Se inizio due o tre trasferimenti contemporaneamente, ciascuno andrà a 320 e se ne eseguo quattro contemporaneamente, massimizzeranno il collegamento.

Devo essere in grado di inviare i dati il ​​più velocemente possibile, quindi ho bisogno di uno strumento in grado di eseguire il multiplexing inverso con i trasferimenti di file. Ho bisogno di una soluzione generale, quindi eseguire la divisione sulla macchina sorgente e catturarli insieme dall'altra parte non è pratico. Ho bisogno di questo per funzionare in modo automatizzato.

Esiste uno strumento che lo fa o devo crearne uno mio? Il mittente è CentOS, il destinatario è FreeBSD.

La prova aggiunge tutto: presento il "santo graal" dei comandi remoti del mirror. Grazie a David per il lftpsuggerimento.

lftp -c "mirror --use-pget-n=10 --verbose sftp://username:password@server.com/directory" 

Quanto sopra rispecchierà ricorsivamente una directory remota, suddividendo ogni file in 10 thread durante il trasferimento!

Ci sono un paio di strumenti che potrebbero funzionare.

• LFTP : supporta FTP, HTTP e SFTP. Supporta l'utilizzo di più connessioni per scaricare un singolo file. Supponendo di voler trasferire un file da remoteServer a localServer, installare LFTP su localServer ed eseguire:

  lftp -e 'pget -n 4 sftp://userName@remoteServer.com/some/dir/file.ext'

  '-N 4' è il numero di connessioni da utilizzare in parallelo.

• Quindi ci sono molti strumenti di "acceleratore di download", ma generalmente supportano solo HTTP o FTP, che potresti non voler impostare sul server remoto. Alcuni esempi sono Axel , aria2 e ProZilla

Se hai pochi e grandi file da utilizzare lftp -e 'mirror --parallel=2 --use-pget-n=10 <remote_dir> <local_dir>' <ftp_server>: scaricherai 2 file con ogni file diviso in 10 segmenti con un totale di 20 connessioni ftp a <ftp_server>;

Se hai una grande quantità di piccoli file, usa lftp -e 'mirror --parallel=100 <remote_dir> <local_dir>' <ftp_server>: scaricherai 100 file in parallelo senza segmentazione, quindi. Verranno aperte in totale 100 connessioni. Questo può esaurire i client disponibili sul server o farti vietare su alcuni server.

È possibile utilizzare --continueper riprendere il lavoro :) e l' -Ropzione per caricare invece di scaricare (quindi cambiare l'ordine degli argomenti in <local_dir> <remote_dir>).

Potrebbe essere possibile modificare le impostazioni TCP per evitare questo problema, a seconda della causa del limite di connessione di 320 KB / s. La mia ipotesi è che è non è esplicito tariffa al collegamento limitando dall'ISP. Ci sono due probabili colpevoli per la limitazione:

1. Qualche collegamento tra le due macchine è saturo e fa cadere pacchetti.
2. Le finestre TCP sono saturate perché il prodotto di ritardo della larghezza di banda è troppo grande.

Nel primo caso ogni connessione TCP competerebbe, in modo efficace, allo stesso modo nel controllo di congestione TCP standard. Puoi anche migliorare questo modificando gli algoritmi di controllo del traffico o riducendo la quantità di backoff.

Nel secondo caso non sei limitato dalla perdita di pacchetti. L'aggiunta di connessioni extra è un modo rozzo di espandere la dimensione totale della finestra. Se è possibile aumentare manualmente le dimensioni della finestra, il problema scompare. (Ciò potrebbe richiedere il ridimensionamento della finestra TCP se la latenza della connessione è sufficientemente elevata.)

Puoi dire approssimativamente quanto deve essere grande la finestra moltiplicando il tempo di "ping" di andata e ritorno per la velocità totale della connessione. 1280 KB / s richiedono 1280 (1311 per 1024 = 1 KB) byte per millisecondo di andata e ritorno. Un buffer da 64 KB verrà massimizzato a circa 50 ms di latenza, il che è abbastanza tipico. Un buffer da 16 KB si saturerebbe quindi intorno a 320 KB / s.

Come sono strutturati i tuoi dati? Qualche file di grandi dimensioni? Qualche directory di grandi dimensioni? È possibile generare più istanze di rsync su rami specifici dell'albero della directory.

Tutto dipende da come sono strutturati i dati di origine. Ci sono tonnellate di strumenti unix per tagliare, tagliare e assemblare i file.

Se è possibile configurare il login ssh senza password, questo aprirà 4 connessioni scp simultanee (-n) con ogni connessione che gestisce 4 file (-L):

trova . -tipo f | xargs -L 4 -n 4 /tmp/scp.sh user @ host: percorso

File /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 &

Prova a ordinare tutti i file su inode (find / mydir -type f -print | xargs ls -i | sort -n) e trasferiscili con ad esempio cpio su ssh. Questo massimizzerà il tuo disco e renderà la rete il collo di bottiglia. Più veloce di così è difficile andare attraverso la rete.

Conosco uno strumento in grado di trasferire file in blocchi. Lo strumento è chiamato pacchetto / porta "rtorrent" disponibile su entrambi gli host;) I client BitTorrent spesso riservano spazio su disco prima del trasferimento e i blocchi vengono scritti direttamente dai socket sul disco. Inoltre, sarai in grado di rivedere TUTTI gli stati dei trasferimenti in una bella schermata di ncurses.

È possibile creare semplici script bash per automatizzare la creazione di file "* .torrent" e inviare un comando al computer remoto in modo da scaricarlo. Sembra un po 'brutto, ma non credo che troverai una soluzione semplice senza sviluppare :)

FTP utilizza più connessioni per i download. Se è possibile impostare un canale sicuro per FTP su VPN o FTP su SSH , si dovrebbe essere in grado di massimizzare il collegamento di rete. (Notare che sono necessarie considerazioni speciali per FTP su SSH - consultare il collegamento.)

FTPS (FTP over SSL) potrebbe anche fare ciò di cui hai bisogno.

Potresti anche utilizzare un client SFTP che supporta più connessioni, ma non sono sicuro che SFTP supporti più connessioni per un singolo file. Questo dovrebbe fare ciò di cui hai bisogno per la maggior parte del tempo, ma potrebbe non darti il ​​massimo throughput quando devi trasferire solo un file di grandi dimensioni.

Soluzione 1: non sono sicuro che questo sia pratico nel tuo caso, ma potresti creare un archivio con spanning (ad esempio un file tar diviso in blocchi o un archivio 7zip con spanning), quindi utilizzare più istanze di rsync per inviarle la rete e rimontarli / estrarli dall'altro lato. È possibile scrivere uno script generico i cui argomenti sono la directory da trasferire e il numero di connessioni da utilizzare. L'ovvio aspetto negativo è che avrai bisogno del doppio dello spazio libero su entrambi i lati e avrai il sovraccarico aggiuntivo di archiviare / estrarre i file su entrambe le estremità.

Soluzione 2: una soluzione migliore sarebbe quella di scrivere uno script o un programma che divide l'albero di directory di grandi dimensioni in sottotitoli in base alle dimensioni, quindi copia tali sottotitoli in parallelo. Potrebbe semplificare le cose se prima copi l'intera struttura di directory (senza i file).

Sei due macchine in esecuzione in un ambiente attendibile? Potresti provare netcat . Sul lato server:

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

e sul client:

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

Puoi fare in modo che la connessione client usi un tunnel ssh:

ssh -f -L 23333:127.0.0.1:9999 foo@your.server.net sleep 10; \
    nc 127.0.0.1 23333 > yourdir.tar.gz

Anche un'intera partizione può essere spostata in questo modo:

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

e sul client:

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

.

Nota

netcat non è lo strumento di trasferimento più sicuro là fuori, ma nel giusto ambiente può essere veloce perché ha un sovraccarico così basso.

HowtoForge ha una buona pagina di esempi .