☰

두 컴퓨터 간에 대량의 데이터를 전송하는 가장 빠른 방법은 무엇입니까? [폐쇄]

tag-icon • tag-icon networking backup dd file-transfer
두 컴퓨터 간에 대량의 데이터를 전송하는 가장 빠른 방법은 무엇입니까? [폐쇄]

제가 자주 접하는 내용은 다음과 같습니다.

  • 320GB 하드 드라이브와 16GB RAM을 갖춘 원본 서버가 있습니다(정확한 사양은 여기에서 확인하실 수 있습니다, 그러나 이것은 다른 컴퓨터에서도 자주 발생하는 문제이기 때문에 대답이 "합리적인" Linux 컴퓨터에서 작동하기를 바랍니다.)
  • 몇 테라바이트의 하드 드라이브 공간을 갖춘 백업 서버가 있습니다(정확한 사양은 여기, 위 면책 조항 참조)

소스 서버에서 대상 서버로 320GB의 데이터(특히 의 데이터)를 전송하고 싶습니다 /dev/sda.

  1. 두 컴퓨터는 물리적으로 인접해 있으므로 두 컴퓨터 사이에 전선을 연결할 수 있습니다.
  2. 나는 LAN에 있고새로운 라우터를 사용하고 있어요, 이는 내 네트워크 속도가 "이상적으로" 1000Mbit여야 함을 의미합니다. 그렇죠?
  3. 안전은 문제가 되지 않습니다. 나는 로컬 네트워크에 있고 신뢰합니다모두라우터를 포함한 네트워크의 컴퓨터.
  4. (임의로 선택할 수 있는)데이터의 서명된 체크섬이 반드시 필요한 것은 아니지만 출력에서 ​​그냥 사라지는 대신 기본적인 오류 검사(패킷 손실 또는 읽을 수 없는 드라이브 등)가 감지되어야 합니다.

이 문제에 대해 웹을 검색하고 여러 명령을 테스트했습니다. 가장 일반적인 것은 다음과 같습니다.

ssh [email protected] 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

이 명령은 너무 느린 것으로 나타났습니다(한 시간 동안 실행되었으며 약 80GB의 데이터만 가져왔습니다). 1GB 테스트 패킷은 약 1분 22초가 소요되었으며, 이는 압축하지 않은 경우 두 배 빠른 속도입니다. 전송되는 파일이 소스 시스템의 RAM 용량보다 작기 때문에 결과가 왜곡될 수도 있습니다.

또한(1GB 테스트 조각에서 테스트됨) gzip명령을 사용하면 문제가 발생하며 dd대상에서 추출할 때 결과 파일은 직접 파이프할 때와 다른 체크섬을 갖습니다. 나는 아직도 왜 이런 일이 일어나는지 알아내려고 노력하고 있습니다.

답변1

서버는 물리적으로 서로 옆에 있고 귀하의 의견에서 물리적으로 액세스할 수 있다고 언급했으므로가장 빠른첫 번째 컴퓨터에서 하드 드라이브를 제거하고 두 번째 컴퓨터에 넣은 다음 SATA 연결을 통해 파일을 전송하면 됩니다.

답변2

netcat보안이 문제가 되지 않는 상황에 유용합니다.

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

GNU coreutils를 사용하는 경우 프로세스로 dd보낼 수 SIGUSR1있으며 진행 상황은 stderr로 보내집니다. BSD의 dd경우 SIGINFO.

PV복사 중에 진행 상황을 보고하는 것이 훨씬 더 유용합니다.

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

답변3

  1. 하다사용빠르게압축.

    • 어떤 전송 매체(특히 네트워크 또는 USB)를 사용하든 데이터를 사용하게 됩니다.탈출하다읽기, 캐싱, 쓰기에 사용되며 완전히 동기화되지는 않습니다.
    • 디스크 펌웨어, 디스크 캐시 및 커널/RAM 캐시 외에도 어떤 방식으로든 시스템의 CPU를 사용하여 디스크당 교환되는 데이터 양을 중앙 집중화할 수 있습니다.터지다그럼 당신은이렇게 해야 해.
    • 모든 압축 알고리즘은 자동으로 희소 입력 실행을 최대한 빠르게 처리하지만 네트워크 처리량에서 나머지를 처리할 수 있는 알고리즘은 거의 없습니다.
    • lz4최선의 선택입니다:

      LZ4는 코어당 400MB/s의 압축 속도를 제공하고 멀티 코어 CPU로 확장 가능한 매우 빠른 무손실 압축 알고리즘입니다. 또한 코어당 수 GB/초의 속도로 매우 빠른 디코더를 갖추고 있으며 종종 멀티 코어 시스템에서 RAM 속도 제한에 도달합니다.

  2. 가장 잘하는 일아니요불필요하게 추구합니다.

    • 이는 측정하기 어려울 수 있습니다.

    • 복사하려는 장치에 여유 공간이 많고 장치가 최근에 초기화되지 않았지만 모든 소스 파일 시스템을 복사해야 하는 경우 먼저 다음과 같이 시간을 들여 이 작업을 수행하는 것이 좋습니다.

      </dev/zero tee >empty empty1 empty2; sync; rm empty*

    • 하지만 소스코드를 어느 수준까지 읽어야 하는지에 따라 다릅니다. 종종 장치를 처음부터 끝까지 읽어야 하는 경우가 있습니다./dev/some_disk파일 시스템 수준에서 읽는 작업에는 일반적으로 디스크를 비순차적으로 앞뒤로 살펴보는 작업이 포함되기 때문입니다. 따라서 읽기 명령은 다음과 같아야 합니다.

      </dev/source_device lz4 | ...

    • 그러나 소스 파일 시스템 전체를 전송하지 않아야 하는 경우에는 파일 시스템 수준에서 읽는 것이 불가피하므로 입력을 단일 스트림에 집중해야 합니다. pax이 경우 일반적으로 이것이 가장 좋고 간단한 솔루션이지만 고려할 수도 있습니다 mksquashfs.

      pax -r /source/tree[12] | lz4 | ...
mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...

  3. 하다아니요암호화 ssh대.

    • 신뢰할 수 있는 매체에 암호화 오버헤드를 추가하는 것은 불필요하며 전송 속도를 심각하게 저하시킬 수 있습니다.계속되는전송 중에 읽은 데이터를 읽어야 합니다.두 배.
    • 이것PRNG무작위성을 유지하려면 데이터 또는 그 중 적어도 일부를 읽어야 합니다.
    • 물론 데이터도 전송해야 합니다.
    • 또한 암호화 오버헤드 자체를 전송해야 합니다. 이는 전송할 데이터가 적고 작업이 더 많다는 것을 의미합니다.버스트할 때마다.

    • 그래서 당신은 사용해야합니다netcat(아니면 내 뜻대로,nmap더욱 강력한 프로젝트 역량ncat) 간단한 웹 사본의 경우 다른 곳에서 제안한 대로:

      ###  on tgt machine...
nc -l 9999 > out.lz4
###  then on src machine...
... lz4 | nc tgt.local 9999

답변4

우리는 이 문제를 정기적으로 해결합니다.

우리가 주로 사용하는 두 가지 주요 방법은 다음과 같습니다.

  1. SATA/eSATA/스니커즈 네트워크
  2. 직접 NFS 마운트를 수행한 후 로컬 cp또는rsync

첫 번째는 드라이브를 물리적으로 재배치할 수 있는지 여부에 따라 다릅니다. 항상 그런 것은 아닙니다.

두 번째는 놀랍게도 잘 작동했습니다. 일반적으로 직접 NFS 마운트를 사용하면 최대 1Gbps 연결에 쉽게 도달할 수 있습니다. scp, dd over ssh 또는 이와 유사한 것을 사용하여 이를 달성할 수 있는 방법은 없습니다(의심스러울 정도로 최대 속도가 100mpbs에 가까운 경우가 많습니다). 매우 빠른 멀티 코어 프로세서에서도 두 시스템 중 가장 느린 코어의 최대 암호화 처리량으로 인해 병목 현상이 발생합니다. 이는 암호화되지 않은 네트워크 설치의 풀 보어 cp 또는 rsync에 비해 엄청나게 느립니다. 사람들은 우울합니다. 때때로 iops 벽에 부딪혀 보다 일반적인 110MB/s 대신 약 53MB/s에서 멈추는 경우가 있지만 소스나 대상이 그렇지 않은 한 일반적으로 수명이 짧습니다.실제로하나의 드라이브를 사용하면 드라이브 자체의 지속 속도에 의해 제한될 수 있습니다(실제로 시도해 보기 전까지는 임의의 이유로 인해 속도가 크게 달라지는지 알 수 없음). 흠.

NFS는 익숙하지 않은 배포판에 있는 경우 설정하기가 약간 성가실 수 있지만 일반적으로 파이프를 최대한 많이 채우는 가장 빠른 방법입니다. 지난번에 10Gbps 이상으로 이 작업을 수행했을 때 실제로는 최대 연결에 도달했는지 전혀 알 수 없었습니다. 커피를 마시고 돌아오기 전에 전송이 끝났기 때문입니다. 따라서 자연스러운 한계에 도달했을 수도 있습니다. 원본과 대상 사이에 일부 네트워크 장비가 있는 경우 네트워크 링크 효과로 인해 약간의 지연이나 중단이 발생할 수 있지만 일반적으로 이는 사무실 전체(다른 트래픽을 방해하지 않고) 또는 데이터 한쪽 끝에서 수행될 수 있습니다. (내부적으로 일종의 필터링/확인을 수행하지 않는 한,이 경우 모든 베팅은 취소됩니다.).

편집하다

압축에 대한 논의가 있는 것을 발견했습니다.아니요압축 연결. 암호화 계층처럼 속도가 느려집니다. 연결을 압축하면 병목 현상은 항상 단일 코어가 됩니다(그리고 해당 코어의 버스를 특히 잘 활용하지도 못할 것입니다). 귀하의 경우, 가장 느린 방법은 연결 속도가 1Gbps 이상인 인접한 두 컴퓨터 간에 암호화되고 압축된 채널을 사용하는 것입니다.

미래를 마주하다

이 권고사항은 2015년 중반부터 유효하다. 이것은 거의틀림없이앞으로 몇 년 동안은 그렇지 않을 것입니다. 따라서 모든 것을 가볍게 생각하고 이 작업에 정기적으로 직면한다면 다양한 방법을 시도해 보십시오.실제 부하네트워크 트래픽 등에 대한 이론적 최적 또는 관찰된 일반적인 압축/암호화 처리량에 가까운 것을 얻을 것이라고 상상하지 마십시오.많은텍스트는 무엇입니까?(팁: 대량 전송은 일반적으로 주로 이미지, 오디오, 비디오, 데이터베이스 파일, 바이너리 코드, Office 파일 형식 등으로 구성됩니다.이미 압축됨나름대로의 방식으로 압축 블록 크기가 이미 압축된 바이너리 데이터와 잘못 정렬되는 것이 거의 보장되는 다른 압축 루틴을 실행하면 이점이 거의 없습니다...).

나는 SCTP와 같은 개념이 미래에 더 흥미로운 곳으로 옮겨갈 것이라고 상상합니다. 여기서는 결합 연결(또는 스펙트럼에 따라 내부적으로 결합된 채널화된 광섬유 연결)이 일반적이고 각 채널은 다른 채널과 독립적으로 스트림을 수신할 수 있으며 각 채널은 스트림을 수신할 수 있습니다. . 스트림은 병렬로 압축/암호화될 수 있습니다. 훌륭해요! 그러나 2015년에는 그렇지 않습니다. 환상과 이론화는 모두 훌륭하지만 우리 대부분은 Watson에 대한 답변을 생성하기 위해 Blue Gene/Q의 내장에 직접 데이터를 공급하는 냉동고에서 맞춤형 스토리지 클러스터를 실행하지 않습니다. 그것은 현실이 아닙니다. 또한 압축이 좋은 생각인지 판단하기 위해 데이터 페이로드를 철저하게 분석할 시간도 없었습니다. 방법을 아무리 잘못 선택하더라도 분석을 완료하기 전에 전송 자체가 종료될 것입니다.

하지만...

변화하는 시대압축과 암호화에 대한 나의 제안은 받아들일 수 없습니다. 이 조언이 뒤집힐 수 있기를 바랍니다.전형적인곧. 그것은 내 인생을 더 쉽게 만들 것입니다.

관련 정보