▲

GN⁺: NVMe TCP를 통한 노트북 복제

 (copyninja.in)
2P by neo 8달전 | favorite | 댓글 1개

NVME TCP를 이용한 노트북 복제

  • 최근 새 노트북을 구입하고 사용을 위해 설정해야 했음.
  • 기존에 알려진 단계를 반복하는 것에 대한 의욕이 없었음.
  • 동료의 제안으로, 기존 디스크를 새 노트북에 복사하는 방법을 고려함.

복제 과정에 대한 의문

  • 기존 노트북을 열고 새 디스크를 USB로 연결하는 도구가 없음.
  • 전체 디스크 암호화를 사용하고 있으며, 기존 노트북은 512GB, 새 노트북은 1TB NVME를 사용함.
  • LUKS 파티션 크기 조정에 익숙하지 않음.

동료의 제안

  • NVME over TCP를 사용하여 디스크를 네트워크를 통해 공유하고 전체 디스크 복사를 수행하라고 제안함.
  • 제안된 단계는 다음과 같음:
    • 기존 노트북에서 nvmet-tcp를 사용하여 디스크를 내보냄.
    • 새 노트북으로 디스크 복사를 수행함.
    • 파티션을 1TB 전체를 사용하도록 크기 조정함.
    • LUKS 크기를 조정함.
    • 마지막으로 BTRFS 루트 디스크의 크기를 조정함.

NVME TCP를 통한 디스크 내보내기

  • systemd-storagetm.service를 사용하는 것이 가장 쉬운 방법으로 제안됨.
  • 대신 GRML 구조 CD로 두 노트북을 부팅하고 nvmet-tcp 모듈을 사용하여 NVME 디스크를 내보내는 단계를 수행함.

디스크 복사

  • dd 명령을 사용하여 루트 디스크를 새 노트북으로 복사함.
  • 새 노트북에 이더넷 포트가 없어서 Wi-Fi만을 사용해야 했으며, 전체 512GB를 복사하는 데 약 7시간 반 소요됨.
  • 복사 속도는 약 18-20MB/s였음.

파티션 및 LUKS 컨테이너 크기 조정

  • parted를 실행했을 때 파티션 테이블이 디스크 크기와 일치하지 않는 것을 감지하고 수정을 요청함.
  • cloud-guest-utils를 설치하여 growpart를 사용하여 파티션을 1TB까지 확장함.
  • cryptsetup-resize를 사용하여 LUKS 컨테이너 크기를 증가시킴.
  • 시스템에 로그인한 후 BTRFS 파일 시스템의 크기를 조정함.

결론

  • 이 과정의 유일한 이점은 새 노트북을 사용하면서 기존 노트북을 사용하는 것과 같은 느낌을 가질 수 있다는 것임.
  • 새 노트북을 설정하는 데 일반적으로 1~2주가 걸리지만, 이 경우 그 시간을 절약할 수 있음.
  • NVME over TCP를 사용하여 디스크를 내보내는 방법을 배웠다는 추가적인 이점이 있음.

GN⁺의 의견

  • NVME over TCP를 이용한 노트북 복제는 기존 시스템 환경을 새 하드웨어로 빠르게 이전할 수 있는 효율적인 방법을 제시함.
  • 이 기술은 시스템 관리자나 개발자들에게 시간을 절약하고 설정 오류를 최소화할 수 있는 방법으로 흥미를 줄 수 있음.
  • 그러나 네트워크 속도에 크게 의존하며, Wi-Fi만 사용할 경우 상당한 시간이 소요될 수 있어 이는 고려해야 할 단점임.
  • 유사한 기능을 제공하는 Clonezilla나 Acronis 같은 도구들이 있으나, NVME over TCP는 네트워크를 통한 직접적인 디스크 접근이라는 독특한 이점을 가짐.
  • 이 기술을 도입할 때는 네트워크 설정, 암호화된 디스크의 처리, 파일 시스템의 크기 조정 등에 대한 충분한 지식이 필요함.
▲
neo 8달전  [-]
Hacker News 의견

  • 저자의 시나리오에서는 NVMe/TCP를 사용하는 이점이 없음. 단순히 dd를 사용하여 직렬 블록 복사를 수행하기 때문에 동시 I/O를 활용하지 못함. 복잡한 명령어들은 간단한 netcat으로 대체 가능.

    • 목적지 노트북에서는 $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M 사용.
    • 출발지 노트북에서는 $ nc x.x.x.x 1234 </dev/nvme0nX 사용.
    • 목적지에서 dd는 쓰기 작업을 버퍼링하여 더 빠르고 효율적으로 만듦. 출발지/목적지에서 gzip/gunzip을 추가하면 디스크가 가득 차 있지 않은 경우 전체 작업이 훨씬 빨라짐. 이 방법은 네트워크를 통해 PC 이미지를 만드는 가장 좋아하는 방법임. gzip에 --fast 옵션을 전달하거나, 더 빠른 lz4/unlz4로 대체하는 것이 좋음. 최근에 1TB NVMe가 있는 새로운 윈도우 노트북을 이미징할 때 사용했으며, GigE를 통해 20분 정도 걸렸고 결과 이미지는 20GB였음. 보통 이 lz4 이미지를 백업하고 몇 년 후 노트북을 기부할 때 unlz4 | dd로 복원함. 매우 편리함.
    • Linux 커널 모듈 nvme-tcp에 대해서는 몰랐지만, 매일 새로운 것을 배움. 이 모듈의 유용성은 dd로 원시 접근하는 것보다는 원격 NVMe에 파일 시스템을 마운트하는 데 더 있음.
    • Linux에서 최대 파이프 버퍼 크기는 64kB이므로 dd bs=X 인수는 기술적으로 그보다 클 필요가 없음. 그러나 bs=1M은 해가 되지 않고(64kB 읽기를 1MB가 될 때까지 버퍼링함) 파이프 크기가 증가할 경우를 대비하여 미래에도 사용 가능함. 일부 netcat 버전에는 입력 및 출력 블록 크기를 제어하는 옵션이 있어 dd bs=X 사용 필요성을 줄여주지만, 구조 복구 디스크에서는 이러한 옵션이 없는 netcat 바이너리가 보통 사용됨.

  • nbdkit과 nbdcopy를 사용하는 것이 훨씬 간단함.

  • 새 노트북을 설정해야 했을 때, USB-C 케이블을 사용하여 10Gb/s로 전송하는 것이 유용함. 다른 옵션으로는 WiFi밖에 없었음.

    • 컴퓨터를 연결하면 애드혹 네트워크가 형성되고 rsync를 사용하여 전송 가능. 링크가 포화된 것으로 보여 다른 프로토콜을 사용하는 것은 무의미함.

  • 최근에 WiFi를 통해 약 200GB의 파일을 복사해야 했음. 연결 실패 시 처음부터 다시 시작하지 않도록 rsync를 사용했지만, 적어도 6시간이 걸림. 더 나은 방법이 궁금함.

    • dd 방법으로 어떤 보장을 받는지? 결과 블록 레벨 장치의 md5를 비교해야 하는지?

  • 저자가 왜 네트워크를 통해 btrfs를 파이프하지 않았는지 이해할 수 없음. 먼저 btrfs 스냅샷을 만든 다음 btrfs send => nc => network => nc => btrfs receive를 통해 사용 중인 블록만 전송함.

  • 이전에 노트북을 전송할 때 양쪽에서 dd와 nc를 결합한 설치 프로그램을 실행했음. 기억나는 대로, 전송을 더 빠르게 하기 위해 gzip도 추가함.

    • 새 노트북에 이더넷 포트가 없어서 압축이 약간의 속도 향상을 제공했을 수 있어 저자의 방법보다 더 빨랐을 것임.

  • Clonezilla를 사용하면 실제 데이터 블록만 복사하고 파티션을 자동으로 조정할 수 있음. 항상 이 방법을 사용함.

    • 일반적으로 NVMe 디스크를 노트북에서 꺼내고 고속 도크에 넣음.

  • 수십 년 동안 실제로 OS를 "설치"하지 않았으며, 파일을 복사하고 필요에 따라 조정함. 보통 새 파일 시스템을 만들어 파일 시스템 유형/파라미터(예: 블록 크기), 암호화 등을 업데이트하는 기회로 사용하고 파일을 rsync로 전송함.

    • 그럼에도 불구하고, 계획을 세우는 사람이라면 NixOS와 같은 더 선언적인 접근 방식을 사용하는 것이 더 나을 수 있음. 여기서는 설정만 복사한 다음 모든 것을 자동으로 다시 설치할 수 있음.

  • FDT(Fast Data Transfer)에 대한 언급이 없음.

    • 불행히도 Java로 작성된 놀라운 소프트웨어(전송 성능 측면에서). 직관적이지 않은 CLI 옵션을 가지고 있지만, 본 적 있는 가장 빠른 전송임.
    • 너무 빨라서 속도를 인위적으로 제한하지 않으면 때때로 전체 로컬 네트워크를 점유함.
    • -limit <rate> 옵션으로 전송 속도를 지정된 속도로 제한할 수 있음. K(KiloBytes/s), M(MegaBytes/s), G(GigaBytes/s)를 접미사로 사용할 수 있음.
    • 목적지에서 파일 조각화를 일으키지만, 실제로는 아무에게도 중요하지 않음.
답변달기