많은 파일을 전송하는 가장 빠르고 안정적인 방법은 무엇입니까?


10

총 90GB의 약 100k 파일을 전송하려고합니다. 지금은 rsync 데몬을 사용하고 있지만 느린 3.4mb / s이며 여러 번 수행해야합니다. 인터넷을 통해 100mbit 연결을 최대한 활용하고 매우 신뢰할 수있는 옵션이 무엇인지 궁금합니다.


2
거의 3 분의 1의 연결을 얻고 있습니다. 파일이 전송되는 전자 비행 거리는 얼마나됩니까?
Shane Madden 1

두 서버 간의 대기 시간은 50ms입니다.
시크릿 2

5
한 번에 많은 파일을 보았습니다 hyperboleandahalf.blogspot.com/2010/04/…
Smudge November

rsync 데몬을 사용하는 경우 ssh가 포함되어 있지 않습니다. 그러면 설명은 아마도 호스트 사이의 인프라 일 것입니다. netperf 또는 iperf 또는 flowgrind를 시도하여 호스트 간의 속도를 테스트 할 수 있습니다. 이 테스트가 더 높은 전송 속도를 제공하는 경우 rsync로 인해 속도가 느려지는지 확인해야합니다. 서버에서 I / O를 느리게 읽기, 클라이언트에서 I / O를 쓰기, 많은 작은 파일, 파일 시스템 등.
AndreasM

답변:


11

Sneakernet 을 고려 습니까? 대용량 데이터 세트를 사용하면 밤새 배송하는 것이 인터넷을 통한 전송보다 더 빠르고 저렴합니다.


10
"고속도로를 다치게하는 테이프로 가득 찬 스테이션 왜건의 대역폭을 과소 평가하지 마십시오." - AST
voretaq7

1
기가비트 LAN 하드웨어의 경제성을 고려할 때 LAN 전송의 경우 eSATA를 통해 단일 스핀들에 쓰는 데 소요되는 시간이 그리 매력적이지는 않습니다.
memnoch_proxy 2018

10

어떻게? 또는 TL; DR

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

예 :

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

이를 사용하여 1Gb 링크에서 950Mb / 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통계적으로 유의하다.


SSH를 전송으로 사용하는 경우 암호화 오버 헤드가 있습니다. 참조 : 암호화없이 강력한 인증을받은 Linux 시스템간에 파일 복사
ewwhite

2
필요한 경우 더 빠른 암호화 메커니즘을 사용할 수 있습니다. 그러나 반드시 이것을 통해 ssh를 파이프 할 필요는 없습니다. 양쪽의 mbuffer에서 -O 및 -I 포트를 설정하는 것을 선호합니다. 이 명령이 이제 두 명령이더라도 양쪽 끝을 버퍼링하여 암호화를 건너 뛰고 네트워크 대역폭을 최대화합니다. 로컬 LAN에서 720 + Mbps로 타르 스트림을 전송하고 있습니다.tar -cf - .|mbuffer -m128k -s 256M -I 9090 & mbuffer -m128k -s 256M -O host:9090 | tar -xf -
memnoch_proxy

2
@memnoch_proxy : 좋은 제안입니다. (투표 한) 요즘 NSA에서 암호화를 사용하여 데이터 센터 (예 : Google과 Yahoo)간에 개인 데이터 라인을 활용하는 IMO는 항상 좋은 습관입니다. . 사용 ssh하면 간단합니다. 사용 stunnel, socat또는 것은 openssl너무 작동하지만, 그들은 간단한 전송을 위해 설정하는 더 복잡한 것.
bahamat

1
@bahamat 다시 질문을 봐 주셔서 감사합니다. VPN을 통해 전송이 발생할 수있는 경우에만 제 제안이 적절 해 보입니다. 인터넷 전송의 경우 확실히 ssh도 사용합니다.
memnoch_proxy

8

"rsync"에 대해 언급 했으므로 Linux를 사용한다고 가정합니다.

tar 또는 tar.gz 파일을 작성하지 않는 이유는 무엇입니까? 하나의 큰 파일의 네트워크 전송 시간은 많은 작은 파일보다 빠릅니다. 원하는 경우 압축 할 수도 있습니다 ...

압축이없는 타르 :

소스 서버에서 :

tar -cf file.tar /path/to/files/

그런 다음 수신 측에서 :

cd /path/to/files/
tar -xf /path/to/file.tar

압축 된 타르 :

소스 서버에서 :

tar -czf file.tar.gz /path/to/files/

그런 다음 수신 측에서 :

cd /path/to/files/
tar -xzf /path/to/file.tar.gz

rsync를 사용하여 (tar | tar.gz) 파일의 실제 전송을 수행하기 만하면됩니다.


아카이브 보관 장소가있을 경우에만 ..
Tebe

5

당신은 시도해 볼 수도 tarssh트릭 설명 여기 :

tar cvzf - /wwwdata | ssh root@192.168.1.201 "dd of=/backup/wwwdata.tar.gz"

이것은 다음에 다시 쓸 수 있어야 합니다 .

tar cvzf - /wwwdata | ssh root@192.168.1.201 "tar xvf -"

그러나 프로세스에서 --partial기능을 잃게됩니다 rsync. 파일이 자주 변경되지 않으면 느린 초기 이름으로 사는 것이 나중에 훨씬 더 빨라지 rsync므로 가치가있을 수 있습니다 .


2

rsync의 다양한 압축 옵션을 사용할 수 있습니다.

-z, --compress              compress file data during the transfer
     --compress-level=NUM    explicitly set compression level
     --skip-compress=LIST    skip compressing files with suffix in LIST

이진 파일의 압축 비율은 매우 낮으므로 --skip-compress (예 : iso, 이미 아카이브 및 압축 된 타르볼 등)를 사용하여 해당 파일을 건너 뛸 수 있습니다.


-6

저는 SFTP의 열렬한 팬입니다. SFTP를 사용하여 기본 컴퓨터에서 서버로 미디어를 전송합니다. LAN을 통해 좋은 속도를 얻습니다.

SFTP는 신뢰할 수 있으며 설정하기 쉽고 샷을 줄 수 있으며 경우에 따라 더 빠를 수도 있습니다.


5
FTP가 죽어야합니다. 그것은 암호화되지 않았으며, 방해를 잘 처리하지 못하며, 완전히 빨리 지 않는 최소한 6 가지 가능한 대안이 있습니다.
MDMarra

1
SFTP에 대해 들어 본 적이 있습니까?
Tillman32

8
그래요? 이름과 파일을 옮기는 것 외에는 FTP 프로토콜과 관련이 없습니다.
MDMarra

5
방화벽을 통과 할 때 FTP는 신뢰할 수없는 것으로 악명 높습니다 (클라이언트가 임의의 포트를 열어 백 연결을 수락하도록 방화벽을 설정 한 시점부터 시작되었습니다). Hackery)
voretaq7
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.