Membalik multiplexing untuk mempercepat transfer file

Saya telah mengirim sejumlah besar data dari satu mesin ke komputer lain. Jika saya mengirim dengan rsync (atau metode lain), itu akan tetap pada 320kb / detik. Jika saya melakukan dua atau tiga transfer sekaligus, masing-masing akan mencapai 320, dan jika saya melakukan empat sekaligus, mereka akan memaksimalkan tautan.

Saya harus dapat mengirim data secepat mungkin, jadi saya memerlukan alat yang dapat melakukan multiplexing terbalik dengan transfer file. Saya memerlukan solusi umum, jadi menjalankan split pada mesin sumber dan men-catting mereka di ujung yang lain tidak praktis. Saya membutuhkan ini untuk bekerja secara otomatis.

Apakah ada alat yang melakukan ini, atau apakah saya perlu membuatnya sendiri? Pengirimnya adalah CentOS, penerima adalah FreeBSD.

Buktinya semuanya bertambah - saya menyajikan 'cawan suci' dari perintah mirror jarak jauh. Terima kasih kepada davr untuk lftpsarannya.

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

Di atas akan mencerminkan direktori remote secara rekursif, memecah setiap file menjadi 10 utas saat ditransfer!

Ada beberapa alat yang mungkin berhasil.

• LFTP - mendukung FTP, HTTP, dan SFTP. Mendukung penggunaan banyak koneksi untuk mengunduh satu file. Dengan asumsi Anda ingin mentransfer file dari remoteServer ke localServer, instal LFTP di localServer, dan jalankan:

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

  '-N 4' adalah berapa banyak koneksi yang digunakan secara paralel.

• Lalu ada banyak alat 'unduh akselerator', tetapi mereka umumnya hanya mendukung HTTP atau FTP, yang mungkin tidak ingin Anda atur di server jarak jauh. Beberapa contoh adalah Axel , aria2 , dan ProZilla

Jika Anda menggunakan beberapa file besar dan besar lftp -e 'mirror --parallel=2 --use-pget-n=10 <remote_dir> <local_dir>' <ftp_server>: Anda akan mengunduh 2 file dengan setiap file dibagi dalam 10 segmen dengan total koneksi 20 ftp ke <ftp_server>;

Jika Anda memiliki banyak file kecil, gunakan lftp -e 'mirror --parallel=100 <remote_dir> <local_dir>' <ftp_server>: Anda akan mengunduh 100 file secara paralel tanpa segmentasi. Total 100 koneksi akan terbuka. Ini dapat exaust klien yang tersedia di server, atau dapat membuat Anda dilarang di beberapa server.

Anda dapat menggunakan --continueuntuk melanjutkan pekerjaan :) dan -Ropsi untuk mengunggah alih-alih mengunduh (lalu mengalihkan urutan argumen ke <local_dir> <remote_dir>).

Anda mungkin dapat mengubah pengaturan TCP Anda untuk menghindari masalah ini, tergantung pada apa yang menyebabkan 320KB / s per batas koneksi. Dugaan saya adalah bahwa itu bukan batas per koneksi koneksi eksplisit oleh ISP. Ada dua kemungkinan penyebab pelambatan:

1. Beberapa tautan antara kedua mesin jenuh dan menjatuhkan paket.
2. Jendela TCP jenuh karena produk penundaan bandwidth terlalu besar.

Dalam kasus pertama setiap koneksi TCP akan, secara efektif, bersaing secara setara dalam kontrol kongesti TCP standar. Anda juga bisa meningkatkan ini dengan mengubah algoritma kontrol kemacetan atau dengan mengurangi jumlah backoff.

Dalam kasus kedua Anda tidak dibatasi oleh packet loss. Menambahkan koneksi tambahan adalah cara kasar untuk memperluas ukuran jendela total. Jika Anda dapat secara manual meningkatkan ukuran jendela masalahnya akan hilang. (Ini mungkin memerlukan penskalaan jendela TCP jika latensi koneksi cukup tinggi.)

Anda dapat mengetahui kira-kira seberapa besar ukuran jendela dengan mengalikan waktu "ping" pulang pergi dengan kecepatan total koneksi. 1280KB / s membutuhkan 1280 (1311 untuk 1024 = 1K) byte per milidetik perjalanan pulang pergi. Penyangga 64K akan dimaksimalkan pada sekitar 50 ms latensi, yang cukup khas. Buffer 16K kemudian akan jenuh sekitar 320KB / s.

Bagaimana struktur data Anda? Beberapa file besar? Beberapa direktori besar? Anda dapat memunculkan banyak rsync pada cabang-cabang tertentu dari pohon direktori Anda.

Itu semua tergantung pada bagaimana data sumber Anda disusun. Ada banyak alat unix untuk mengiris, memotong, dan memasang kembali file.

Jika Anda dapat mengatur login ssh tanpa kata sandi, maka ini akan membuka 4 koneksi scp bersamaan (-n) dengan masing-masing koneksi menangani 4 file (-L):

Temukan . -type f | xargs -L 4 -n 4 /tmp/scp.sh user @ host: path

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 &

Coba urutkan semua file pada inode (temukan / mydir -type f -print | xargs ls -i | sort -n) dan transfer dengan misalnya cpio over ssh. Ini akan memaksimalkan disk Anda dan membuat jaringan Anda macet. Lebih cepat dari itu sulit untuk pergi ketika melintasi jaringan.

Saya tahu alat yang dapat mentransfer file dalam potongan. Alat ini disebut paket / port 'rtorrent' yang tersedia di kedua host;) Klien BitTorrent sering memesan ruang disk sebelum transfer, dan potongan ditulis langsung dari soket ke disk. Selain itu, Anda dapat meninjau status SEMUA transfer dalam layar ncurses yang bagus.

Anda dapat membuat skrip bash sederhana untuk mengotomatisasi pembuatan file "* .torrent" dan ssh sebuah perintah ke mesin jarak jauh sehingga ia mengunduhnya. Ini terlihat agak jelek, tapi saya tidak berpikir Anda akan menemukan solusi sederhana tanpa mengembangkan :)

FTP menggunakan beberapa koneksi untuk unduhan. Jika Anda dapat mengatur saluran aman untuk FTP melalui VPN atau FTP melalui SSH , Anda harus dapat memaksimalkan tautan jaringan Anda. (Perhatikan bahwa pertimbangan khusus diperlukan untuk FTP melalui SSH - lihat tautan.)

FTPS (FTP over SSL) juga dapat melakukan apa yang Anda butuhkan.

Anda juga dapat menggunakan klien SFTP yang mendukung banyak koneksi, tetapi saya tidak yakin apakah SFTP mendukung banyak koneksi untuk satu file. Ini harus melakukan apa yang paling Anda butuhkan sepanjang waktu, tetapi mungkin tidak memberi Anda throughput maksimum ketika Anda hanya perlu mentransfer satu file besar.

Solusi 1: Saya tidak yakin apakah ini praktis dalam kasus Anda, tetapi Anda dapat membuat arsip yang terbentang (misalnya, tarfile yang dipecah menjadi potongan-potongan, atau arsip 7zip yang dibentangkan), lalu gunakan beberapa contoh rsync untuk mengirimkannya jaringan dan pasang kembali / ekstrak mereka di sisi lain. Anda dapat menulis skrip tujuan umum yang argumennya adalah direktori yang akan ditransfer dan jumlah koneksi yang akan digunakan. Kelemahan yang jelas adalah bahwa Anda akan membutuhkan ruang kosong dua kali lebih banyak di kedua sisi, dan akan memiliki biaya tambahan pengarsipan / mengekstraksi file di kedua ujungnya.

Solusi 2: solusi yang lebih baik adalah dengan menulis skrip atau program yang membagi pohon direktori besar menjadi sub pohon berdasarkan ukuran, kemudian menyalin sub pohon tersebut secara paralel. Mungkin menyederhanakan hal-hal jika Anda menyalin seluruh struktur direktori (tanpa file) terlebih dahulu.

Apakah Anda dua mesin berjalan di lingkungan tepercaya? Anda bisa mencoba netcat . Di sisi server:

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

dan pada klien:

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

Anda dapat meminta koneksi klien menggunakan terowongan 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

Bahkan seluruh partisi dapat dipindahkan dengan cara ini:

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

dan pada klien:

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

.

Catatan

netcat bukan alat transfer yang paling aman di luar sana, tetapi di lingkungan yang tepat bisa cepat karena memiliki overhead yang rendah.

HowtoForge memiliki halaman contoh yang bagus .