ESXi에서 rsync와 진정한 차동 동기화를 달성 한 사람이 있습니까?


11

서비스 콘솔을 사용하여 ESXi에서 작업을 수행한다는 사실에 대해 나중에 저를 평가하십시오.

ESXi 4.1U1에서 사용할 수있는 작동하는 rsync 바이너리 (v3.0.4)가 있습니다. 하나의 로컬 데이터 저장소에서 다른 로컬 데이터 저장소로 VM 또는 백업을 복사 할 때 cp를 통해 rsync를 사용하는 경향이 있습니다. rsync를 사용하여 하나의 ESXi 상자에서 다른 ESXi 상자로 데이터를 복사했지만 작은 파일에만 사용되었습니다.

이제 기본 ESXi 시스템과 보조 시스템간에 ghettoVCB 를 통해 수행 된 백업의 진정한 차등 동기화를 수행하려고합니다 . 그러나 로컬에서 (같은 ESXi 시스템의 다른 데이터 저장소에 대한 하나의 데이터 저장소)를 수행하더라도 rsync는 파일을 전체적으로 복사하는 것처럼 보입니다. 나는 크기가 두 VMDK의 완전히 80기가바이트있어, 그리고 rsync를 아직 어디서나 사이에 1, 2 시간이 소요되지만 VMDK 년대는 성장하지 않는 것을 많은 일.

아래는 내가 실행중인 rsync 명령입니다. 궁극적으로 이러한 파일은 원격 시스템의 LUN에서 작성된 데이터 저장소로 복사되므로 로컬로 복사하고 있습니다. 원격 시스템의 rsync 데몬이 서비스하는 rsync가 아닙니다.

rsync -avPSI VMBACKUP_2011-06-10_02-27-56/* VMBACKUP_2011-06-01_06-37-11/ --stats --itemize-changes --existing --modify-window=2 --no-whole-file
sending incremental file list
>f..t...... VM-flat.vmdk
 42949672960 100%   15.06MB/s    0:45:20 (xfer#1, to-check=5/6)
>f..t...... VM.vmdk
         556 100%    4.24kB/s    0:00:00 (xfer#2, to-check=4/6)
>f..t...... VM.vmx
        3327 100%   25.19kB/s    0:00:00 (xfer#3, to-check=3/6)
>f..t...... VM_1-flat.vmdk
 42949672960 100%   12.19MB/s    0:56:01 (xfer#4, to-check=2/6)
>f..t...... VM_1.vmdk
         558 100%    2.51kB/s    0:00:00 (xfer#5, to-check=1/6)
>f..t...... STATUS.ok
          30 100%    0.02kB/s    0:00:01 (xfer#6, to-check=0/6)

Number of files: 6
Number of files transferred: 6
Total file size: 85899350391 bytes
Total transferred file size: 85899350391 bytes
Literal data: 2429682778 bytes
Matched data: 83469667613 bytes
File list size: 129
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2432530094
Total bytes received: 5243054

sent 2432530094 bytes  received 5243054 bytes  295648.92 bytes/sec
total size is 85899350391  speedup is 35.24

ESXi 자체가 VMDK를 너무 많이 변경하여 rsync에 관한 한 전체 파일을 다시 전송해야합니까?

실제로 ESXi와 실제 diff 동기화를 달성 한 사람이 있습니까?


rsynce는 기본적으로 증분입니다. 믿기 ​​힘들지만 사실입니다. ESXi에서 작동하는 rsynce의 다운로드 위치를 궁금합니다. ESXi 4.1

답변:


6

2GB의 증분 변경 사항 만 전송 한 것 같습니다. rsync는 여전히 하나의 전체 파일을 읽고 체크섬해야 80GB의 데이터를 읽어야합니다. rsync 중에 서버 통계를 확인하십시오. 작업 중에 CPU 또는 IO가 바인딩되어 있습니까? 디스크에서 80GB 파일을 얼마나 빨리 읽을 수 있습니까? 그것은 당신의 절대 최소 전송 시간에 가깝습니다.

또한 rsync는 파일을 복사하는 동안 파일을 복사 한 다음 최종 파일을 원자 작업으로 이동시킵니다. 대상 디렉토리에서 전송하는 동안 임의의 접미사가있는 비슷한 파일 이름을보고이를 확인할 수 있습니다. 즉, 160GB의 데이터 (각 소스 및 대상마다 80GB)를 읽고 대상 측에서 80GB를 써야합니다. --inplace 옵션을 보셨습니까? 여기에 도움이 될 수 있습니다.

간단히 말해 2GB의 변경 사항 만있을 수 있지만 rsync는 많은 작업을 수행합니다. 동일한 디스크에서 읽고 쓰면 많은 경합과 속도 저하가 발생할 수 있으므로 IO에 바인딩되어있을 수 있습니다.


귀하의 답변에 감사드립니다. 전송 된 바이트 수가 현저히 낮아졌지만 30-45 분 이상의 대기 시간을보고있었습니다. 파일 전체를 다시 보냈을 수도 있습니다. 여기에 IO 병목이있을 수 있지만 ESXi 내에 있으며 하드웨어가 많지 않다고 생각합니다. LUN으로 옮기고 거기서 테스트하겠습니다. 정말 고마워
JuliusPIV

4

이 스레드는 매우 오래되었지만 누군가에게 도움이 될 수 있습니다.

ESX가 새로운 블록을 쓸 때마다 파일 시스템을 잠그기 때문에 옵션을 사용하면 성능이 그다지 좋지 않습니다. 더 나은 결과를 얻을 수 있지만 동기화를 취소하면 파일이 일관성이 없습니다. 더. 일관성에 대해 열린 파일의 rsync는 일관성이 없어서 rsync 전에 스냅 샷을 더 잘 사용할 수 있습니다.

안부 마크


2

그것의 모양으로, 당신은로 로컬에서 로컬로 복사를하고 rsync있습니다. 이 경우 기본 동작은 rsync델타 전송 알고리즘을 끄고 "전체 파일"전송을 수행하는 것입니다. 이 기본 동작의 이론적 근거는 델타 알고리즘이 단순히 전체 파일 복사를 수행하는 것보다 훨씬 많은 CPU 크 런칭을 포함하기 때문에 델타 -xfer 알고리즘을 사용하는 로컬-로컬 전송이 일반적으로 전체 파일을 복사하는 것보다 느리다는 것입니다.

로컬-로컬 사본이 delta-xfer 알고리즘을 사용하면 이점이 있다고 생각 rsync되면 --no-W(또는 --no-whole-file) 옵션 을 지정하여이를 강제 로 사용할 수 있습니다.


응답 Steven에 감사드립니다! 맞습니다. 순전히 테스트 목적으로 로컬 복사본을 수행하고 있습니다 (일명 실제로 차동 동기화를 수행하는지 확인). 궁극적으로 파일은 원격 시스템에 상주하는 노출 된 LUN 인 로컬 데이터 저장소로 복사됩니다. 실제로는 rsync-to-rsync 데몬 유형의 동기화가 아닙니다. 그 가치 --no-whole-file에 대해 rsync 명령의 일부로 옵션을 사용하고 있습니다. 화면을 넘어서 볼 수 있습니다.
JuliusPIV

@ 줄리어스 : 으악, 나는 그 수평 스크롤 막대를 놓쳤다! 오, 시간 낭비해서 죄송합니다.
Steven 월요일
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.