매우 큰 폴더 구조 동기화


14

인트라넷의 폴더 구조는 약 800,000 개의 파일을 약 4,000 개의 폴더로 나눕니다. 이를 DMZ의 소규모 시스템 클러스터에 동기화해야합니다. 구조의 깊이는 매우 얕습니다 (깊이가 두 수준을 초과하지 않음).

대부분의 파일은 변경되지 않으며 매일 수천 개의 업데이트 파일과 1-21,000 개의 새 파일이 있습니다. 데이터는 소스 데이터가 제거 된 위치에서 유지되는 히스토리보고 데이터입니다 (즉, 소스 데이터가 아카이브되어 삭제하기에 충분히 오래된 최종 보고서입니다). 합리적인 시간 내에 발생할 수 있으므로 하루에 한 번만 동기화하면됩니다. 보고서는 밤새 생성되며 아침에 예약 된 작업으로 가장 먼저 동기화합니다.

정기적으로 변경되는 파일이 거의 없기 때문에 증분 복사의 이점을 크게 누릴 수 있습니다. Rsync를 시도했지만 "빌드 파일 목록"작업을 완료하는 데 8 ~ 12 시간이 걸릴 수 있습니다 . rsync가 할 수있는 것보다 빠르게 성장하고있는 것은 분명합니다 (12 시간 시간이 너무 깁니다).

우리는 구조를 동기화하기 위해 RepliWeb이라는 또 다른 도구를 사용했으며 약 45 분 안에 증분 전송을 수행 할 수 있습니다. 그러나 한계를 초과 한 것으로 보이며 파일이 없을 때 파일이 삭제 된 것으로 표시되기 시작했습니다 (일부 내부 메모리 구조가 소진되었을 수도 있지만 확실하지 않습니다).

이런 종류의 대규모 동기화 프로젝트에 다른 사람이 있습니까? 동기화를 위해 이와 같은 대규모 파일 구조를 처리하도록 설계된 것이 있습니까?


동시에 실행중인 여러 rsync 인스턴스에서 작업을 분할하려고 했습니까? 디렉토리 구조에 대한 좋은 그림은 없지만 디렉토리 이름이나 파일 이름으로 나눌 수 있습니다.
클러치

우리는 그것에 대해 생각했지만 그러한 평평한 구조로 인해 작업을 분할 할 좋은 구분선을 찾기가 어렵습니다. 폴더의 이름은 대부분 비슷한 이름으로되어 있기 때문에 복잡합니다 (대부분의 폴더는 동일한 초기 6 자 세트로 시작하는 이름 지정 규칙이 있습니다).
MightyE

좋은 해결책을 찾은 적이 있습니까, Dave? 65535 개의 하위 디렉토리가있는 디렉토리에 대해 lsyncd를 고려하고 있습니다. 각 디렉토리 에는 65 ^ 16 파일 이 있을 수 있습니다.
Mike Diehn 2018 년

1
@ MikeDiehn 나는 여기에 완전히 만족하는 도구를 찾지 못했습니다. 우리는 독점적 인 RepliWeb 도구를 사용하여 파일을 삭제로 보았던 버그를 수정했습니다. 내부 구조가 오버플로되었습니다. 나는 몇 년 전에 그 직장을 떠 났는데, 그들은 여전히 ​​그것을 사용하고 있다고 가정합니다. 귀하의 목적을 위해 디렉토리가 합리적으로 배포되면 Ryan의 솔루션과 같은 것을 사용할 수 있습니다. 최상위 레벨 삭제는 알지 못하지만 65535 하위 디렉토리에는 아마도 해당 디렉토리가 없을 것입니다.
MightyE

답변:


9

파일 시스템의 마지막 수정 타임 스탬프를 신뢰할 수 있다면 Rsync와 UNIX / Linux 'find'유틸리티를 결합하여 작업 속도를 높일 수 있습니다. 'find'는 지난 날에 마지막으로 수정 된 시간을 표시하는 모든 파일 목록을 조합 한 다음 단축 된 파일 / 디렉토리 목록 만 Rsync로 파이프 할 수 있습니다. 이것은 Rsync가 발신자의 모든 단일 파일의 메타 데이터를 원격 서버와 비교하는 것보다 훨씬 빠릅니다.

즉, 다음 명령은 지난 24 시간 동안 변경된 파일 및 디렉토리 목록에서 Rsync 만 실행합니다. (Rsync는 다른 파일 / 디렉토리를 확인하지 않아도됩니다.)

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

'find'명령에 익숙하지 않은 경우 특정 디렉토리 하위 트리를 통해 반복하여 지정한 기준에 맞는 파일 및 / 또는 디렉토리를 찾습니다. 예를 들어 다음 명령은

find . -name '\.svn' -type d -ctime -0 -print

현재 디렉토리 ( ".")에서 시작하여 모든 하위 디렉토리를 통해 재귀하여 다음을 찾습니다.

  • 모든 디렉토리 ( "-타입 d")
  • ".svn"( "-name '.svn'"),
  • 지난 24 시간 동안 메타 데이터가 수정되었습니다 ( "-ctime -0").

표준 출력에서 ​​해당 기준과 일치하는 항목의 전체 경로 이름 ( "-print")을 인쇄합니다. '-name', '-type'및 '-ctime'옵션을 "tests"라고하며, "-print"옵션을 "action"이라고합니다. 'find'매뉴얼 페이지에는 전체 테스트 및 조치 목록이 있습니다.

정말 영리하고 싶다면 '-ctime'대신 'find'명령의 '-cnewer'테스트를 사용하여이 프로세스를보다 내결함성과 유연성으로 만들 수 있습니다. '-cnewer'는 트리의 각 파일 / 디렉토리가 일부 참조 파일보다 최근에 메타 데이터가 수정되었는지 테스트합니다. 'touch'를 사용하여 각 실행의 시작 부분에서 'find ... 직전의 NEXT 실행 참조 파일을 작성하십시오. rsync ... '명령이 실행됩니다. 기본 구현은 다음과 같습니다.

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

이 스크립트는 마지막으로 실행 된 시간을 자동으로 알고 마지막 실행 이후 수정 된 파일 만 전송합니다. 이 방법은 더 복잡하지만 가동 중지 시간이나 기타 오류로 인해 24 시간 이상 작업을 놓친 상황으로부터 사용자를 보호합니다.


이것은 매우 영리한 솔루션입니다! 나는 당신 touch $next_ref_file이 마지막에 의미한다고 생각 합니까? 삭제 된 경로에 대처할 수있는 능력이 없어집니다 (이 정적 보관 보고서조차도 결국 아카이브되고 삭제 될 정도로 오래되었습니다). 그래도 쇼 스토퍼가 아닐 수도 있습니다.
MightyE

나는 find . -ctime 0이 디렉토리 구조 에서조차도 꽤 느리다는 것을 알았습니다 (아직도 시간을보고하기 위해 기다리고 있습니다). 그것은 실제로 우리 가이 작업을 완료 할 것으로 예상되는 가장 빠른 기준을 설정하는 꽤 낮은 수준의 작업 일 것 같습니다. 여기서 디스크 I / O가 제한 요인 인 경우가 있습니다.
MightyE

그 스크립틀릿에 관해서는 그렇습니다. 'find ...'를 실행하기 직전에 'next_ref_file'( 'curr_ref_file'아님)에서 'touch'를 실행하는 것을 의미했습니다 ... | rsync ... '명령. (내 대답을 고칠 수 있습니다.)
라이언 B. 린치에게

3
slow 'find'명령은 어떤 파일 시스템을 사용하고 있습니까? Ext3을 사용하는 경우 두 가지 FS 조정을 고려할 수 있습니다. 1) 'tune2fs -O dir_index <DEVICE_NODE>'를 실행하여 Ext3의 'dir_index'기능을 활성화하여 파일 수가 많은 디렉토리에 대한 액세스 속도를 높입니다. 2) 'mount -o remount, noatime, nodiratime'을 실행하여 액세스 시간 업데이트를 끄면 일반적으로 읽기 속도가 빨라집니다. 'dumpe2fs -h <DEVICE_NODE> | grep dir_index '는'dir_index '가 이미 활성화되어 있는지 (일부 배포판에서는 기본값 임),'mount | grep <DEVICE_NODE> '는 액세스 시간 업데이트에 대해 알려줍니다.
Ryan B. Lynch

안타깝게도 NTFS-찾기 명령에 Cygwin을 사용하는 Windows 2003 서버입니다. 데비안 클러스터 중 하나에서 비슷한 것을 경험할 수 있도록 ext3에 대한 튜닝 옵션 (우수한 조언)을 기억할 것입니다.
MightyE

7

unison을 시도해보십시오 . 변경 목록 (빌딩 파일 목록)을 각 서버에 로컬로 유지하여 델타를 계산하는 시간을 단축하고 나중에 와이어를 통해 전송되는 감소량을 단축 하여이 문제를 해결하도록 특별히 설계되었습니다.


Unison에게 시도해보고 있습니다. 현재 "변경 사항 찾기"단계에서 약 2 시간 동안 실행 중이며 현재 작업중인 파일을 기준으로 절반 정도 완료된 것으로 보입니다 (전송이 시작되기 전에 총 4 시간이 소요될 수 있음). rsync보다 낫지 만 여전히 원하는 작동 창을 벗어난 것처럼 보입니다.
MightyE

2
양쪽에서 처음으로 인덱스를 만들면 재 구축 시간은 각 파일을 해시해야하므로 rsync와 비슷합니다. 이 작업이 완료되면 unison은 디렉토리의 마지막 수정 시간을 사용하여 파일이 변경된시기를 식별하고 해당 파일에서 변경 사항 만 스캔하면됩니다.
Dave Cheney

슬프게도 카탈로그 작성이 완료되기 전에 세션을 강제 종료 한 지나치게 열성적인 운영 관리자의 희생자였습니다 (우리는 동시 로그온 수를 프로덕션 서버로 제한했습니다). 초기 카탈로그를 구축하는 과정에서 진전을 잃었으므로 다시 시작해야합니다. 어떻게되는지 알려 드리겠습니다.
MightyE

변경 사항을 스캔하기 위해 초기 카탈로그가 빌드 되려면 이제 약 2 시간이 걸립니다. RAM Unison이 이것을 얼마나 많이 사용하고 있는지 놀랐습니다. 파일 콜렉션의 경우 소스 서버는 635M을 사용하고 원격 클라이언트는 366M을 사용합니다. 클러스터에서 여러 시스템을 동기화하는 것은 특히 소스 서버의 경우 매우 큰 공간입니다.
MightyE

1
최근에 변경된 데이터를 쉽게 식별 할 수있는 방식으로 데이터를 구성 할 수 있습니까? 즉, 년 / 월 / 일 / ... 형식으로 저장합니까?
Dave Cheney


2

rsync에서 -z 스위치를 사용하는 경우 스위치없이 실행 해보십시오. 어떤 이유로 나는이 파일의 초기 열거 조차도이 속도를 보았습니다.


-z 플래그를 사용하거나 사용하지 않고 시도했습니다. "빌딩 파일 목록"실행 시간에는 영향을 미치지 않는 것 같습니다.
MightyE

2

압축되지 않은 rsync 명령에서 -z를 제거하면 "수신 파일 목록"이 훨씬 빨라지고 약 500GB를 전송해야했습니다. -z 스위치로 하루가 걸렸습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.