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.

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 [email protected]' -avP /source/ user@dest-ip:/target

Untuk ssh / sshd yang lebih lama, coba aes128-ctratau aes128-cbcganti [email protected].

ChaCha20 akan [email protected](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.

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.

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.