Cách nhanh chóng để sao chép một tệp lớn trên mạng LAN


24

Tôi gặp một số rắc rối với NFS và tôi muốn thử chỉ sử dụng TCP cũ.

Tôi không biết bắt đầu từ đâu.

Thông minh về phần cứng, tôi đang sử dụng cáp chéo ethernet để nối mạng hai netbook.

Để kết nối chúng, tôi gõ

$ 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

trên netbook đầu tiên và

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

vào ngày thứ hai

nơi /mnt/network1được chỉ định trong / etc / fstab là

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

cũng như trong /etc/exports(sử dụng cú pháp của tệp đó), trên netbook đầu tiên.

Ở trên hoạt động tốt, nhưng các tập tin và thư mục là rất lớn. Các tập tin trung bình khoảng nửa gigabyte một mảnh và các thư mục đều nằm trong khoảng từ 15 đến 50 gigabyte.

Tôi đang sử dụng rsyncđể chuyển chúng và lệnh (bật 192.168.1.2) là

$ rsync -avxS /mnt/network1 ~/somedir

Tôi không chắc có cách nào để điều chỉnh cài đặt NFS của mình để xử lý các tệp lớn tốt hơn không, nhưng tôi muốn xem liệu chạy rsyncdaemon trên TCP cũ đơn giản có hoạt động tốt hơn rsyncNFS không.

Vì vậy, để nhắc lại, làm cách nào để thiết lập một mạng tương tự với TCP?

CẬP NHẬT:

Vì vậy, sau vài giờ cố gắng kéo bản thân ra khỏi sự thờ ơ của chính mình (hoặc, như tôi nghĩ về nó, để tự kéo mình lên bằng đôi giày boot của mình), tôi đã đưa ra một số sự thật hữu ích.

Nhưng trước hết, điều khiến tôi đi theo con đường thỏ này thay vì chỉ chấp nhận câu trả lời hay nhất hiện tại là đây: nclà một chương trình tuyệt vời đến khó tin mà kiên quyết không làm việc cho tôi. Tôi đã thử netcat-openbsdnetcat-traditionalcác gói không có may mắn nào.

Lỗi tôi nhận được trên máy nhận ( 192.168.1.2) là:

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

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

Nhưng, đây là tin tốt: có các địa chỉ IP tĩnh được đặt /etc/network/interfaces, tôi bắt đầu thực hiện trong khi cố gắng nclàm việc, khắc phục tất cả các sự cố NFS của tôi và khơi dậy tình yêu của tôi đối với NFS.

Cấu hình chính xác mà tôi đã sử dụng (tất nhiên là với 192.168.1.1netbook đầu tiên) là:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

Với các cài đặt đó, hai netbook sẽ có thể ping trực tiếp lẫn nhau sau khi được khởi động, thậm chí không cần ifup.

Dù sao, tôi vẫn thực sự muốn thấy nctrong hành động, vì vậy tôi hy vọng ai đó giúp tôi gỡ lỗi quá trình này.


Nếu cả hai thư mục đều là cục bộ, tốt hơn hết bạn chỉ /bin/cpnên sử dụng NFS cũ hoặc hoàn toàn không sử dụng NFS
Karlson

1
Chạy rsync đối với tệp được truy cập qua NFS có nghĩa là toàn bộ nội dung của tệp cần được sao chép qua mạng ít nhất một lần. Bạn không cần một trình nền để gọi rsync máy khách / máy chủ - chỉ cần chạy nó qua ssh. (về mặt lý thuyết là có thể gọi đầu cuối từ xa qua telnet / rsh - nhưng thật ngớ ngẩn khi chạy một dịch vụ như vậy trong thực tế - ssh không thêm nhiều chi phí).
symcbean

NFSv2 khá cũ. Bạn đang sử dụng hệ điều hành nào?
Nils

Debian mới nhất và Ubuntu mới nhất, tương ứng. tôi đã nhận được tất cả các lệnh đó (bao gồm nfsvers=2) từ hướng dẫn này ( michaelminn.com/linux/home_network )
ixtmixilix

5
Trên thực tế, ssh thêm một lượng chi phí khá lớn, tiền điện tử không hề rẻ. Với tốc độ Internet bình thường, điều đó không thành vấn đề, nhưng qua mạng LAN (hoặc kết nối chéo trực tiếp, trong trường hợp này) bạn có thể nhận thấy. Trên gigabit, ngoại trừ trên các máy nhanh nhất (hoặc các máy có hướng dẫn AES-NI, nếu SSH sử dụng các máy đó) tôi chắc chắn rằng nó sẽ được chú ý.
derobert

Câu trả lời:


43

Cách nhanh chóng

Cách nhanh nhất để truyền tệp qua mạng LAN có thể không phải là rsync, trừ khi có một vài thay đổi. rsync dành một chút thời gian để thực hiện kiểm tra, tính toán sự khác biệt, v.v ... Nếu bạn biết rằng bạn sẽ chuyển hầu hết dữ liệu, chỉ cần làm một cái gì đó như thế này (lưu ý: có nhiều triển khai netcat; kiểm tra hướng dẫn sử dụng Các tùy chọn chính xác. Đặc biệt, bạn có thể không muốn -p):

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

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

Điều đó sử dụng netcat ( nc) để gửi tar qua kết nối TCP thô trên cổng 1234. Không có mã hóa, kiểm tra tính xác thực, v.v., vì vậy nó rất nhanh. Nếu kết nối chéo của bạn đang chạy ở gigabit hoặc ít hơn, bạn sẽ kết nối mạng; nếu có thêm, bạn sẽ chốt đĩa (trừ khi bạn có mảng lưu trữ hoặc đĩa nhanh). Các vcờ để tar làm cho nó in tên tệp khi nó đi (chế độ dài dòng). Với các tệp lớn, thực tế không có phí. Nếu bạn đang thực hiện hàng tấn tệp nhỏ, bạn sẽ tắt nó đi. Ngoài ra, bạn có thể chèn một cái gì đó như pvvào đường ống để có được chỉ báo tiến trình:

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

Tất nhiên, bạn cũng có thể chèn những thứ khác, như gzip -1(và thêm zcờ vào đầu nhận nhận, zcờ ở đầu gửi sẽ sử dụng mức nén cao hơn 1, trừ khi bạn đặt biến môi trường GZIP, tất nhiên). Mặc dù gzip có thể sẽ thực sự chậm hơn, trừ khi dữ liệu của bạn thực sự nén.

Nếu bạn thực sự cần rsync

Nếu bạn thực sự chỉ chuyển một phần nhỏ dữ liệu đã thay đổi, rsync có thể nhanh hơn. Bạn cũng có thể muốn xem tùy chọn -W/ --whole-file, vì với một mạng thực sự nhanh (như kết nối chéo) có thể nhanh hơn.

Cách dễ nhất để chạy rsync là qua ssh. Bạn sẽ muốn thử nghiệm với mật mã ssh để xem cái nào nhanh nhất, đó sẽ là AES, ChaCha20 hoặc Blowfish (mặc dù có một số lo ngại về bảo mật với kích thước khối 64 bit của Blowfish), tùy thuộc vào việc chip của bạn có AES của Intel không Hướng dẫn -NI (và OpenSSL của bạn sử dụng chúng). Trên một ssh đủ mới, rsync-over-ssh trông như thế này:

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

Đối với ssh / sshd cũ hơn, hãy thử aes128-ctrhoặc aes128-cbcthay thế aes128-gcm@openssh.com.

ChaCha20 sẽ là chacha20-poly1305@openssh.com(cũng cần một ssh / sshd mới đủ) và blowfish sẽ là blowfish-cbc. OpenSSH không cho phép chạy mà không có mật mã. Tất nhiên bạn có thể sử dụng bất kỳ tùy chọn rsync nào bạn thích thay thế -avP. Và tất nhiên bạn có thể đi theo hướng khác và chạy rsync từ máy đích (kéo) thay vì máy nguồn (đẩy).

Làm rsync nhanh hơn

Nếu bạn chạy một daemon rsync, bạn có thể thoát khỏi chi phí tiền điện tử. Trước tiên, bạn sẽ tạo một tệp cấu hình daemon ( /etc/rsyncd.conf), ví dụ như trên máy nguồn (đọc manpage rsyncd.conf để biết chi tiết):

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

Sau đó, trên máy đích, bạn sẽ chạy:

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

Bạn cũng có thể làm điều này theo cách khác (nhưng tất nhiên bạn sẽ cần đặt chỉ đọc thành không). Có các tùy chọn để xác thực, vv, kiểm tra trang chủ để biết chi tiết.


2
Đây là một câu trả lời tuyệt vời. Một cái khác là tuyệt vời quá. Có câu trả lời nào được chấp nhận chỉ vì người hỏi không thể chọn giữa họ không?
sudo

Cách netcattiếp cận mạnh mẽ như thế nào ? Nếu mạng giảm các gói, có vẻ như nó sẽ mất các phần ngẫu nhiên của các tệp.
sudo

1
@sudo đó là sử dụng TCP, sẽ truyền lại khi cần thiết. Vì vậy, nó sẽ ổn đối với việc mất gói, tham nhũng ngẫu nhiên (đến mức tổng kiểm tra TCP và Ethernet bắt được nó), v.v ... Tất nhiên, nó không an toàn trước các cuộc tấn công như đào hầm qua ssh.
derobert

1
@sudo bạn có thể làm tất cả cùng một lúc, chèn một số teelệnh vào đường ống ở cả hai bên để tính toán tổng kiểm tra.
derobert

1
@TheStoryCoder Dấu chấm trong tarphần đang bảo nó thực hiện thư mục hiện tại. Đó thực sự không phải là một phần của nclệnh, tar đang được sử dụng để tạo một kho lưu trữ tar, đang được dẫn vào netcat (và mặt khác, netcat đang được dẫn vào tar để trích xuất kho lưu trữ). Tôi sợ một nhận xét không thực sự đủ để giải thích các đường ống, nhưng hy vọng điều đó đủ để bạn bắt đầu ...
derobert

17

Làm sao? Hoặc TL; DR

Phương pháp nhanh nhất tôi tìm thấy là sự kết hợp của tar, mbufferssh.

Ví dụ:

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

Sử dụng điều này tôi đã đạt được chuyển mạng cục bộ bền vững trên 950 Mb / giây trên các liên kết 1Gb. Thay thế các đường dẫn trong mỗi lệnh tar để phù hợp với những gì bạn đang chuyển.

Tại sao? mbuffer!

Nút thắt lớn nhất trong việc chuyển các tệp lớn qua mạng là, cho đến nay, đĩa I / O. Câu trả lời là mbufferhoặc buffer. Chúng phần lớn tương tự nhưng mbuffercó một số lợi thế. Kích thước bộ đệm mặc định là 2MB cho mbuffervà 1MB cho buffer. Bộ đệm lớn hơn có nhiều khả năng không bao giờ trống. Chọn kích thước khối là bội số chung thấp nhất của kích thước khối gốc trên cả hệ thống tệp đích và hệ thống tệp đích sẽ cho hiệu suất tốt nhất.

Đệm là điều mà làm cho tất cả sự khác biệt! Sử dụng nó nếu bạn có nó! Nếu bạn không có nó, hãy lấy nó! Sử dụng (m}?buffercộng với bất cứ điều gì tốt hơn bất cứ điều gì của chính nó. nó gần như là một liều thuốc cho việc chuyển tập tin mạng chậm.

Nếu bạn đang chuyển nhiều tệp, hãy sử dụng tarđể "gộp" chúng lại thành một luồng dữ liệu. Nếu đó là một tệp duy nhất bạn có thể sử dụng cathoặc chuyển hướng I / O. Chi phí của tarvs catlà không đáng kể về mặt thống kê vì vậy tôi luôn sử dụng tar(hoặc zfs -sendnơi tôi có thể) trừ khi nó đã là một tarball . Cả hai thứ này đều được đảm bảo cung cấp cho bạn siêu dữ liệu (và đặc biệt là catsẽ không). Nếu bạn muốn siêu dữ liệu, tôi sẽ để nó như một bài tập cho bạn.

Cuối cùng, sử dụng sshcho một cơ chế vận chuyển vừa an toàn và mang rất ít chi phí. Một lần nữa, chi phí sshso với nckhông đáng kể về mặt thống kê.


4
openssl speedtrên i7-3770 mang lại ~ 126 Mạnh146 MB / giây cho CBC cá kiếm và ~ 138 Tắt157 MB / giây cho AES CBC (chip này có hướng dẫn AES-NI). Sau đó ~ 200 con300 MB / giây cho sha256. Vì vậy, nó chỉ có thể đẩy 1 gigabit. Với OpenSSH 6.1+, bạn có thể sử dụng AES GCM, điều này có thể làm với tốc độ làm mờ (370 chuyến1320 MB / giây, tùy thuộc vào kích thước tin nhắn). Vì vậy, tôi nghĩ rằng sự thật duy nhất là OpenSSH có ít chi phí hoạt động nếu bạn đang chạy 6.1+ trên chip có AES-NI và sử dụng AES-GCM.
derobert

1
Ugh, tôi đã thay đổi nó thành 6.1+ thay vì 6.2+ vào phút cuối, sau khi nhanh chóng kiểm tra lại. Tất nhiên, đó là một sai lầm, đó là những thay đổi kể từ 6.1. Vì vậy, OpenSSH 6.2+ là phiên bản chính xác. Và nó sẽ không cho phép tôi chỉnh sửa bình luận nữa. Nhận xét cũ hơn 5 phút phải không chính xác. Tất nhiên, nếu ít hơn OpenSSH 6.4, hãy xem openssh.com/txt/gcmrekey.adv như không có bản vá, có một lỗ hổng có thể khai thác trong triển khai AES-GCM của OpenSSH.
derobert

Chi phí cho ssh(hoặc rsync trên ssh) là rất, RẤT quan trọng. Tôi có một NAS sử dụng CPU Intel Atom. Mã hóa SSH TUYỆT ĐỐI TÂN tốc độ truyền. Tôi nhận được <400 Mbit / giây cho RSA một cách nhất quán, ghi đè thủ công lên RC4 giúp tôi đạt ~ 600 Mbits / giây và nếu tôi sử dụng rsync như một daemon, nó sẽ chạy ở tốc độ gốc liên kết (> 900 MBit / giây, trên gigabit kết nối).
Tên giả

Mặc dù trong nhiều trường hợp, sự thật là việc vận chuyển không quan trọng, điều cực kỳ quan trọng là phải xem xét nó, đặc biệt nếu bạn không chạy trên phần cứng cực kỳ cao cấp. Trong trường hợp của tôi, Atom (đó là D525, lõi kép 1.8 Ghz) tạo ra một NAS hoàn toàn tốt, với nhiều tốc độ cho SMB, nhưng mã hóa hoàn toàn giết chết nó.
Tên giả

2
Tôi gặp lỗi nghiêm trọng do tham số của mbuffer: 'mbuffer: fatal: tổng bộ nhớ phải lớn hơn kích thước khối \ n Đã kết thúc'. Để sửa, tôi nghi ngờ nó nên đọc một cái gì đó như 'mbuffer -s 1K -m 512M' với chữ 'M' cuối cùng viết tắt cho MByte (nguồn: man mbuffer)
Peter Lustig

1

Bạn thậm chí không cần sử dụng TCP. AoE là một triển khai ATA qua Ethernet, là lớp 2, đây là cách tiếp cận chi phí thấp hơn mà không có kiến ​​thức về ngăn xếp TCP / IP. Nó sẽ cung cấp cho bạn chuyển khoản nhanh nhất có thể với ít chi phí nhất. ***

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

*** nếu mạng là nút cổ chai, hãy chắc chắn rằng bạn đang gửi dữ liệu nén.


Wow đó là lõi cứng! :) Tự hỏi nếu có bất kỳ điểm chuẩn nào ...
rogerdpack
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.