백만 개의 파일을 원격 서버와 효율적으로 동기화하는 옵션이 있습니까?


27

내가 일하는 회사에서 우리는 각각 "100 ~ 300 바이트의 작은 파일 인"재생 목록 "이라는 것을 가지고 있습니다. 그들 중 약 백만이 있습니다. 그들 중 약 10 만 시간마다 변경됩니다. 이 재생 목록은 1 시간마다 다른 대륙에있는 10 개의 다른 원격 서버에 업로드해야하며 2 분 이내에 빠르게 이상적이어야합니다. 마스터에서 삭제 된 파일도 모든 복제본에서 삭제되어야합니다. 현재 인프라에 Linux를 사용하고 있습니다.

내용을 비교하지 않고 전체 파일을 복사하기 위해 -W 옵션으로 rsync를 시도하는 것에 대해 생각하고있었습니다. 아직 시도하지는 않았지만 rsync에 대한 경험이 많은 사람들이 가능한 옵션인지 말해 줄 수 있습니까?

고려해야 할 다른 옵션은 무엇입니까?

업데이트 : 나는 lsyncd 옵션을 답으로 선택했지만 가장 인기가 있었기 때문에 만 사용했습니다. 제안 된 다른 대안도 자체 방식으로 유효합니다.


1
어떤 파일이 변경 또는 삭제되었는지를 나타내는 로그가 있습니까?
Oliver

3
재생 목록 만 mysql 레코드 인 경우. 그런 다음 데이터베이스 복제를 사용하고 mysql이 보내거나받는 데 필요한 것을 해결하도록 할 수 있습니다.
Matt

@oliver 우리는. 그러나 로그를 생성하는 코드가 정확해야한다는 의미의 로그를 신뢰해야하며 해당 로그를 처리하려면 사용자 정의 코드도 필요합니다. 오히려 커뮤니티에서 광범위하게 테스트 한 무언가를 처리하기 위해 집에서 작성한 코드를 피하고 싶습니다.
Zilvinas 2016 년

당신의 변경 하시겠습니까 에만 GET은 매 시간마다 적용? 아니면 인스턴트 복제도 허용됩니까?
faker

1
rsync가 백만 개의 파일을 처리하는 데 걸리는 시간을 과소 평가하지 마십시오. 그것을 시도하고 당신이 무엇을 볼 수 있습니다. 해당 로그가 있으면 사용하거나 제안 된 다른 솔루션을 사용해보십시오.
Oliver

답변:


39

인스턴트 업데이트도 허용 되므로 lsyncd를 사용할 수 있습니다 .
디렉토리를 감시 (inotify)하고 rsync슬레이브로 변경합니다.
시작할 때 full을 수행 rsync하므로 시간이 다소 걸리지 만 그 후에는 변경 사항 만 전송됩니다.
디렉토리의 재귀적인 감시가 가능합니다. 슬레이브 서버가 다운되면 동기화가 다시 시작될 때까지 재 시도됩니다.

이것이 모두 단일 디렉토리 (또는 정적 디렉토리 목록)에있는 경우 incron 을 사용할 수도 있습니다 .
단점은 폴더를 재귀 적으로 볼 수 없으므로 동기화 기능을 직접 구현해야한다는 것입니다.


다시 화려한 팁 :
Zilvinas

1
+1 이것은 본질적으로 캐시 일관성 문제이며, 변경 사항을 적용하는 모니터가 가장 쉬운 솔루션입니다. lsyncd그것을 구현합니다.
Chris S

1
귀하의 특정 서버 OS에 적용되는 내용을 조사 lsyncd하고 inotify깊이 생각합니다. 사용 가능한 inotify 시계 수에는 제한이 있습니다. 특정 Linux 버전에 따라 기본값이 약 1500 또는 8000이라고 생각합니다. 대부분의 커널을 사용하면 한계를 높일 수 있지만 백만 개의 파일을 모니터링하는 것이 실용적입니다. 또한 inotify 이벤트 큐가 오버플로하여 이벤트가 손실 될 수 있으므로 복구 할 수있는 방법이 필요합니다. 신중하게 조정 된 lsyncd구현과 매일을 조정 하면 rsync2012 년에 기반을 다룰 수 있습니다.
Old Pro

2
사실 그것은을 수행 iontify상의 디렉토리 가 아닌 개별 파일. 몇 개의 디렉토리를 볼 수 있습니까? 확인하십시오 /proc/sys/fs/inotify/max_user_watches(일반적으로 8192).
faker 2016 년

2
~ 50k 디렉토리를 사용하면 inotify는 확장 성이 떨어질 것입니다. 2009 년에 100k 디렉토리를 사용하여 유사한 접근 방식을 시도했을 때 모든 디렉토리를 구독하는 데 오랜 시간이 걸렸습니다. @OldPro는 우리에게 효과가 없었습니다.
neovatar

11

GlusterFS 와 같은 분산 파일 시스템 사용을 고려하십시오 . 복제 및 병렬 처리를 염두에두고 설계된 GlusterFS는 inotify 및을 포함하는 임시 솔루션보다 훨씬 더 부드럽게 최대 10 대의 서버로 확장 할 수 있습니다 rsync.

이 특정 사용 사례의 경우 10 개의 복제본으로 10 개의 서버 GlusterFS 볼륨 (즉, 서버 당 1 개의 복제본 / 브릭)을 구축 할 수 있으므로 각 복제본은 볼륨에있는 다른 모든 복제본의 정확한 미러가됩니다. GlusterFS는 파일 시스템 업데이트를 모든 복제본에 자동으로 전파합니다.

각 위치의 클라이언트는 로컬 서버에 접속하므로 파일에 대한 읽기 액세스가 빠릅니다. 중요한 질문은 쓰기 대기 시간을 상당히 낮게 유지할 수 있는지 여부입니다. 대답하는 유일한 방법은 시도해 보는 것입니다.


Glusterfs의 경우 +1
Tom O'Connor

8

나는 의심 rsync10 번 만 파일을 검색하고 원격 시스템과 비교하는 것은 오래 걸릴 것이기 때문에, 일반적인 방법으로이 작동한다. inotify수정 된 파일 목록을 유지하고 원격 서버로 푸시하는 것과 같은 시스템을 구현하려고 합니다 (이 변경 사항이 다른 방식으로 기록되지 않으면). 그런 다음이 목록을 사용하여 전송에 필요한 파일을 신속하게 식별 할 수 있습니다. rsync (또는 10 개 이상의 병렬 인스턴스)로도 가능합니다.

편집 : 약간의 작업 으로이 inotify / log watch 접근법을 사용하여 수정이 발생하는 즉시 파일을 복사 할 수도 있습니다.


5

다른 대안들 :

  • 기본 서버에서 파일을 삭제하거나 추가 할 때마다 작업을 RabbitMQ 또는 Gearman 에 삽입하여 모든 원격 서버에서 동일한 파일을 비동기식으로 이동 및 삭제 (또는 추가)하십시오.
  • 파일을 데이터베이스에 저장하고 복제를 사용하여 원격 서버를 동기화하십시오.
  • ZFS가 있으면 ZFS 복제를 사용할 수 있습니다 .
  • 일부 SAN에는 파일 복제가 있습니다. 이것이 인터넷을 통해 사용될 수 있는지 전혀 모른다.

4

이것은 MongoDB 와 아마도 GridFS에 이상적인 스토리 북 사용 사례 인 것 같습니다 . 파일이 상대적으로 작기 때문에 GridFS API를 사용하는 것이 편리 할 수도 있지만 MongoDB만으로도 충분합니다.

MongoDB는 nosql 데이터베이스이고 GridFS는 그 위에 파일 스토리지 빌드입니다. MongoDB에는 복제샤딩 을위한 많은 옵션이 내장되어 있으므로 사용 사례에 맞게 확장해야합니다.

귀하의 경우에는 아마도 기본 데이터 센터에 위치한 마스터 (같은 위치에서 페일 오버하려는 경우 두 번째 마스터)와 전세계에 분산 된 10 개의 "슬레이브"로 구성된 복제본 세트로 시작할 것입니다. 그런 다음로드 테스트를 수행하여 쓰기 성능이 충분한 지 확인하고 노드에 대한 복제 시간을 확인하십시오. 더 많은 성능이 필요한 경우 설정을 샤드로 전환 할 수 있습니다 (대부분 쓰기로드를 더 많은 서버에 분배하기 위해). MongoDB는 "저렴한"하드웨어를 사용하여 대규모 설정을 확장하도록 설계되었으므로 저렴한 서버를 배치하여 성능을 향상시킬 수 있습니다.


0

S3 백엔드를 사용하고 필요한 모든 서버에 마운트하면 모든 사람이 즉시 동기화됩니다.


저장소가 동기화되는 동안 응용 프로그램에 알려야하므로 다시 사각형으로 돌아가거나 누군가이 재생 목록에 액세스 할 때마다 응용 프로그램에서 저장소를 폴링해야합니다. 두 경우 모두 성능이 끔찍합니다.
Chris S

응용 프로그램은 누군가가 재생 목록에 액세스 할 때마다 저장 공간을 폴링 할 필요가 없습니다. 시간 내에 충분한 시간 만 있으면 응용 프로그램이 오래된 데이터없이 실행될 수 있습니다. 또한 S3을 백엔드로 사용하는 경우 애플리케이션이 파일을 먼저 폴링해야하는 이유는 무엇입니까? 그들은 항상 최신 상태입니다
Mister IT 전문가

0

아직 언급되지 않은 옵션은 모든 파일을 하나의 압축 파일로 아카이브하는 것입니다. 이렇게하면 전체 크기가 크게 줄어들고 수백만 개의 개별 파일을 처리 할 때 발생하는 모든 오버 헤드가 제거됩니다. 하나의 큰 업데이트로 전체 파일 세트를 교체하면 제거 된 파일이 복제본에서 제거된다는 것을 확신 할 수 있습니다.

단점은 물론 많은 파일을 불필요하게 전송한다는 것입니다. 압축 덕분에 크기가 줄어들면 균형이 맞지 않을 수도 있습니다. 또한 많은 파일을 압축하는 데 시간이 얼마나 걸릴지 모르겠습니다.

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