Membalik multiplexing untuk mempercepat transfer file


19

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.

Jawaban:


29

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!


lftpitu bagus, tapi saya tidak bisa membuatnya melakukan multipart ketika meng-upload. Saya menggunakan mirror --use-pget-n=20 -R- tetapi tampaknya itu --use-pget-nhanya berfungsi saat mengunduh.
Dan

PS, -P20berfungsi untuk mengunggah banyak file, tetapi saya tidak dapat mengalikan setiap file.
Dan

1
lftp tidak mendukung pengunggahan tersegmentasi / multi-bagian. Anda harus memulai transfer dari sisi tujuan untuk digunakan pget -n.
apraetor

Ingat, mirroradalah dua arah; satu pgetargumen hanya berlaku untuk file yang didownload.
apraetor

10

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


8

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>).


1
kesalahan ketik pada parameter: --use-pget-n alih-alih --use-pget-m. Sudah mencoba mengedit, tetapi edit saya terlalu pendek.
Tony

2

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.


1

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.


Data sewenang-wenang. Terkadang itu adalah direktori besar, terkadang satu file.
ZimmyDubZongyZongDubby

1

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 &

0

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.


itu benar-benar licik :)
warren

Saya tidak dapat menjamin bahwa semua filesystem mendapatkan dorongan dari ini, tergantung pada bagaimana tata letak inode dilakukan.
Jimmy Hedman

Hambatannya adalah bahwa setiap koneksi TCP dibatasi hingga 320KB / detik. Saya ingin mengirim file dalam koneksi TCP paralel sehingga saya mendapatkan 320 * NumConnections hingga batas jaringan (sekitar 1200KB / detik). Mengurutkan berdasarkan inode tidak mencapai ini.
ZimmyDubZongyZongDubby

Apa yang membatasi kecepatan TCP? Router antar mesin?
Jimmy Hedman

ISP saya. Netralitas bersih? HA!
ZimmyDubZongyZongDubby

0

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 :)


1
Jika hanya dua mesin yang terlibat dalam transfer file, bagaimana torrent dapat membantu? Gagasan torrent adalah segerombolan seeder yang membuat data tersedia untuk pemohon klien.
DaveParillo

Kamu benar. Tapi siapa bilang tidak berguna dengan seeder tunggal? ;)
kolypto

2
Jika klien torrent membuat beberapa koneksi TCP dengan satu rekan, maka ini akan menyelesaikan masalah OP. Namun, saya tidak tahu apakah klien torrent benar-benar membuat beberapa koneksi TCP dengan satu rekan.
chronos

0

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.


Bukankah SFTP akan jauh lebih mudah dan sama seperti (jika tidak lebih) aman?
Mark Renouf

1
@rob: dari mana Anda mendapatkan "FTP menggunakan banyak koneksi untuk transfer file" dari? Beberapa klien mengizinkan beberapa aliran untuk mengunduh dari FTP, tetapi pasti tidak ada kombo klien / server FTP yang memungkinkan beberapa aliran untuk diunggah ke FTP.
chronos

@ Mark: Ya, SFTP mungkin akan lebih mudah dan sama-sama aman, tapi saya tidak tahu apakah itu mendukung beberapa koneksi untuk mentransfer satu file. Terima kasih untuk sarannya; Saya akan menambahkannya ke daftar.
merampok

1
@ Syncos: Maaf tidak jelas; Saya menyarankan agar ZimmyDubZongyZongDubby menggunakan FTP untuk mengunduh dari server CentOS ke klien FreeBSD. Saya telah memperbarui jawaban untuk secara khusus mengatakan "unduhan" alih-alih "transfer file."
merampok

-1

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.


Adakah yang mau menjelaskan tentang downvote?
merampok

-1

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 .


Ini sepertinya jawaban umum yang tidak menjawab pertanyaannya. Aku tidak bisa melihat bagaimana salah satu solusi Anda akan mentransfer secara paralel, nc hanya satu sambungan sejauh yang saya tahu
davr

Anda mungkin benar, namun, menggunakan nc, Anda memiliki kendali atas port yang dibuka. Anda dapat menentukan 10.000 jika Anda cenderung.
DaveParillo
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.