두 개의 원격 Linux 서버간에 큰 파일 트리의 양방향 실시간 동기화

큰 파일 트리는 약 200k 파일을 의미하며 항상 증가합니다. 주어진 시간에 비교적 적은 수의 파일이 변경되고 있습니다.

양방향으로 나는 서버 중 하나에서 변경이 발생할 수 있으며 다른 서버로 푸시해야하므로 rsync가 적절하지 않은 것으로 보입니다.

멀리 있다는 것은 서버가 데이터 센터에 있지만 지리적으로 서로 떨어져 있다는 것을 의미합니다. 현재 2 대의 서버 만 있지만 시간이지나면서 확장 될 수 있습니다.

실시간으로 동기화 사이에 약간의 대기 시간이있을 수는 있지만 1-2 분마다 크론을 실행하는 것은 옳지 않은 것처럼 보입니다. 분의 파일은 물론 소수의 파일도 아주 적은 시간에 변경 될 수 있기 때문입니다.

편집 : 이것은 VPS에서 실행되므로 내가 할 수있는 커널 수준의 종류에 제한이있을 수 있습니다. 또한 VPS는 리소스가 풍부하지 않으므로 Gluster와 같은 많은 램이 필요한 솔루션을 피하고 싶습니다.

이 작업을 수행하는 가장 좋은 방법은 무엇입니까? 이것은 일반적인 요구 인 것처럼 보이지만, 일반적으로 받아 들여지는 접근법을 아직 찾지 못했지만 놀라운 일이었습니다. (나는 대중의 안전을 찾고 있습니다. :)

나는 건너 한 lsyncd 파일 시스템 변경 수준에서 동기화를 트리거 할 수 있습니다. 그것은 흔하지는 않지만 영리한 것처럼 보이며 다양한 lsyncd 접근 방식에 약간 혼란 스럽습니다. rsync와 함께 lsyncd를 사용하고 있지만 rsync에 메모리 개념이 없기 때문에 양방향에 취약 할 수 있습니다 (예 : A에서 삭제 된 파일을 B에서 삭제 해야하는지 또는 B에서 새 파일인지 여부를 알기 위해) A)로 복사해야합니다. 립싱크는 단지 lsyncd + rsync를 구현, 잘 될 것 같습니다?

그런 다음 csync2와 함께 lsyncd를 사용 하고 있습니다 : https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ...이 접근법에 기대어 있습니다. csync2는 약간 기발하지만, 테스트를 성공적으로 수행했습니다. 나는이 방법에 대해 많은 커뮤니티 확인을 할 수 없었 을까 걱정하고있다.

여기에있는 사람들은 Unison을 많이 좋아하는 것처럼 보이지만 더 이상 활발히 개발 중이 아니며 lsyncd와 같은 자동 트리거가 있는지 확실하지 않습니다.

나는 Gluster가 언급 된 것을 보았지만 , 내가 필요로하는 것에 대해 지나치게 과잉 일까?

업데이트 : 참고-나는 내가 언급 한 원래 솔루션 인 lsyncd + csync2로 끝났습니다. 꽤 잘 작동하는 것 같습니다. 서버를 매우 느슨하게 연결하는 아키텍처 방식이 마음에 들기 때문에 각 서버는 링크 품질에 관계없이 자체적으로 무기한으로 작동 할 수 있습니다.

DRBD 의 듀얼 차 A를 모드 프록시는 옵션입니다.

동기화하는 대신 NFS를 통해 동일한 파일 시스템을 공유하지 않겠습니까?

분산 파일 시스템을 구현하는 것이 도구 및 스크립트와 함께 해킹하는 것보다, 특히 서버 클러스터가 커지는 경우보다 낫습니다. 다운 된 노드를 더 잘 처리 할 수도 있습니다.

나는 Gluster (또는 AFS)가 전혀 과도하다고 생각하지 않습니다.

귀하의 경우 이중 기본 모드와 gfs 또는 ocfs에서 DRBD의 조합을 권장합니다.

이중 기본에서 DRBD의 단점은 동기 모드에서 실행된다는 것입니다. 그러나 여기서 쓰기 속도는 중요하지 않은 것 같습니다.

DRBD의 대안은 많은 (2+) iSCSI 대상을 사용하는 Soft-Raid1 일 수 있지만 두 개의 노드가있는 DRBD를 선호합니다.

위에서 설명한 것처럼 각각의 장점과 단점이있는 많은 솔루션을 사용할 수 있습니다.

전체 트리를 버전 제어 ( 예 : Subversion )에 배치하고 cron 작업의 두 서버에서 주기적으로 체크인 / 업데이트하는 것을 고려할 것이라고 생각 합니다.

똑같은 것에 대해 약간의 탐구를 끝내고 난 글 러스터로 갈거야. 그러나 성능 테스트를 수행하지 않았습니다.