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