배경

배경

배경

가상 컴퓨터를 호스팅하는 서버 한 대와 해당 가상 컴퓨터의 백업 대상으로 사용되는 이전 NAS Synology DS1512+ 한 대가 있습니다. 서버는 ZFS를 사용하여 스냅샷을 생성하고 스냅샷 파일을 NAS로 전송합니다. NAS는 압축이 활성화된 BTRFS를 사용하고 스냅샷도 지원합니다. 궁극적인 목표는 서버가 실제로 RSYNC를 사용하여 DELTA만 전송하여 NAS가 수신하는 변경된 데이터의 양을 최소화하고 이에 대한 스냅샷도 효율적으로 사용하는 것입니다.

문제

하지만 DELTA와 함께 RSYNC를 사용하면 데이터를 전송하는 데 시간이 걸리기 때문에 내 경우에는 작동하지 않습니다.시간이 너무 많아. RSYNC를 와 함께 사용하면 --inplace --whole-file데이터를 전송하는 데 최대 2시간이 걸립니다. DELTA를 사용하기 위해 제거할 때 --whole-file동일한 백업 프로세스가 훨씬 더 오래 걸리며 이미 12시간 이상 실행한 후 프로세스를 종료하는 경우가 많습니다. 역사적인 이유로 인해 다양한 백업을 훨씬 더 작은 기간에 맞춰야 합니다.

서버가 훨씬 더 강력하고 대부분의 시간 동안 유휴 상태이기 때문에 이해가 되는 유일한 병목 현상은 NAS입니다. NAS OTOH는 백업 중에 CPU 및 I/O에 대한 부하가 상당히 높습니다. 하지만 숫자도 전혀 나쁘지는 않지만 --whole-file. 이를 통해 NAS는 ~100MiB/s 이상을 쓰는 반면, DELTA를 사용하면 ~50~100MiB/s에 걸쳐 대부분의 경우 더 느리게 읽습니다. 나는 DELTA 때문에 쓰지 말아야 할 데이터의 양이 느린 NAS의 사실보다 쉽게 ​​성능을 발휘할 것이라고 생각했지만 그렇지 않은 것 같습니다. 그리고 VM에서 변경된 데이터의 양은 대부분 그리 높지 않습니다.

관찰

NAS를 사용하면서 깨달은 점은 RSYNC가 어느 시점에서는 두 개의 파일을 동시에 처리하는 것 같다는 점이었습니다. 이는 미리 읽기 또는 유사해 보입니다.

root@amds1512-01:~# lsof | grep [d]asi_
rsync   6883   root  cwd    DIR   0,33        290   259 /volume1/[...]
rsync   6883   root    0r   REG   0,33 2142633984   580 /volume1/[...]/[...]-s024.vmdk
rsync   6884   root  cwd    DIR   0,33        290   259 /volume1/[...]
rsync   6884   root    1r   REG   0,33 2143748096   579 /volume1/[...]/[...]-s023.vmdk
rsync   6884   root    3w   REG   0,33 2143748096   579 /volume1/[...]/[...]-s023.vmdk

HTOP는 RSYNC의 두 인스턴스가 모두 읽는다는 것을 명확하게 보여줍니다. 다른 RSYNC 프로세스는 무시하세요. 이들은 서로 관련이 없으며 하나의 백업이 독점적으로 실행되는 경우에도 문제가 계속 지속됩니다.

스크린샷 HTOP

질문

그렇다면 백업 대상에서 서로 다른 파일을 사용하여 두 RSYNC를 실행하는 목적은 무엇입니까? RSYNC에게 하나의 파일만 차례로 처리하도록 지시할 수 있는 방법이 있습니까?

그러면 동시 로드가 줄어들어 전체 처리 시간이 늘어날 수 있습니다. 매뉴얼 페이지에서 미리 읽기 또는 유사 항목을 찾을 수 없습니다. 차이가 있는 경우 사용되는 옵션은 다음과 같습니다.

--owner \
--numeric-ids \
--compress-level=0 \
--group \
--perms \
--rsh=rsh \
--devices \
--hard-links \
--inplace \
--links \
--recursive \
--times \
--delete \
--delete-during \
--delete-excluded \
--rsync-path=[...] \
--specials

감사해요!

답변1

보세요Rsync 작동 방식. 구체적으로 파이프라인으로 동작하는 생성자 프로세스와 송신자 프로세스가 있습니다. 보낸 사람은 원격으로 보낼 파일을 읽습니다. 생성기는 보낼 파일 목록을 생성하고 "기본 파일에 대한 블록 체크섬이 생성되어 파일의 인덱스 번호 바로 다음에 보낸 사람에게 전송됩니다."

--inplace여러 개의 대용량 파일을 보내는 데 사용하는 경우 파일 시스템 스래싱을 ​​일으킬 가능성이 있는 것처럼 들립니다.커널이 캐시에 두 개의 연속 파일을 보관할 수 있는 충분한 RAM이 없습니다..

테스트로 개별 파일을 전송해 rsync --inpace보고 성능이 훨씬 더 나은지 확인할 수 있습니다. (예: for i in *.vmdk; do rsync [...]; done.) 두 개의 별도 리더가 실제로 성능 문제를 일으키는지 확인하는 데 도움이 됩니다.

독자가 여러 명인 경우~이다성능 문제가 발생하는 경우 가능한 경로 중 하나는 호스트 커널에 더 많은 RAM을 사용할 수 있도록 하거나 개별 vmdk 파일을 더 작게 만들어 커널의 읽기 캐시 기능을 향상시키는 것입니다.

불행히도 각 파일에 대해 한 번씩 rsync를 호출하는 자체 스크립트를 작성하는 것 외에는 rsync에서 생성기/발신자 파이프라인 동작을 변경하는 확실한 방법이 없습니다. 이에 대해 물어보고 싶을 수도 있습니다.rsync 메일링 리스트.

관련 정보