~7백만 개의 파일(주로 이미지)이 포함된 디렉터리를 로컬 디스크에서 네트워크 클라이언트로 내보내는 서버가 있습니다.NFS.
HA를 위해 두 번째 항목을 추가하고 둘 사이의 델타를 가능한 한 적게 유지하면서 첫 번째 항목과 동기화를 유지해야 합니다.
연구에 따르면 다음을 사용하는 것이 좋습니다.lsyncd또는 기타inotify이에 대한 기반 솔루션이지만 생성하는 파일의 수를 고려하면inotify시계는 영원합니다. 같은 것재동기화.
다른 가능한 해결책은 다음과 같습니다.drdb또는 클러스터파일 시스템~와 같은세프또는글러스터, 그러나 나는 이에 대한 경험이 없으며 어느 것이 더 적절하고 많은 파일에 잘 대처하면서도 여전히 괜찮은 성능을 제공하는지 모릅니다.
활동은 대부분 읽기로 이루어지며 쓰기는 거의 발생하지 않습니다.
답변1
나는 drbd와 같이 데이터에 구애받지 않는 복제를 제안하고 싶습니다. 많은 수의 파일로 인해 "블록 스토리지"보다 높은 수준에서 실행되는 모든 항목이 트리를 탐색하는 데 과도한 시간을 소비하게 됩니다. 이는 rsync를 사용하거나 inotify 시계를 생성하는 것을 발견한 것처럼 보입니다.
이를 뒷받침하는 내 개인적인 이야기의 짧은 버전: 저는 Ceph를 사용해 본 적이 없지만 Gluster와의 유사성으로 볼 때 이것이 Ceph의 주요 시장 목표가 아니라고 확신합니다. 그러나 나는 지난 몇 년 동안 Gluster를 사용하여 이러한 종류의 솔루션을 구현하려고 노력해 왔습니다. 여러 번의 주요 버전 업데이트를 통해 대부분의 시간 동안 작동했지만 문제는 끝이 없었습니다. 목표가 성능보다 중복성이라면 Gluster는 좋은 솔루션이 아닐 수 있습니다. 특히 사용 패턴에 stat() 호출이 많으면 Gluster는 복제를 제대로 수행하지 못합니다. 이는 복제된 볼륨에 대한 stat 호출이 모든 복제된 노드(실제로는 "브릭"이지만 호스트당 하나의 브릭만 갖게 될 것임)로 이동하기 때문입니다. 예를 들어 양방향 복제본이 있는 경우 클라이언트의 각 stat()는 현재 데이터를 사용하고 있는지 확인하기 위해 두 브릭의 응답을 기다립니다. 그런 다음 중복성을 위해 기본 Gluster 파일 시스템을 사용하는 경우 FUSE 오버헤드와 캐싱이 부족합니다(중복성을 위한 프로토콜 및 자동 마운트로 NFS를 사용하여 Gluster를 백엔드로 사용하는 대신 여전히 stat() 이유로 인해 짜증이 납니다). . Gluster는 여러 서버에 데이터를 분산시킬 수 있는 대용량 파일을 처리하는 데 매우 효과적입니다. 데이터 스트라이핑 및 배포는 실제로 잘 작동합니다. 그리고 최신 RAID10 유형 복제는 기존의 직접 복제 볼륨보다 성능이 더 좋습니다. 하지만 제가 추측하는 바에 따르면 귀하의 사용 모델은 반대되는 것이 좋습니다.
머신 간에 마스터 선택을 수행하거나 분산 잠금을 구현하는 방법을 찾아야 할 수도 있다는 점을 명심하십시오. 공유 블록 장치 솔루션에는 다중 마스터 인식(예: GFS) 파일 시스템이 필요하거나 하나의 노드만 파일 시스템 읽기-쓰기를 마운트해야 합니다. 일반적으로 파일 시스템은 그 아래의 블록 장치 수준에서 데이터가 변경되는 것을 싫어합니다. 즉, 클라이언트는 어느 것이 마스터인지 확인하고 거기에 직접 쓰기 요청을 할 수 있어야 합니다. 그것은 큰 골칫거리가 될 수도 있습니다. GFS 및 모든 지원 인프라가 옵션인 경우 다중 마스터 모드("이중 기본"이라고 함)의 drbd가 잘 작동할 수 있습니다. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode이에 대한 자세한 내용은
어떤 방향으로 가든 SAN 회사에 많은 돈을 주지 않고 실시간으로 작업을 수행하는 것은 여전히 상당히 큰 고통이라는 것을 알게 될 것입니다.
답변2
Proxmox VE 설정의 도움으로 rsync에서 ceph로 전환했습니다.
이제 실시간 복제를 통해 하나의 클러스터에서 14TB를 관리하고 있습니다. 거의 4년 동안.