네트워크를 통해 한 서버에서 다른 서버로 논리 볼륨을 직접 옮기시겠습니까?


13

여러 개의 VM이있는 KVM 호스트 시스템이 있습니다. 각 VM은 호스트에서 논리 볼륨을 사용합니다. LV를 다른 호스트 시스템으로 복사해야합니다.

일반적으로 다음과 같은 것을 사용합니다.

dd if=/the/logical-volume of=/some/path/machine.dd

LV를 이미지 파일로 바꾸고 SCP를 사용하여 옮기십시오. 그런 다음 DD를 사용하여 파일을 새 호스트의 새 LV로 다시 복사하십시오.

이 방법의 문제점은 두 시스템에서 VM이 차지하는 디스크 공간의 두 배가 필요하다는 것입니다. 즉. 5GB LV는 LV에 5GB의 공간을 사용하고 dd 사본은 이미지에 5GB의 추가 공간을 사용합니다. 이것은 작은 LV에는 적합하지만 큰 VM에 500GB LV가 있다면 어떨까요? 그것은 500 기가 바이트는 이미지 파일을 dd는 보유하지 수 있도록 새로운 호스트 시스템은 1TB 하드 드라이브가 에 복사 500GB의 논리 볼륨을 가지고 호스트 OS의 여지가 다른 작은 손님을위한 공간을.

내가하고 싶은 일은 다음과 같습니다.

dd if=/dev/mygroup-mylv of=192.168.1.103/dev/newvgroup-newlv

즉, 네트워크를 통해 하나의 논리 볼륨에서 다른 논리 볼륨으로 직접 데이터를 복사하고 중간 이미지 파일을 건너 뜁니다.

이게 가능해?


답변:


24

물론 가능합니다.

dd if=/dev/mygroup-mylv | ssh 192.168.1.103 dd of=/dev/newvgroup-newlv

팔.

그래도 호의를 베풀고 기본 블록 크기보다 큰 것을 사용하십시오. bs = 4M을 추가하십시오 (4MB 단위의 읽기 / 쓰기). 주석에서 블록 크기에 대한 간단한 선택이 있음을 알 수 있습니다. 이것이 자신이 상당히 자주하는 일이라면 약간의 시간을 들여 다른 블록 크기로 여러 번 시도하고 가장 좋은 전송 속도를 얻는 방법을 직접 확인하십시오.

의견에서 질문 중 하나에 대답 :

pv 를 통해 전송을 파이프하여 전송 에 대한 통계를 얻을 수 있습니다 . 신호를 보내는 출력보다 훨씬 좋습니다 dd.

또한 netcat (또는 암호화 오버 헤드를 부과하지 않는 다른 것)을 사용하는 것이 더 효율적일 것이라고 말할 것입니다. 일반적으로 추가 속도가 약간의 편의성을 잃는다는 것을 알았습니다. 실제로 큰 데이터 세트를 이동하지 않는 한 대부분의 경우 모든 것이 이미 Just Work로 설정되어 있기 때문에 오버 헤드에도 불구하고 일반적으로 ssh를 사용합니다.


1
bs는 복사 속도에만 영향을 미치거나 데이터 저장 방법에 영향을 미칩니 까?
Nick

3
데이터 저장 방법에는 영향을 미치지 않지만 읽기 및 쓰기에 기본 블록 크기 (512 바이트)를 사용하는 것보다 훨씬 효율적입니다.
larsks

3
@Nick : Linux에서는 dd프로세스에 USR1신호를 전송하여 전송 된 금액과 함께 상태 표시 줄을 표시 할 수 있습니다. 당신의 프로세스 번호 오기 dd같은과 프로세스를 ps aux | grep dd다음 명령으로이 PID를 사용합니다 kill -USR1 $PID. 시작한 원래 터미널에 메시지가 표시됩니다 dd.
Sven

3
디스크를 유휴 상태로 만드는 시간 동안 대부분의 네트워크 소켓으로 네트워크 소켓으로 전송할 수있을 때까지 파이프에 대한 쓰기를 ssh로 막기 때문에 큰 bs를 사용하고 싶지 않을 것입니다. 기본 판독 헤드 크기는 128k이므로이를 고수하고 싶을 것입니다. 또는 디스크 판독기 크기를 늘리십시오.
psusi

1
@psusi : Zoredache가 질문 아래에 언급 한 링크는 반대를 보여 주었으며 16M 블록 크기로 가장 빠른 결과를 얻었지만 전송 방법으로 ssh 대신 netcat을 사용했습니다. 이는 암호화가 필요하지 않을 때 항상 더 나은 옵션입니다.
Sven

18

다음 pv은 더 큰 청크에 BS를 사용 하고 사용 하는 진행률을 보여주고 gzip네트워크 트래픽을 줄이는 데 사용 되는 최적화 된 버전 입니다.

인터넷 서버와 같이 느린 연결간에 데이터를 이동할 때 완벽합니다. 화면 또는 tmux 세션 내에서 명령을 실행하는 것이 좋습니다. 이렇게하면 명령을 실행하는 호스트와의 ssh 연결이 문제없이 끊어 질 수 있습니다.

$ dd if=/dev/volumegroupname/logicalvolume bs=4096 | pv | gzip | \
    ssh root@78.46.36.22 'gzip -d | dd of=/dev/volumegroupname/logicalvolume  bs=4096'

2
ssh -C대신에 사용할 수 있습니다 gzip. 성능에 영향이 있는지 확실하지 않지만 타이핑이 훨씬 적습니다.
Samuel Edwin Ward

1
또한 gzip 대신 pigz 또는 pxz -1을 사용하는 것이 좋습니다. 멀티 스레딩 은 최신 서버에서 실제로 도움 됩니다.
sCiphre

pv바이트 수로 문제가 발생할 수 있습니다 (제 경험상이 시스템의 다른 서버로 500 vps 이상 이동).이 문제 후에 lvm 볼륨이 일치하지 않습니다. 작업 진행 상황의 이점은 무효입니다. 진행 상황이 마음에 들면 ifto로 콘솔을 엽니 다.
abkrim

4

오래된 freind를 사용 하여이 작업을 수행하는 것은 어떻습니까? 넷캣.

논리 볼륨 유형이 손실 된 시스템에서

  • $ dd if=/dev/[directory]/[volume-name] | nc -l [any high number port]

그런 다음 수신 시스템에서. 유형

  • $ nc -w 10 [ip or name] [port] | dd of=/dev/[directory/[volume name]

번역, 시작 상자에이 파일을 추가하고이 포트를 수신 할 nc (netcat)로 파이프하십시오. 수신 시스템에서 netcat은 [port]에서 [ip 또는 name]으로 닫기 전에 데이터가 없으면 10 초 동안 기다린 다음 해당 데이터를 dd로 파이프하여 기록합니다.


2
Netcat은 이러한 옵션과 함께 UDP를 사용하지 않습니다.
사무엘 에드윈 워드

3

먼저 lv의 스냅 샷을 찍습니다.

lvcreate --snapshot --name my_shot --size <thesize> /dev/<name of vg>/<name of lv>

그런 다음 같은 크기의 새 호스트에서 새 lv를 작성해야합니다 (예 : lvcreate 사용). 그런 다음 데이터를 새 호스트에 직접 복사 할 수 있습니다. 다음은 복사 명령의 예입니다.

dd if=/dev/vg0/my_shot bs=4096 | pv | ssh root@some_host -C 'dd of=/dev/vg1/<created lv> bs=4096'

절차를 사용하여 proxmox pve 유지 관리 VM을 다른 호스트에 복사했습니다. 논리 볼륨에는 VM 자체에서 유지 관리 한 몇 가지 추가 LV가 포함되었습니다.


2

먼저 논리 볼륨이 마운트되지 않았는지 확인하십시오. "핫 카피"를 만들려면 먼저 스냅 샷을 생성하고 대신 이것을 사용하십시오. lvcreate --snapshot --name transfer_snap --size 1G

두 개의 1Gbit 연결 서버간에 많은 양의 데이터 (7TB)를 전송해야하므로 가능한 빠른 방법이 필요했습니다.

SSH를 사용해야합니까?

ssh를 사용하는 것은 암호화 때문이 아니라 (AES-NI를 지원하는 CPU가있는 경우 크게 아프지 않습니다) 네트워크 버퍼 때문에 문제가되지 않습니다. 그것들은 잘 확장되지 않습니다. 이 문제를 해결 하는 패치 된 Ssh 버전 이 있지만 사전 컴파일 된 패키지가 없으므로 매우 편리하지 않습니다.

압축 사용

원시 디스크 이미지를 전송할 때는 항상 압축을 사용하는 것이 좋습니다. 그러나 압축이 병목 현상이되는 것을 원하지 않습니다. gzip과 같은 대부분의 유닉스 압축 도구는 단일 스레드이므로 압축이 하나의 CPU를 포화 시키면 병목 현상이 발생합니다. 이런 이유로 압축을 위해 모든 CPU 코어를 사용하는 gzip 변형 인 pigz를 항상 사용합니다. 그리고 이것은 GBit 속도 이상으로 올라가고 싶을 때 필요합니다.

암호화 사용

앞에서 말했듯이 ssh는 느립니다. AES-NI CPU가있는 경우 병목 현상이 발생하지 않아야합니다. 따라서 ssh를 사용하는 대신 openssl을 직접 사용할 수 있습니다.

속도

구성 요소의 속도 영향에 대한 아이디어를 제공하기 위해 내 결과는 다음과 같습니다. 이것들은 메모리에 읽고 쓰는 두 프로덕션 시스템 사이의 전송 속도입니다. 실제 결과는 네트워크 속도, HDD 속도 및 소스 CPU 속도에 따라 다릅니다! 적어도 성능 저하가 없다는 것을 보여주기 위해이 작업을 수행하고 있습니다. Simple nc dd: 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 47.3576 s, 106 MB/s +pigz compression level 1 (speed gain depends on actual data): network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 38.8045 s, 130 MB/s +pigz compression level 5: network traffic: 2.43GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 44.4623 s, 113 MB/s +compression level 1 + openssl encryption: network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 43.1163 s, 117 MB/s 결론 : 압축을 사용하면 데이터 크기가 많이 줄어들 기 때문에 속도가 눈에 띄게 향상됩니다. 네트워크 속도가 느리면 더욱 중요합니다. 압축을 사용할 때는 CPU 사용량을 확인하십시오. 사용량이 최대가되면 사용하지 않고 시도 할 수 있습니다. imho는 압축에서 30-40 % CPU를 훔치기 때문에 압축을 AES-NI 시스템에 미치는 작은 영향으로 만 사용합니다.

화면 사용

나와 같은 많은 데이터를 전송하는 경우 ssh 클라이언트의 네트워크 연결 끊김으로 인해 데이터를 중단하지 않으려는 경우 양쪽 화면에서 시작하는 것이 좋습니다. 이것은 단지 참고 사항입니다. 여기서는 화면 자습서를 작성하지 않습니다.

복사 할 수 있습니다

소스 및 대상에 대한 일부 종속성을 설치하십시오. apt install pigz pv netcat-openbsd

그런 다음 대상과 소스와 동일한 크기로 볼륨을 만듭니다. 확실하지 않은 경우 소스에서 lvdisplay를 사용하여 크기를 가져오고 대상을 작성하십시오. lvcreate -n lvname vgname -L 50G

다음으로, 데이터를 수신 할 대상을 준비하십시오.

nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname

준비가되면 소스에서 전송을 시작하십시오.

pv -r -t -b -p -e /dev/vgname/lvname | pigz -1 | openssl aes-256-cbc -salt -pass pass:asdkjn2hb | nc <destip/host> 444 -q 1

참고 : 로컬로 데이터를 전송하거나 암호화에 신경 쓰지 않으면 Openssl 부분을 양쪽에서 제거하십시오. 관심이 있으시면 asdkjn2hb가 암호화 키이므로 변경해야합니다.


PROXMOX 서버에서이 작업을 수행하지 마십시오. apt install netcat-openbsd 서버에서 netcat-openbsd를 완전히 삭제 한 ProxMox를 설치하면 5 시간 이상의 가동 중지 시간과 작업이 발생했습니다 !!!
Zoltan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.