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첫 번째 넷북 에서 (해당 파일의 구문 사용).

위의 내용은 잘 작동하지만 파일과 디렉토리는 엄청납니다. 파일은 평균 약 기가 바이트이며 디렉토리는 모두 15 ~ 50 기가 바이트입니다.

나는 rsync그들을 전송하는 데 사용 하고 있으며 명령 (on 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

그러나 좋은 소식은 다음과 같습니다.에 고정 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

이러한 설정을 사용하면 부팅 후 두 넷북이 서로 부팅하지 않고 서로 핑할 수 있습니다 ifup.

어쨌든, 나는 여전히 실제로 nc행동 하고 싶습니다 . 그래서 누군가 가이 프로세스를 디버깅하는 데 도움이되기를 바랍니다.

빠른 길

LAN을 통해 파일을 전송 하는 가장 빠른 방법은 변경이 거의없는 한 동기화되지 않을 가능성이 높습니다. 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타르에 플래그가 (모드 상세)가는대로 파일 이름을 인쇄합니다. 큰 파일의 경우 실제로 오버 헤드가 없습니다. 많은 양의 작은 파일을 수행하는 경우 해당 파일을 끕니다. 또한 pv파이프 라인에 다음과 같은 것을 삽입 하여 진행률 표시기를 얻을 수 있습니다.

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

물론 GZIP 환경 변수를 설정하지 않는 한 수신 측에 플래그를 gzip -1추가하면 송신 측 z의 z플래그가 1보다 높은 압축 수준을 사용합니다. 데이터가 실제로 압축 되지 않으면 gzip이 실제로 느려질 수 있습니다 .

정말 rsync가 필요한 경우

변경된 데이터의 일부만 실제로 전송하는 경우 rsync가 더 빠를 수 있습니다. 더 빠른 네트워크 (예 : 교차 연결)와 같이 -W/ --whole-file옵션 을 보려고 할 수도 있습니다.

rsync를 실행하는 가장 쉬운 방법은 ssh를 사용하는 것입니다. 칩에 인텔의 AES가 있는지 여부에 따라 ssh 암호를 실험하여 AES, ChaCha20 또는 Blowfish (Blowfish의 64 비트 블록 크기에 대한 보안 문제가 있음)를 확인하십시오. -NI 지침 (및 OpenSSL에서 사용) 충분히 새로운 ssh에서 rsync-over-ssh는 다음과 같습니다.

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

이전 ssh / sshd의 경우 aes128-ctr또는 aes128-cbc대신 시도하십시오 aes128-gcm@openssh.com.

ChaCha20은 chacha20-poly1305@openssh.com(또한 충분한 새로운 ssh / sshd가 필요함), 복어는 복어 -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

다른 방법 으로도이 작업을 수행 할 수 있습니다 (물론 읽기를 아니요로 설정해야합니다). 인증 등의 옵션이 있습니다. 자세한 내용은 맨 페이지를 확인하십시오.

방법? 또는 TL; DR

내가 찾은 가장 빠른 방법은 tar, mbuffer및 의 조합입니다 ssh.

예 :

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

이를 사용하여 1Gb 링크에서 950 Mb / s 이상의 지속적인 로컬 네트워크 전송을 달성했습니다. 전송중인 내용에 맞게 각 tar 명령의 경로를 바꾸십시오.

왜? mbuffer!

네트워크를 통해 대용량 파일을 전송하는 데 가장 큰 병목 현상은 디스크 I / O입니다. 그 대답은 mbuffer또는 buffer입니다. 그것들은 대체로 비슷하지만 mbuffer몇 가지 장점이 있습니다. 기본 버퍼 크기는 2MB mbuffer, 1MB입니다 buffer. 더 큰 버퍼는 절대 비워지지 않을 가능성이 높습니다. 대상 및 대상 파일 시스템에서 기본 블록 크기의 최소 공배수 인 블록 크기를 선택하면 최상의 성능을 얻을 수 있습니다.

버퍼링은 모든 차이 를 만드는 것입니다 ! 가지고 있다면 사용하십시오! 당신이 그것을 가지고 있지 않다면 그것을 얻으십시오! (m}?buffer더하기를 사용하는 것이 그 자체로하는 것보다 낫습니다. 네트워크 파일 전송 속도가 느리다는 것은 사실상 만병 통치약입니다.

여러 파일을 전송하는 경우 파일 tar을 하나의 데이터 스트림으로 "뭉치기" 위해 사용하십시오 . 단일 파일 인 경우 cat또는 I / O 리디렉션을 사용할 수 있습니다 . tarvs. 의 오버 헤드 cat는 통계적으로 중요하지 않으므로 이미 tarball이 아닌 한 항상 사용할 수 있습니다 tar(또는 가능한 zfs -send곳) . 이들 중 어느 것도 메타 데이터를 제공한다고 보장 하지 않으며 , 특히 그렇지 않습니다. 메타 데이터를 원한다면 연습용으로 남겨 두겠습니다.cat

마지막으로, ssh전송 메커니즘을 사용 하는 것이 안전하고 오버 헤드가 거의 없습니다. 또, 오버 헤드 ssh대는 nc통계적으로 유의하다.

TCP를 사용할 필요조차 없습니다. AoE는 이더넷을 통한 ATA 구현으로 계층 2이므로 TCP / IP 스택에 대한 지식이없는 오버 헤드가 낮은 접근 방식입니다. 최소한의 오버 헤드로 가능한 가장 빠른 전송을 제공합니다. ***

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

*** 네트워크에 병목 현상이 발생하면 압축 된 데이터를 전송하고 있는지 확인하십시오.