NFS에 문제가 있어서 일반 TCP를 사용해 보고 싶습니다.
하지만 어디서부터 시작해야 할지 모르겠습니다.
하드웨어 측면에서는 이더넷 크로스오버 케이블을 사용하여 두 개의 넷북을 네트워크로 연결했습니다.
네트워크로 연결하려면 다음을 입력하세요.
$ 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
첫 번째 넷북에서
$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1
두 번째에는
/mnt/network1/etc/fstab에 다음과 같이 지정됨
192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0
그리고 /etc/exports(이 파일의 구문을 사용하여) 첫 번째 넷북에서.
위의 방법은 잘 작동하지만 파일과 디렉터리가 큽니다. 각 파일의 평균 크기는 약 0.5GB이고 디렉터리 크기는 모두 15~50GB입니다.
rsync전송하는 데 사용하는 명령은 다음과 192.168.1.2같습니다.
$ rsync -avxS /mnt/network1 ~/somedir
대용량 파일을 더 잘 처리하기 위해 NFS 설정을 조정할 수 있는 방법이 있는지는 잘 모르겠지만, rsync일반 기존 TCP를 통해 데몬을 실행하는 것이 rsyncNFS보다 나은지 확인하고 싶었습니다.
그렇다면 다시 말하면 TCP를 사용하여 유사한 네트워크를 어떻게 구축합니까?
고쳐 쓰다:
그래서 무지의 수렁에서 나 자신을 끌어내려고 몇 시간 동안 노력한 끝에(또는 내가 생각하는 대로 최선을 다해 노력한 끝에) 몇 가지 유용한 사실을 생각해 냈습니다.
하지만 먼저, 단순히 현재의 최선의 답을 받아들이는 대신 저를 이 토끼 길로 이끌었던 것은 이것이었습니다. 이것은 nc믿을 수 없을 만큼 멋진 프로그램이지만 확실히 나에게는 적합하지 않습니다. 나는 시도 netcat-openbsd하고 netcat-traditional포장했지만 운이 없었습니다.
수신 컴퓨터에서 받은 오류( ) 192.168.1.2는 다음과 같습니다.
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다음을 제공합니다:
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
그러나 좋은 소식은 다음과 같습니다. .net에서 고정 IP 주소를 설정하면 /etc/network/interfaces( nc시작하려고 할 때 시작함) 모든 NFS 문제가 해결되고 NFS에 대한 사랑이 다시 불붙었습니다.
내가 사용한 정확한 구성( 192.168.1.1물론 첫 번째 넷북)은 다음과 같습니다.
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
이러한 설정을 사용하면 두 넷북은 부팅 후 직접 ping을 수행할 필요 없이 서로 ping을 보낼 수 있습니다 ifup.
그럼에도 불구하고 나는 이것이 실제로 작동하는 것을 보고 싶기 nc때문에 누군가가 이 프로세스를 디버깅하는 데 도움을 줄 수 있기를 바랍니다.
답변1
빠른 방법
이것가장 빠른사소한 변경 사항이 없는 한 LAN을 통해 파일을 전송하는 방식은 rsync가 아닐 수 있습니다. rsync는 체크섬, 차이 계산 등을 수행하는 데 상당한 시간을 소비합니다. 어쨌든 대부분의 데이터가 전송된다는 것을 알고 있다면 다음과 같이 하십시오(참고: 여러 구현이 있습니다 netcat. 특히 매뉴얼을 확인하십시오. 아마도 원하지 않을 것입니다 -p).
user@dest:/target$ nc -q 1 -l -p 1234 | tar xv
user@source:/source$ tar cv . | nc -q 1 dest-ip 1234
netcat( nc)을 사용하여 포트 1234의 원시 TCP 연결을 통해 tar를 보냅니다. 암호화, 진위 확인 등이 없으므로 매우 빠릅니다. 교차 연결이 기가비트 이하로 실행되면 네트워크에 연결되고, 그 이상이면 디스크에 연결됩니다(스토리지 어레이나 빠른 디스크가 없는 경우). v실행 시 파일 이름을 인쇄하도록 하는 tar에 플래그를 지정합니다 (상세 모드). 대용량 파일의 경우 오버헤드가 거의 없습니다. 작은 파일이 많이 있는 경우에는 이 기능을 끌 수 있습니다. 또는 pv파이프라인에 다음과 같은 항목을 삽입하여 진행률 표시기를 얻을 수 있습니다.
user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv
물론 다른 항목도 삽입할 수 있습니다(그리고 gzip -1수신 측에 플래그를 추가합니다. 물론 GZIP 환경 변수를 설정하지 않는 한 송신 측의 플래그는 1보다 높은 압축 수준을 사용합니다). 데이터가 없으면 gzip이 실제로 느려질 수 있지만zz진짜압축.
정말로 rsync가 필요한 경우
변경된 데이터의 일부만 전송하는 경우 rsync가 더 빨라질 수 있습니다. 매우 빠른 네트워크(예: 교차 연결)가 훨씬 더 빠를 수 있으므로 -W/ 옵션을 살펴보는 것이 좋습니다 .--whole-file
rsync를 실행하는 가장 쉬운 방법은 ssh를 사용하는 것입니다. 어느 것이 가장 빠른지 확인하려면 SSH 암호화를 시도해야 합니다. 칩에 Intel AES-NI가 있는지 여부에 따라 AES, ChaCha20 또는 Blowfish(Blowfish의 64비트 블록 크기에 일부 보안 문제가 있음)일 수 있습니다. 지침(그리고 OpenSSL이 이를 사용합니다). 새로운 SSH에서 rsync-over-ssh는 다음과 같습니다.
user@source:~$ rsync -e 'ssh -c [email protected]' -avP /source/ user@dest-ip:/target
이전 ssh/sshd의 경우 대신 aes128-ctr또는 를 사용해 보세요 .aes128-cbc[email protected]
ChaCha20은 [email protected](충분한 새로운 ssh/sshd도 필요함)이고, Blowfish는 Blowfish-cbc입니다. OpenSSH는 비밀번호 없이는 실행할 수 없습니다. 물론 원하는 rsync 옵션을 대신 사용할 수 있습니다 -avP. 물론 다른 방향으로 이동하여 소스 머신(푸시) 대신 대상 머신(풀)에서 rsync를 실행할 수도 있습니다.
rsync를 더 빠르게 만들기
rsync 데몬을 실행하면 암호화 오버헤드를 제거할 수 있습니다. 먼저, /etc/rsyncd.conf예를 들어 소스 머신에서 데몬 구성 파일( )을 생성합니다 (자세한 내용은 rsyncd.conf 맨페이지 참조).
[big-archive]
path = /source
read only = yes
uid = someuser
gid = somegroup
그런 다음 대상 머신에서 실행합니다.
user@dest:~$ rsync -avP source-ip::big-archive/ /target
이 작업을 반대 방향으로 수행할 수도 있습니다(물론 읽기 전용을 아니요로 설정해야 합니다). 인증과 같은 옵션이 있습니다. 자세한 내용은 맨페이지를 확인하세요.
답변2
어떻게? 또는 TL;DR
tar내가 찾은 가장 빠른 방법은 mbuffer, 및 의 조합 입니다 ssh.
예를 들어:
tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"
이를 사용하여 1Gb 링크에서 950Mb/s 이상의 지속적인 로컬 네트워크 전송을 달성했습니다. 전송하려는 항목에 맞게 각 tar 명령의 경로를 바꾸십시오.
왜? 완충기!
네트워크를 통해 대용량 파일을 전송할 때 가장 큰 병목 현상은 디스크 I/O입니다. 대답은 mbuffer또는 입니다 buffer. 일반적으로 유사하지만 mbuffer몇 가지 장점이 있습니다. 기본 버퍼 크기는 2MB mbuffer이고 기본 버퍼 크기는 1MB입니다 buffer. 버퍼가 클수록 비어 있을 가능성이 더 높습니다. 대상 파일 시스템과 대상 파일 시스템의 기본 블록 크기의 최소 공배수인 블록 크기를 선택하면 최상의 성능을 얻을 수 있습니다.
버퍼링은 허용하는 것입니다모두차이점!가지고 계시다면 활용해보세요! 하나도 없다면, 그것을 얻으십시오! 무엇 이든 (m}?buffer혼자 사용하는 것보다 무엇이든 사용하는 것이 좋습니다. 느린 네트워크 파일 전송에 대한 거의 만병통치약입니다.
전송할 파일이 여러 개인 경우 tar해당 파일을 단일 데이터 스트림으로 "덩어리"로 사용하세요. 단일 파일인 경우 catI/O 리디렉션을 사용할 수 있습니다. tarvs.의 오버헤드는 cat통계적으로 중요하지 않으므로 이미 사용하지 않는 한 항상 사용합니다 tar(또는 zfs -send가능한 경우).보관소. 이들 중 어느 것도 메타데이터 제공을 보장하지 않습니다(특히 cat그렇지 않음). 메타데이터가 필요한 경우 연습용으로 남겨 두겠습니다.
마지막으로, ssh사용된 전송 메커니즘은 안전하고 오버헤드가 거의 없습니다. 다시 말하지만, sshAND의 오버헤드 nc는 통계적으로 중요하지 않습니다.
편집하다
알았어 얘들아 답은 이거야십살이에요. 시대가 변했습니다.
- 이 질문은 구체적으로근거리 통신망s, 대륙 사이가 아닌.
- mbuffered ssh 및 mbuffered nc는 통계적으로 유의하지 않습니다. ssh만 사용하는 것은 nc만 사용하는 것과 다릅니다. tcp 및 udp 모드의 NC는 또 다른 문제입니다.
- 이 업데이트(2022-01) 현재 고속 파일 전송에 대한 가장 일반적인 대답은 여전히입니다(의견에서 @derobert가 언급했듯이).
scp -c [email protected]
답변3
TCP를 사용할 필요조차 없습니다. AoE는 이더넷을 통한 ATA 구현이며, 레이어 2로서 TCP/IP 스택에 대한 지식이 필요하지 않은 낮은 오버헤드 접근 방식입니다. 최소한의 오버헤드로 가장 빠른 전송 속도를 제공합니다. ***
https://en.wikipedia.org/wiki/ATA_over_Ethernet
***네트워크에 병목 현상이 발생하는 경우 압축된 데이터를 전송하고 있는지 확인하세요.