Cara cepat untuk menyalin file besar di LAN


24

Saya mengalami beberapa masalah dengan NFS, dan saya ingin mencoba menggunakan TCP lama.

Saya tidak tahu harus mulai dari mana.

Dari sisi hardware, saya menggunakan kabel crossover ethernet untuk jaringan dua netbook.

Untuk jaringan mereka, saya ketik

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

di netbook pertama dan

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

pada yang kedua

di mana /mnt/network1ditentukan di / etc / fstab sebagai

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

dan juga di /etc/exports(menggunakan sintaks file itu), di netbook pertama.

Di atas berfungsi dengan baik, tetapi file dan direktori sangat besar. Rata-rata file sekitar setengah gigabyte per potong, dan direktori semua antara 15 dan 50 gigabyte.

Saya menggunakan rsyncuntuk mentransfernya, dan perintah (on 192.168.1.2) adalah

$ rsync -avxS /mnt/network1 ~/somedir

Saya tidak yakin apakah ada cara untuk men-tweak pengaturan NFS saya untuk menangani file besar lebih baik, tetapi saya ingin melihat apakah menjalankan rsyncdaemon pada TCP lama yang biasa berfungsi lebih baik daripada rsyncNFS.

Jadi, untuk mengulangi, bagaimana cara mengatur jaringan yang serupa dengan TCP?

MEMPERBARUI:

Jadi, setelah beberapa jam berusaha untuk menarik diri keluar dari rawa ketidaktahuan saya sendiri (atau, seperti yang saya suka pikirkan, untuk menarik diri dengan tali sepatu saya sendiri) saya menemukan beberapa fakta berguna.

Tetapi pertama-tama, yang menuntun saya pada jejak kelinci ini alih-alih hanya menerima jawaban terbaik saat ini adalah ini: ncadalah program keren yang luar biasa yang gagal bekerja untuk saya. Saya sudah mencoba paket netcat-openbsddan netcat-traditionaltidak berhasil sama sekali.

Kesalahan yang saya dapatkan pada mesin penerima ( 192.168.1.2) adalah:

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route memberi:

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

Tapi, inilah kabar baiknya: mengatur alamat IP statis /etc/network/interfaces, yang saya mulai lakukan ketika mencoba untuk ncbekerja, memperbaiki semua masalah NFS saya dan menyalakan kembali cinta saya untuk NFS.

Konfigurasi tepat yang saya gunakan (dengan 192.168.1.1untuk netbook pertama, tentu saja) adalah:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

Dengan pengaturan itu, kedua netbook akan dapat melakukan ping satu sama lain secara langsung setelah di-boot, bahkan tanpa ifup.

Ngomong-ngomong, saya masih sangat ingin melihat ncaksi, jadi saya berharap seseorang membantu saya men-debug proses ini.


Jika kedua direktori tersebut bersifat lokal, Anda lebih baik menggunakan yang lama /bin/cpatau tidak menggunakan NFS sama sekali
Karlson

1
Menjalankan rsync terhadap file yang diakses melalui NFS berarti bahwa seluruh konten file perlu disalin melalui jaringan setidaknya sekali. Anda tidak perlu daemon untuk memanggil rsync klien / server - jalankan saja ssh. (Secara teori dimungkinkan untuk memanggil ujung jarak jauh melalui telnet / rsh - tetapi agak konyol untuk menjalankan layanan seperti itu dalam praktiknya - ssh tidak menambah banyak overhead).
symcbean

NFSv2 sudah cukup tua. OS apa yang Anda gunakan?
Nils

masing-masing Debian terbaru dan Ubuntu terbaru. saya mendapatkan semua perintah itu (termasuk nfsvers=2) dari tutorial ini ( michaelminn.com/linux/home_network )
ixtmixilix

5
sebenarnya, ssh menambahkan jumlah overhead yang cukup besar, crypto tidak murah. Lebih dari kecepatan Internet normal, itu tidak masalah, tetapi melalui LAN (atau koneksi silang langsung, dalam hal ini) Anda mungkin memperhatikan. Lebih dari gigabit, kecuali pada mesin yang paling cepat (atau yang dengan instruksi AES-NI, jika SSH menggunakan itu) saya cukup yakin itu akan terlihat.
derobert

Jawaban:


43

Cara cepat

Cara tercepat untuk mentransfer file melalui LAN mungkin bukan rsync, kecuali ada beberapa perubahan. rsync menghabiskan cukup banyak waktu untuk melakukan checksum, menghitung perbedaan, dll. Jika Anda tahu bahwa Anda akan mentransfer sebagian besar data, lakukan saja sesuatu seperti ini (catatan: ada beberapa implementasi netcat; periksa manual untuk opsi yang benar. Khususnya, Anda mungkin tidak ingin -p):

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

Itu menggunakan netcat ( nc) untuk mengirim tar melalui koneksi TCP mentah pada port 1234. Tidak ada enkripsi, pemeriksaan keaslian, dll, jadi sangat cepat. Jika cross-connect Anda berjalan pada gigabit atau kurang, Anda akan mematok jaringan; jika lebih, Anda akan mematok disk (kecuali jika Anda memiliki array penyimpanan, atau disk cepat). The vbendera untuk tar membuatnya mencetak nama file sebagai kelanjutannya (verbose mode). Dengan file besar, itu praktis tidak ada overhead. Jika Anda melakukan banyak file kecil, Anda akan mematikannya. Anda juga dapat memasukkan sesuatu seperti pvke dalam pipeline untuk mendapatkan indikator progres:

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

Anda tentu saja dapat menyisipkan hal-hal lain juga, seperti gzip -1(dan menambahkan zbendera di sisi penerima - zbendera di ujung pengiriman akan menggunakan tingkat kompresi yang lebih tinggi dari 1, kecuali Anda mengatur variabel lingkungan GZIP, tentu saja). Meskipun gzip mungkin sebenarnya akan lebih lambat, kecuali jika data Anda benar-benar kompres.

Jika Anda benar-benar membutuhkan rsync

Jika Anda benar-benar hanya mentransfer sebagian kecil dari data yang telah berubah, rsync mungkin lebih cepat. Anda mungkin juga ingin melihat opsi -W/ --whole-file, karena dengan jaringan yang sangat cepat (seperti koneksi silang) yang bisa lebih cepat.

Cara termudah untuk menjalankan rsync adalah melalui ssh. Anda akan ingin bereksperimen dengan ssh cipher untuk melihat mana yang tercepat, itu bisa AES, ChaCha20, atau Blowfish (meskipun ada beberapa masalah keamanan dengan ukuran blok 64-bit Blowfish), tergantung pada apakah chip Anda memiliki Intel AES Instruksi -NI (dan OpenSSL Anda menggunakannya). Pada ssh yang cukup baru, rsync-over-ssh terlihat seperti ini:

user@source:~$ rsync -e 'ssh -c aes128-gcm@openssh.com' -avP /source/ user@dest-ip:/target

Untuk ssh / sshd yang lebih lama, coba aes128-ctratau aes128-cbcganti aes128-gcm@openssh.com.

ChaCha20 akan chacha20-poly1305@openssh.com(juga membutuhkan ssh / sshd yang cukup baru) dan Blowfish akan menjadi blowfish-cbc. OpenSSH tidak memungkinkan berjalan tanpa cipher. Anda tentu saja dapat menggunakan opsi rsync mana saja yang Anda suka -avP. Dan tentu saja Anda dapat pergi ke arah lain, dan menjalankan rsync dari mesin tujuan (tarik) alih-alih mesin sumber (push).

Membuat rsync lebih cepat

Jika Anda menjalankan daemon rsync, Anda dapat menyingkirkan overhead crypto. Pertama, Anda akan membuat file konfigurasi daemon ( /etc/rsyncd.conf), misalnya pada mesin sumber (baca manual rsyncd.conf untuk detail):

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

Kemudian, di mesin tujuan, Anda akan menjalankan:

user@dest:~$ rsync -avP source-ip::big-archive/ /target

Anda juga dapat melakukannya dengan cara sebaliknya (tetapi tentu saja Anda harus menyetel read only ke no). Ada opsi untuk otentikasi, dll., Periksa halaman manual untuk detailnya.


2
Ini jawaban yang sangat bagus. Yang lain juga bagus. Apakah tidak ada jawaban yang diterima hanya karena penanya tidak dapat memilih di antara mereka?
sudo

Seberapa kuat netcatpendekatannya? Jika jaringan menjatuhkan paket, sepertinya itu akan kehilangan bagian acak dari file.
sudo

1
@udo itu menggunakan TCP, yang akan mentransmisikan kembali sesuai kebutuhan. Jadi itu harus baik-baik saja terhadap kehilangan paket, korupsi acak (sejauh TCP dan Ethernet checksum menangkapnya), dll. Tentu saja, itu tidak aman terhadap serangan seperti melompati ssh.
derobert

1
@udo Anda dapat melakukan semuanya sekaligus, masukkan beberapa teeperintah ke dalam pipa di kedua sisi untuk menghitung checksum.
derobert

1
@TheStoryCoder Titik di tarbagian itu mengatakannya untuk melakukan direktori saat ini. Itu sebenarnya bukan bagian dari ncperintah, tar digunakan untuk membuat arsip tar, yang disalurkan ke netcat (dan di sisi lain, netcat sedang disalurkan ke tar untuk mengekstrak arsip). Saya khawatir komentar tidak cukup untuk menjelaskan pipa, tapi mudah-mudahan itu cukup untuk membantu Anda memulai ...
derobert

17

Bagaimana? Atau TL; DR

Metode tercepat yang saya temukan adalah kombinasi dari tar, mbufferdan ssh.

Misalnya:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Dengan ini saya telah mencapai transfer jaringan lokal yang berkelanjutan lebih dari 950 Mb / s pada tautan 1Gb. Ganti jalur di setiap perintah tar agar sesuai untuk apa yang Anda transfer.

Mengapa? mbuffer!

Hambatan terbesar dalam mentransfer file besar melalui jaringan adalah, sejauh ini, disk I / O. Jawabannya adalah mbufferatau buffer. Mereka sebagian besar mirip tetapi mbuffermemiliki beberapa keunggulan. Ukuran buffer default adalah 2MB untuk mbufferdan 1MB untuk buffer. Buffer yang lebih besar cenderung tidak pernah kosong. Memilih ukuran blok yang merupakan kelipatan umum terendah dari ukuran blok asli pada sistem file target dan tujuan akan memberikan kinerja terbaik.

Buffering adalah hal yang membuat semua perbedaan! Gunakan jika Anda memilikinya! Jika Anda tidak memilikinya, dapatkan! Menggunakan (m}?bufferplus apa pun lebih baik daripada apa pun dengan sendirinya. hampir secara harfiah merupakan obat mujarab untuk transfer file jaringan yang lambat.

Jika Anda mentransfer banyak file, gunakan taruntuk "menyatukan" keduanya menjadi satu aliran data. Jika itu adalah file tunggal yang dapat Anda gunakan catatau I / O redirection. Overhead tarvs catsecara statistik tidak signifikan jadi saya selalu menggunakan tar(atau di zfs -sendmana saya bisa) kecuali itu sudah tarball . Tidak satu pun dari ini dijamin memberi Anda metadata (dan khususnya cattidak akan). Jika Anda ingin metadata, saya akan meninggalkan itu sebagai latihan untuk Anda.

Akhirnya, menggunakan sshuntuk mekanisme transportasi aman dan membawa sedikit overhead. Sekali lagi, overhead sshvs ncsecara statistik tidak signifikan.


4
openssl speedpada i7-3770 memberi ~ 126–146 MB / detik untuk blowfish CBC dan ~ 138–157 MB / detik untuk AES CBC (chip ini memiliki instruksi AES-NI). Kemudian ~ 200–300 MB / detik untuk sha256. Jadi itu hampir tidak bisa mendorong 1 gigabit. Dengan OpenSSH 6.1+, Anda dapat menggunakan AES GCM, yang dapat dilakukan dengan kecepatan yang menyilaukan (370–1320 MB / detik, tergantung pada ukuran pesan). Jadi saya pikir hanya benar bahwa OpenSSH memiliki sedikit overhead jika Anda menjalankan 6.1+ pada chip dengan AES-NI dan menggunakan AES-GCM.
derobert

1
Ugh, saya mengubahnya menjadi 6.1+ daripada 6.2+ pada menit terakhir, setelah dengan cepat memeriksa ulang. Tentu saja, itu adalah kesalahan, itu adalah perubahan sejak 6.1. Jadi OpenSSH 6.2+ adalah versi yang benar. Dan itu tidak akan membiarkan saya mengedit komentar lagi sekarang. Komentar yang lebih dari 5 menit harus tetap salah. Tentu saja, jika kurang dari OpenSSH 6.4, lihat openssh.com/txt/gcmrekey.adv karena tanpa patch, ada kelemahan yang dapat dieksploitasi dalam implementasi AES-GCM OpenSSH.
derobert

Overhead untuk ssh(atau rsync over ssh) sangat, SANGAT penting. Saya memiliki NAS yang menggunakan CPU Intel Atom. Enkripsi SSH BENAR-BENAR TUMBUH kecepatan transfer. Saya mendapatkan secara konsisten <400 Mbit / detik untuk RSA, menimpanya secara manual ke RC4 membuat saya ~ 600 Mbits / detik, dan jika saya menggunakan rsync sebagai daemon, ia berjalan pada kecepatan tautan asli (> 900 MBit / detik, pada gigabit koneksi).
Nama Palsu

Meskipun benar bahwa untuk banyak situasi, transportasi tidak kritis, sangat penting untuk mempertimbangkannya, terutama jika Anda tidak menggunakan perangkat keras yang sangat canggih. Dalam kasus saya, Atom (itu adalah D525, dual core 1,8 Ghz) membuat NAS benar-benar bagus, dengan banyak kecepatan untuk SMB, tetapi enkripsi benar-benar membunuhnya.
Nama Palsu

2
Saya mendapatkan kesalahan fatal karena parametrization mbuffer: 'mbuffer: fatal: total memori harus lebih besar dari ukuran blok \ n Dihentikan'. Untuk memperbaiki, saya menduga itu harus membaca sesuatu seperti 'mbuffer -s 1K -m 512M' dengan akhir 'M' berdiri untuk MByte (sumber: man mbuffer)
Peter Lustig

1

Anda bahkan tidak perlu menggunakan TCP. AoE adalah implementasi ATA melalui Ethernet, karena layer 2 itu adalah pendekatan overhead yang lebih rendah tanpa pengetahuan tentang tumpukan TCP / IP. Ini akan memberi Anda transfer tercepat yang mungkin dengan overhead terendah. ***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

*** jika jaringannya menjadi hambatan, pastikan Anda mengirim data terkompresi.


Wow itu inti keras! :) Bertanya-tanya apakah ada tolok ukur ...
rogerdpack
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.