WAN을 통해 일부 사이트에 표준 파일 서버를 배포해야하는 응용 프로그램을 만들고 있습니다. 기본적으로 각 사이트는 다양한 크기 (일부 100MB 범위이지만 가장 작은 크기)의 기타 파일을 많이 작성해야하며 충돌이 문제가되지 않도록 응용 프로그램이 작성됩니다. 다음 자격 요건을 충족하는 시스템을 설정하고 싶습니다.
- 각 사이트는 파일을 공유 된 "네임 스페이스"에 저장할 수 있습니다. 즉, 모든 파일이 동일한 파일 시스템에 나타납니다.
- 각 사이트는 필요하지 않으면 WAN을 통해 데이터를 보내지 않습니다. 즉, WAN의 양쪽에 동일한 논리 파일 시스템에 "병합"될 로컬 스토리지가 있습니다.
- Linux & Free ($$$)는 플러스
기본적으로 중앙 NFS 공유와 같은 것은 대부분의 요구 사항을 충족하지만 로컬로 작성된 데이터를 로컬로 유지할 수는 없습니다. WAN의 원격 측에있는 모든 데이터는 항상 로컬로 복사됩니다.
Lustre를 살펴보고 성공적인 테스트를 수행했지만 분산 스토리지에 파일을 상당히 균일하게 분배하는 것으로 보입니다. 설명서를 발굴했으며 원격 저장소보다 로컬 저장소를 자동으로 "선호"하는 것을 찾지 못했습니다. 지연 시간이 가장 낮은 스토리지와 함께 제공되는 것도 괜찮습니다. 대부분의 경우 작동하며이 응용 프로그램의 요구 사항을 충족합니다.
아래에 몇 가지 질문에 대한 답변이 있습니다.
- 서버 노드 : 2 또는 3을 시작합니다. 각 서버에는 수십 개의 동시 읽기 / 쓰기 클라이언트가 연결되어 있습니다.
- WAN 토폴로지는 완전한 메시이며 신뢰할 수 있습니다. (대기업, 비용은 레드 테이프만큼 제한되지 않습니다)
- 클라이언트 장애 조치 : 실제로 클라이언트 장애 조치에 대해 생각하지 않았습니다 (대부분 현재 응용 프로그램은 한 사이트에서만이를 수행하지 않기 때문에). 실제로 대답은 지리적으로 분산 된 각 사이트의 서버가 서비스를 제공하는 클라이언트에 대해 단일 지점 장애 일 것으로 예상됩니다. 비록 당신이 여기에 특정한 것을 생각하고 있다면, 나는 그것이 토론에 아주 밀접한 것이라고 생각합니다.
- Roll-my-own : rsync / unison에 대해 생각했지만이 작업의 "동적"부분을 원활하게 만들기 위해서는 약간의 멋진 논리가 필요합니다. 즉, 파일이 로컬 인 것처럼 보이지만 요청시에만 검색됩니다.
- MS-DFS : 확실히 살펴 봐야 할 것 같습니다. 연결하는 많은 클라이언트가 NFS 클라이언트이므로 Windows의 NFS 서버 구성 / 신뢰성 / 성능에 대해 확신이 서지 않을 수 있습니다.
Linux의 하드 요구 사항을 충족하고 Free to Plus.
—
dpb