미국에서 영국 데이터 센터로 10TB의 파일 전송


96

서버를 미국에서 영국으로, 한 데이터 센터에서 다른 데이터 센터로 마이그레이션하고 있습니다. 호스트는 초당 11MB를 달성 할 수 있어야한다고 말했습니다.

운영 체제는 양쪽 끝에 Windows Server 2008입니다.

내 평균 파일 크기는 약 100MB이며 데이터는 5 개의 2TB 드라이브로 분할됩니다.

이러한 파일을 전송하는 데 권장되는 방법은 무엇입니까?

  • FTP
  • SMB
  • Rsync / Robocopy
  • 다른?

어쨌든 공개 파일이기 때문에 보안에 대해 신경 쓰지 않았지만 전체 전송 시간을 최소화하기 위해 전체 11MB / s 전송 속도를 누를 수있는 솔루션을 원합니다.


19
11MB / s 또는 11Mb / s?
wim

14
이진 펀치 카드로 데이터를 전송하고 캐리어 비둘기를 사용 :)
enterzero

9
세부 사항을 제공해야합니다. 캐리어 비둘기는 몇 마리나 필요할까요? 당신의 일을 보여주십시오.
Evik James

18
@Evik 유럽 또는 아프리카?
wim

8
그 외에도 Wolfram Alpha는 "11TB / s에서 10TB"를 계산하는 가장 편리한 방법입니다. wolframalpha.com/input/?i=10+TB+at+11MB%2Fs
복어

답변:


173

대신 바다를 가로 질러 하드 드라이브를 배송하십시오.

전체 사용률이 11Mbps 인 경우 10TB를 전송하는 데 90 일이 걸리는 것입니다.


11Mbps = 1.375Mbps = 116.015GB / 일 .

1만2백40기가바이트 / 116.015 GB / 일 = ~ 88.3 일 .


42
+1 체크를하면서 . 또한 TCP / IP 오버 헤드를 잊었습니다. 이상적인 상황에서 ~ 100 일이 더 낫습니다.
Chris S

43
한 현명한 사람은 "고속도로를 다치게하는 테이프로 가득한 스테이션 왜건의 대역폭을 과소 평가하지 마십시오"라고 말했습니다. 이 방정식은 매우 사실이며 보트의 스테이션 왜건을 변경하여 실질적으로 변경되지는 않습니다. ( bpfh.net/sysadmin/never-underestimate-bandwidth.html )
Rob Moir

5
드라이브보다는 테이프 또는 블루 레이 디스크를 배송하는 것이 좋습니다. 드라이브를 사용하는 경우 원본을 안전하게 보관하고 만일을 위해 사용할 수 있도록하십시오. 10TB = 410 단일 레이어 블루 레이 디스크이기 때문에 드라이브에 직접 갈 것입니다 (Ultrium 4 드라이브가없는 경우).
Allen

9
내가 11Mbps를 입력했다는 것을 깨달았지만 실제로는 11MB / s였습니다. 나는 이것이 상당히 큰 차이를 만든다고 가정하고, 계산에 따르면 대략 11-14 일이 소요됩니다 ... 이것이 맞습니까?
Paul Hinett

18
그래도 공식 디스크가 작동하는 동안 10TB 백업으로 사람을 보내면 설정이 완료되면 rsync를 점심 식사로 변경하여 새 서버를 업데이트 할 수 있습니다. 하루 정도면 기계를 가동시킬 수 있습니다.
Loïc Faure-Lacroix

26

rsync라고 말하면 11MB / s에서 10-14 일을 볼 수 있으며 중단 되더라도 rsync는 마지막에 중지 된 위치에서 쉽게 시작됩니다.

11 Mbps에서 위에서 제안한 것처럼 하드 디스크를 배송했습니다. :)


1
귀하의 견적은 다른 사람들이 게시 한 내용과 크게 다릅니다 (그리고 누가 정확한지 모르겠습니다). 해당 수치에 도달하기위한 방법론을 제공 할 수 있습니까?
John Gardeniers

9
그 차이는 실제로 11Mbps를 의미 할 때 11Mbps를 놓치는 OP에서 8 배 더 빠릅니다. BTW, 중단의 경우 10TB rsync를 다시 시작하면 시간이 오래 걸리지 않습니까? 몇 시간 이상?
Frank Farmer

@ FrankFarmer : rsync 재시작에 대해 걱정하지 않습니다. 30Mbps 무선 회선을 통해 오프 사이트 사본을 ~ 20TB로 유지하고 재시작 범위는 초입니다. 초기 사본은 몇 주가 걸렸지 만 야간 업데이트는 보통 몇 시간입니다.
Javier

@ FrankFarmer-rsync가 매우 잘 확장되는 것 같습니다. 나는 운동화로 초기화 된 농촌 ADSL1 라인보다 ~ 2TB가 있지만 아무것도 바뀌지 않으면 매일 밤 rsync하는 데 ~ 5 분이 걸립니다.
Flexo

6
rsync 재시작 시간 stat은 총 데이터가 아닌 파일 수 (주로 시간에 따라)로 확장됩니다 . 나는 상당한 기다림을 기대하지 않을 것입니다 (최대 몇 분). rsync에 대한 나의 경험은 5TB 미만에서 약간 뛰어납니다.
derobert

15

물론 Rsync.

최소한 휴식 후 언제라도 계속할 수 있으며 통증이 없습니다.


7
100 % 사용률로 복사하는 데 3 개월 이상. 미안하지만, 그렇게 많은 데이터를 전송하는 끔찍한 방법입니다.
Chris S

@ChrisS에 동의해야합니다 rsync. 큰 파일을 복사 하는 것만으로는 효율적이지 않습니다. 내 물건에 대해 tar이상 netcat또는 ssh초기 전송을 사용했습니다. 훨씬 빠르며 즉시 전송되기 시작하지만 rsync시간이 걸리는 모든 파일을 먼저 스캔합니다. 이것이 중단되면 여전히 사용할 수 있습니다 rsync. 사실, 나는 때때로 tar모든 권한, 소켓 파일 등이 올바른지 확인하기 위해이 작업을 수행 합니다.
Martin Scharrer

1
OP가 11Mb가 아닌 ~ 100Mb 연결을 수정 한 후에 rsync가 훨씬 더 의미가 있습니다. 처음 언급 한 +1
Chris S

12

테이프로 가득한 스테이션 왜건의 대역폭을 과소 평가하지 마십시오

-Trad.

귀하의 경우, 택배로 발송 된 디스크 또는 테이프이지만 원칙은 여전히 ​​적용됩니다. 대기 시간에 대해 걱정하지 않으면 합리적인 시간 내에 10TB의 데이터를 전송하는 데 네트워크 대역폭보다 훨씬 저렴합니다.


제프 앳 우드는 그의 오래된 코딩 호러 게시물 중 하나에 번호를 달렸다 .. codinghorror.com/blog/2007/02/the-economics-of-bandwidth.html
tardate

10

rsync를 사용해야합니다. 전송하기 전에 데이터 를 압축 하고 중복 제거 합니다. 또한 부분 전송을 재개 할 수 있으며, 이는 큰 전송에 매우 중요합니다.

10TB를 전송하지 않을 수 있습니다. 로그와 텍스트 등의 경우 1TB 미만일 수 있습니다. 아마도 1TB 미만일 것입니다.

rsync보다 더 나은 압축 작업을 수행하고 더 많은 일치 항목을 찾을 수있는 도구가 있습니다. lrzip등을 사용할 수 있습니다 .

압축률이 낮고 리터럴 속임수 (예 : 비디오 및 기타 미디어)를 포함하지 않는 특정 유형의 데이터가 있습니다. 이 경우 FTP와 rsync는 거의 동일한 노력을 기울이고 있습니다.


3
RSync는 데이터를 중복 제거합니까? 필자는 파일 수준에서만이 작업을 수행한다고 생각합니다.이 경우 중복 제거는 거의 쓸모가 없습니다.
devicenull

6

이미 승인되었지만 디스크를 더 많은 대역폭을 얻을 수있는 데이터 센터 / 제공자 / 호스트로 가져가는 것을 고려 했습니까? 아마도 돈이 들겠지만 10240Gb를 백업 디스크에 복사하고 전송하는 데는 시간과 돈이 모두 든다 (2 x 돈).

또한 디스크가 전송 중 손상되지 않도록해야합니다.


이 답변은 허용되는 답변과 어떻게 다릅니 까?
Chris S

2
@Chris이 답변은 디스크를 같은 대륙의 더 큰 파이프로 운반 할 것을 제안합니다.
Alex Jasmin

5

11Mbps? 이것은 당신이 여기에 꽤 제한 사항입니다. 당신의 상황에서 나는 간단하게 :

  • 데이터 복제
  • 그것을 압축
  • 같은 데이터 센터에서 또는 근처의 데이터 센터에서 최소 10 배 이상의 대역폭으로 양쪽 끝에서 서버를 임대하십시오.
  • 파일 전송
  • 새 서버에 데이터를 적용하십시오.

대역폭을 늘릴 솔루션이 없다면 ... 물리적 드라이브를 더 빨리 운송 할 수 있습니다.

내 고통스런 경험에서 하드 드라이브는 메일에서 깨지는 경향이 있습니다 ... USB 플래시 드라이브는 빈번한 데이터 전송을위한 더 나은 솔루션입니다. 귀하의 경우에는 몇 가지가 필요합니다 :) 따라서 여러 개의 하드 드라이브에 2 개의 데이터 사본을 보내십시오.

데이터 양을 고려할 때 다른쪽에 동일한 하드웨어 / 소프트웨어가있는 경우 드라이브를 연결하는 경우 RAID 5 또는 RAID 6 어레이에서 드라이브를 보낼 수도 있습니다. 그러나이 경우 드라이브 순서를 표시해야합니다. 일련 번호는 재구성 할 때 혼동되지 않습니다.


1
죄송합니다, 11Mbps는 타입이 잘못되었습니다. 11MB / s입니다. 위의 의견 중 하나에서 언급 한 적이 있습니다.
Paul Hinett

4

이 경우 "하드 드라이브를 사용하여 제공"답변에 동의해야하지만, 처음으로 대량의 파일을 복사해야 할 때 사용하는 복사 솔루션입니다.

rsync두 개의 데이터 스토리지를 동기화 상태로 유지 하는 것이 좋지만 초기 전송에 약간의 불필요한 오버 헤드가 발생합니다. 나는 가장 빠른 방법은 tar파이프를 통해 얻는다 는 것을 알았 습니다 netcat. 수신기 사이트에서 당신은 또한 사용할 수 있습니다 netcat에서 들을 수 있는 추출에 파이프 들어오는 데이터를 모드 tar. 이점은 tar즉시 전송 을 시작하여 netcat추가 상위 프로토콜 오버 헤드없이 일반 TCP 스트림으로 전송한다는 것입니다. 이 속도는 빨라야합니다. 그러나 마지막 위치에서 중단 된 전송을 다시 시작하는 것은 간단하지 않습니다.

올바른 tar옵션 을 사용하여 전송 데이터를 쉽게 압축 하거나 파이프에 압축 도구를 추가 할 수도 있습니다. 그 주 netcat암호화되지 않은 날짜를 보냅니다. 옵션이 아닌 경우 암호화 된 ssh연결을 대신 사용할 수 있습니다 ( tar <options> | ssh <target> -c 'tar -x <options>').

모든 데이터가 전송 rsync되면 그 동안 업데이트 된 모든 파일이 동기화되도록 할 수 있습니다. 또한 IIRC tar는 그렇지 않으면 손실되는 소켓을 만들지 않지만 데이터 센터 데이터에는 실제로 사용되지 않습니다.


단점은
개입

3

IPoAC 를 고려 습니까?

비둘기 한 마리가 약 1 시간 동안 수십 기가 바이트의 데이터를 운반 할 수 있는데, 이는 평균 대역폭을 기준으로 잃어버린 드라이브를 고려할 때도 현재 ADSL 표준과 매우 유리합니다.


21
비둘기는 OP가 묘사 한 거리에서 신호 손실을 겪을 것입니다.
Roy Tinker

@RoyTinker Cleared IPoAC는 윈도 잉 프로세스를 사용하여 구현해야합니다.
JamesBarnett

3

다시, 첫 번째 제안은 드라이브를 선적하는 것입니다.

두 번째 제안은 SSH를 사용하지 않고 rsync를 사용하여 rsyncd를 사용하는 것입니다. 나는 많은 것을 시도했지만 일반적으로 가장 빠릅니다. 압축을 켜십시오. 또한 최적의 전송 속도를 얻으려면 rsync 버퍼 크기늘리거나 줄이십시오 . 또한 MTU 크기늘리는 데 도움이 될 수 있습니다 . 이것은 라우팅중인 라우터가 패킷을 조각화하지 않는 경우에만 도움이됩니다. 그들이 있는지 판단하는 방법이 있습니다.

불행히도 항상 가장 좋은 설정은 없습니다. 상황에 가장 적합한 것이 무엇인지 알아 내기 위해 실험을해야합니다.


2

서버에서 Windows 2008을 실행하고 있다고 언급했습니다. Microsoft DFS 가 적합합니까? 하단부에는 가능한 한 많은 대역폭을 연결 밖으로 가져 오려고 시도하고 압축 및 중복 제거 (IIRC) 기능이있는 마술이 있습니다.

하드 드라이브, DVD 또는 BluRays가 더 빠를 것입니다 ... 계산 시간은 11MB / s로 11 일입니다.


1

이를 위해 토렌트를 사용할 수 있습니다.

한쪽에 개인 토런트를 작성하고 다른쪽에 클라이언트를 사용하십시오.

암호화가 있지만 요구 사항을 확인해야합니다.


1
일대일 토렌트 관계는 일대일 파일 전송보다 낫지 않습니다. 두 사이트 사이에 파이프가 제한되어 있으면 지리적으로 분산 된 다른 파이프에 여러 파종기가 필요합니다.
Jeremy

@ Jeeremy-처리량 측면에서 더 나쁘지 않습니다. 이 크기에 대해 xfer가 중요 할 수있는 안정성 (쉬운 일시 중지 / 재개) 측면에서 더 나을 수 있습니다.
Joel Coel
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.