대기 시간이 긴 고속 WAN 링크를 통해 큰 파일 하나를 전송하는 가장 좋은 방법은 무엇입니까?


21

이것은 이것과 관련 있지만 다소 다릅니다.

두 회사 사이트간에이 WAN 링크가 있으며 매우 큰 단일 파일 (Oracle 덤프, ~ 160GB)을 전송해야합니다.

우리는 전체 100 Mbps 대역폭 (테스트)을 얻었지만 TCP가 작동하는 방식 (ACK 등)으로 인해 단일 TCP 연결이 최대 크기를 초과하지 않는 것처럼 보입니다. 우리는 iperf 와의 링크를 테스트했으며 TCP Window Size를 증가시킬 때 결과가 급격히 변합니다. 기본 설정으로 ~ 5Mbps의 처리량을 얻습니다. WS가 클수록 최대 ~ 45Mbps까지 얻을 수 있지만 그 이상은 아닙니다. 네트워크 대기 시간은 약 10ms입니다.

호기심으로 인해 하나 이상의 연결을 사용하여 iperf를 실행했으며 그 중 4 개를 실행할 때 각각 ~ 25Mbps의 속도를 달성하여 사용 가능한 모든 대역폭을 채우는 것으로 나타났습니다. 따라서 키는 여러 동시 전송을 실행하는 것으로 보입니다.

FTP를 사용하면 상황이 악화됩니다. 최적화 된 TCP 설정 (높은 창 크기, 최대 MTU 등)을 사용하더라도 한 번의 전송으로 20Mbps를 초과 할 수 없습니다. 우리는 동시에 일부 큰 파일을 FTP로 시도했지만 실제로는 단일 파일을 전송할 때보 다 훨씬 나아졌습니다. 그러나 같은 디스크 병목 현상에서 4 개의 큰 파일을 읽고 쓰는 것이 곧 원인이기 때문에 범인은 디스크 I / O가되었습니다. 또한, 우리는 하나의 큰 파일을 더 작은 파일로 분할 한 다음 다시 합병 할 수없는 것처럼 보입니다 (적어도 허용 가능한 시간이 아닌 시간에 파일을 병합 / 복구 할 수는 없습니다). 전송).

여기서 이상적인 솔루션은 파일의 다양한 청크를 동시에 전송할 수있는 다중 스레드 도구입니다. eMule이나 BitTorrent와 같은 P2P 프로그램은 이미 존재하지만 단일 소스에서 단일 대상까지입니다. 이상적으로는이 도구를 사용하여 사용할 병렬 연결 수를 선택하고 파일의 여러 섹션간에 미친 듯이 점프하지 않도록 디스크 I / O를 최적화 할 수 있습니다.

누구든지 그런 도구를 알고 있습니까?

아니면 더 나은 솔루션이나 우리가 이미 시도하지 않은 것을 제안 할 수 있습니까?

추신 : 우리는 이미 테이프 / 디스크에 백업하여 물리적으로 대상으로 보내는 것을 생각했습니다. WAN이 문제를 해결하지 않으면 이것이 우리의 극단적 인 척도 일 것입니다. 그러나 AS Tanenbaum이 말했듯이 "고속도로를 손상시키는 테이프로 가득 찬 스테이션 왜건의 대역폭을 과소 평가하지 마십시오."


1
호기심에서 실제로 그렇게 시간이 걸리나요? 또한 160Gb 전송 기간 동안 링크를 포화 상태로 유지하면 나머지 네트워크에 영향을 미치지 않습니까?
Bryan

6
99 년에 일부 DLT 오토로더와 수백 개의 카트리지를 고객에게 제공 한 것을 기억합니다. 우리는 약 200TB의 DLT IV 카트리지가 장착 된 차량의 원시 용량 (각각 35GB의 원시 용량)을 약 6.3TB로 계산했습니다. 나는 약 55 분 동안 사무실에서 고객 사이트로 이동하여 "지하철을 운전하는 것과 같은 Geo Metro 차량에서의 주행"백업 전송 메커니즘에 약 118GB / 분의 유효 처리량을 제공했습니다. 좋은 처리량하지만 대기 시간이 살인자이었다 ...> 미소 <
에반 앤더슨

Bryan : 그렇습니다. 시간은 매우 중요합니다 (표준 FTP 및 표준 네트워크 설정으로 TWENTY HOURS 소요). 아니오, 전송은 근무 외 시간에 예약되므로 링크를 포화시키는 데 아무런 문제가 없습니다.
Massimo

에반 : 바로 그게 내 뜻이야 ;-)
Massimo

~ 200GB의 SQL .bak를 사용하여 비슷한 상황을 처리했지만 WAN 링크를 포화 상태로 만들 수있는 유일한 방법은 FTP를 사용하는 것입니다. 나는 압축을 0으로하여 7-zip을 사용하여 512MB 청크로 나누었습니다. "압축"및 "압축 해제"시간은 상당히 짧았습니다. 전국적으로 실제 미디어를 삽질하는 것보다 훨씬 낫습니다. (사이트는 미국 반대편에 있습니다)
Adrien

답변:


15

"높은 대기 시간 파일 전송"을 검색하면 많은 흥미로운 히트가 발생합니다. 분명히 이것은 CompSci 커뮤니티와 상업 커뮤니티 모두가 굳건한 문제입니다.

청구서에 맞는 것으로 보이는 몇 가지 상용 제품 :

  • FileCatalyst 에는 UDP 또는 여러 TCP 스트림을 사용하여 대기 시간이 긴 네트워크를 통해 데이터를 스트리밍 할 수있는 제품이 있습니다. 그들은 다른 많은 기능들도 가지고 있습니다 (즉시 압축, 델타 전송 등).

  • Aspera 의 fasp 파일 전송 "기술"은 찾고자하는 청구서에도 적합합니다.

오픈 소스 세계에서는 uftp 프로젝트가 유망 해 보입니다. 특히 멀티 캐스트 기능이 필요하지는 않지만 파일을 수신자에게 분사하고 전송이 끝날 때 누락 된 블록에 대한 NAK를 수신 한 다음 NAK의 블록을 분사 (헹굼, 반복)하는 기본 아이디어 파일 전송이 한 번 완료 될 때까지 수신기에서 ACK (또는 NAK ')가 없기 때문에 필요한 작업을 수행하는 것처럼 들립니다. 네트워크가 잠복적이고 손실이 없다고 가정하면 필요한 작업도 수행 할 수 있습니다.


uftp는 정말 유망 해 보입니다. 두 데스크탑 컴퓨터 사이에서 30Mbps를 달성 할 수있었습니다 (디스크 성능면에서는 그리 좋지 않습니다). 곧 "실제"서버에서 테스트하겠습니다. 등록 양식의 일부 버그로 인해 FileCatalyst 데모 라이센스를 얻을 수 없었으며 (요청 숫자가 이미 사용되었다고 계속 말함) fasp는 제공하지 않습니다.
Massimo

적절한 디스크와 큰 수신 버퍼가있는 두 컴퓨터간에 60Mbps. 큰!
Massimo

무료 / 오픈 소스 소프트웨어를 좋아합니다! > smile <확실히 uftp에 내가하고있는 것들을 시도해 보겠다. 몇 년 전에 "udpcast"를 사용하여 만든 Linux 기반 멀티 캐스트 디스크 이미징 솔루션에서 어떻게 작동하는지 궁금합니다.
Evan Anderson

얼마 전 나는 serverfault.com/questions/173358/multicast-file-transfers를 요청했다. 결국 uftp와 mrsync가 선택 도구라는 결론에 도달했다. uftp와 관련하여 유용한 정보가 있다면 올해 의견을 적어주십시오. 올해도 회의를 준비 할 것입니다.
Jed Daniels

2
UFTP, UDT 및 Tsunami UDP로 작업 할 때 UFTP는이 세 가지 중에서 가장 성능이 떨어졌습니다. 물론 가장 성숙한 프로토콜 일 것입니다. UDT는 단순한 전송 프로토콜 만 제공하며 사용자 정의 소프트웨어를 개발하기위한 라이브러리 역할을하도록 설계되었으며 Tsunami의 저자는 실제로 시간 부족으로 인해 Tsunami가 활발히 개발되지 않았기 때문에 실제로 UDT를 가리 켰습니다.
Thomas Owens

9

정말 이상한 제안입니다 .. 네트워크에서 파일을 호스팅 할 간단한 웹 서버를 설정 한 다음 (실수로 nginx를 제안합니다), 다른쪽에는 firefox가있는 PC를 설정하고 DownThemAll 확장을 설치하십시오 .

청킹 및 재 조립을 지원하는 다운로드 가속기입니다.
재 조립을 위해 각 다운로드를 10 개의 청크로 나눌 수 있으며 실제로는 작업 속도가 빨라집니다!

(캐비티 : 160GB 정도의 크기로 시도한 적이 없지만 20GB iso 파일과 잘 작동합니다)


동일한 컴퓨터간에 40Mbps 정말 좋아 보인다.
Massimo

1
firefox를 axel.alioth.debian.org로 바꾸십시오 . 제안이 그렇게 나쁘지는 않습니다.
저스틴

7

UDT의 전송은 아마 대기 시간이 통신을위한 가장 인기있는 교통입니다. 이것은 섹터 / 스피어 (Sector / Sphere) 라는 "고성능 분산 파일 시스템 및 병렬 데이터 처리 엔진" 이라는 다른 소프트웨어로 이어질 가치가 있습니다.


1
대기 시간이 길고 패킷 손실이 큰 네트워크를 통한 전송을 위해 UDT와 일부 작업을 수행했습니다. UDT는 TCP 기반 프로토콜보다 대기 시간과 패킷 손실에 훨씬 더 탄력적입니다. 특히 네트워크 지형에 맞게 혼잡 제어 알고리즘을 변경하면 더욱 그렇습니다.
토마스 오웬스

UDT가 내장 된 rsync 버전도 있으며 "UDR"이라고합니다. github.com/LabAdvComp/UDR
최대

5

내 대답은 약간 늦었지만 방금이 질문을 발견했으며 화려 함을 찾았습니다. 검색하는 동안 나는 이것을 발견했다 : http://tsunami-udp.sourceforge.net/ , "Tsunami UDP Protocol".

그들의 웹 사이트에서 :

TCP 제어 및 UDP 데이터를 사용하여 초고속 장거리 네트워크 (≥ 1 Gbps 및 심지어 10 GE)를 통해 전송하는 빠른 사용자 공간 파일 전송 프로토콜로, 동일한 네트워크에서 TCP로 처리 할 수있는 것보다 더 많은 처리량을 제공하도록 설계되었습니다. 네트워크.

속도에 관한 한,이 페이지는 1GBit 링크를 통해 핀란드 헬싱키와 독일 본 사이의 링크를 사용하여이 결과를 언급합니다.

그림 1-평균 800Mbit / 초의 인터넷을 통한 국제 전송

다운로드 가속기를 사용하려면 lftp를 살펴보십시오. 이것이 아는 한 재귀 미러를 수행 할 수있는 유일한 다운로드 가속기입니다.


1
Steve-o의 답변에서 앞서 언급 한 프로젝트에서 우리는 UDT, Tsunami UDP 및 UFTP를 벤치마킹했습니다. 지연 시간은 성능에 큰 영향을 미치지 만 패킷 손실은 (쓰나미 문서와 달리) 영향을 미치지 않습니다. 테스트 네트워크에 100ms의 대기 시간을 추가하면 쓰나미의 성능이 초당 약 250Mbits / 초에서 약 50Mbits / 초로 떨어졌습니다 (내 숫자와 단위가 적절하다고 생각합니다. 반면, 최소 대기 시간 네트워크없이 10 % 패킷 손실을 추가하면 초당 250Mbits에서 약 90Mbits / 초로 성능이 저하됩니다.
Thomas Owens

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.