내가 일하는 회사에서 우리는 각각 “100 ~ 300 바이트의 작은 파일 인”재생 목록 “이라는 것을 가지고 있습니다. 그들 중 약 백만이 있습니다. 그들 중 약 10 만 시간마다 변경됩니다. 이 재생 목록은 1 시간마다 다른 대륙에있는 10 개의 다른 원격 서버에 업로드해야하며 2 분 이내에 빠르게 이상적이어야합니다. 마스터에서 삭제 된 파일도 모든 복제본에서 삭제되어야합니다. 현재 인프라에 Linux를 사용하고 있습니다.
내용을 비교하지 않고 전체 파일을 복사하기 위해 -W 옵션으로 rsync를 시도하는 것에 대해 생각하고있었습니다. 아직 시도하지는 않았지만 rsync에 대한 경험이 많은 사람들이 가능한 옵션인지 말해 줄 수 있습니까?
고려해야 할 다른 옵션은 무엇입니까?
업데이트 : 나는 lsyncd 옵션을 답으로 선택했지만 가장 인기가 있었기 때문에 만 사용했습니다. 제안 된 다른 대안도 자체 방식으로 유효합니다.
답변
인스턴트 업데이트도 허용 되므로 lsyncd를 사용할 수 있습니다 .
디렉토리를 감시 (inotify)하고 rsync슬레이브로 변경합니다.
시작할 때 full을 수행 rsync하므로 시간이 다소 걸리지 만 그 후에는 변경 사항 만 전송됩니다.
디렉토리의 재귀적인 감시가 가능합니다. 슬레이브 서버가 다운되면 동기화가 다시 시작될 때까지 재 시도됩니다.
이것이 모두 단일 디렉토리 (또는 정적 디렉토리 목록)에있는 경우 incron 을 사용할 수도 있습니다 .
단점은 폴더를 재귀 적으로 볼 수 없으므로 동기화 기능을 직접 구현해야한다는 것입니다.
답변
GlusterFS 와 같은 분산 파일 시스템 사용을 고려하십시오 . 복제 및 병렬 처리를 염두에두고 설계된 GlusterFS는 inotify 및을 포함하는 임시 솔루션보다 훨씬 더 부드럽게 최대 10 대의 서버로 확장 할 수 있습니다 rsync.
이 특정 사용 사례의 경우 10 개의 복제본으로 10 개의 서버 GlusterFS 볼륨 (즉, 서버 당 1 개의 복제본 / 브릭)을 구축 할 수 있으므로 각 복제본은 볼륨에있는 다른 모든 복제본의 정확한 미러가됩니다. GlusterFS는 파일 시스템 업데이트를 모든 복제본에 자동으로 전파합니다.
각 위치의 클라이언트는 로컬 서버에 접속하므로 파일에 대한 읽기 액세스가 빠릅니다. 중요한 질문은 쓰기 대기 시간을 상당히 낮게 유지할 수 있는지 여부입니다. 대답하는 유일한 방법은 시도해 보는 것입니다.
답변
나는 의심 rsync10 번 만 파일을 검색하고 원격 시스템과 비교하는 것은 오래 걸릴 것이기 때문에, 일반적인 방법으로이 작동한다. inotify수정 된 파일 목록을 유지하고 원격 서버로 푸시하는 것과 같은 시스템을 구현하려고 합니다 (이 변경 사항이 다른 방식으로 기록되지 않으면). 그런 다음이 목록을 사용하여 전송에 필요한 파일을 신속하게 식별 할 수 있습니다. rsync (또는 10 개 이상의 병렬 인스턴스)로도 가능합니다.
편집 : 약간의 작업 으로이 inotify / log watch 접근법을 사용하여 수정이 발생하는 즉시 파일을 복사 할 수도 있습니다.
답변
다른 대안들 :
- 기본 서버에서 파일을 삭제하거나 추가 할 때마다 작업을 RabbitMQ 또는 Gearman 에 삽입하여 모든 원격 서버에서 동일한 파일을 비동기식으로 이동 및 삭제 (또는 추가)하십시오.
- 파일을 데이터베이스에 저장하고 복제를 사용하여 원격 서버를 동기화하십시오.
- ZFS가 있으면 ZFS 복제를 사용할 수 있습니다 .
- 일부 SAN에는 파일 복제가 있습니다. 이것이 인터넷을 통해 사용될 수 있는지 전혀 모른다.
답변
이것은 MongoDB 와 아마도 GridFS에 이상적인 스토리 북 사용 사례 인 것 같습니다 . 파일이 상대적으로 작기 때문에 GridFS API를 사용하는 것이 편리 할 수도 있지만 MongoDB만으로도 충분합니다.
MongoDB는 nosql 데이터베이스이고 GridFS는 그 위에 파일 스토리지 빌드입니다. MongoDB에는 복제 및 샤딩 을위한 많은 옵션이 내장되어 있으므로 사용 사례에 맞게 확장해야합니다.
귀하의 경우에는 아마도 기본 데이터 센터에 위치한 마스터 (같은 위치에서 페일 오버하려는 경우 두 번째 마스터)와 전세계에 분산 된 10 개의 “슬레이브”로 구성된 복제본 세트로 시작할 것입니다. 그런 다음로드 테스트를 수행하여 쓰기 성능이 충분한 지 확인하고 노드에 대한 복제 시간을 확인하십시오. 더 많은 성능이 필요한 경우 설정을 샤드로 전환 할 수 있습니다 (대부분 쓰기로드를 더 많은 서버에 분배하기 위해). MongoDB는 “저렴한”하드웨어를 사용하여 대규모 설정을 확장하도록 설계되었으므로 저렴한 서버를 배치하여 성능을 향상시킬 수 있습니다.
답변
S3 백엔드를 사용하고 필요한 모든 서버에 마운트하면 모든 사람이 즉시 동기화됩니다.
답변
아직 언급되지 않은 옵션은 모든 파일을 하나의 압축 파일로 아카이브하는 것입니다. 이렇게하면 전체 크기가 크게 줄어들고 수백만 개의 개별 파일을 처리 할 때 발생하는 모든 오버 헤드가 제거됩니다. 하나의 큰 업데이트로 전체 파일 세트를 교체하면 제거 된 파일이 복제본에서 제거된다는 것을 확신 할 수 있습니다.
단점은 물론 많은 파일을 불필요하게 전송한다는 것입니다. 압축 덕분에 크기가 줄어들면 균형이 맞지 않을 수도 있습니다. 또한 많은 파일을 압축하는 데 시간이 얼마나 걸릴지 모르겠습니다.
