WAN을 통해 일부 사이트에 표준 파일 서버를 배포해야하는 응용 프로그램을 만들고 있습니다. 기본적으로 각 사이트는 다양한 크기 (일부 100MB 범위이지만 가장 작은 크기)의 기타 파일을 많이 작성해야하며 충돌이 문제가되지 않도록 응용 프로그램이 작성됩니다. 다음 자격 요건을 충족하는 시스템을 설정하고 싶습니다.
- 각 사이트는 파일을 공유 된 “네임 스페이스”에 저장할 수 있습니다. 즉, 모든 파일이 동일한 파일 시스템에 나타납니다.
- 각 사이트는 필요하지 않으면 WAN을 통해 데이터를 보내지 않습니다. 즉, WAN의 양쪽에 동일한 논리 파일 시스템에 “병합”될 로컬 스토리지가 있습니다.
- Linux & Free ($$$)는 플러스
기본적으로 중앙 NFS 공유와 같은 것은 대부분의 요구 사항을 충족하지만 로컬로 작성된 데이터를 로컬로 유지할 수는 없습니다. WAN의 원격 측에있는 모든 데이터는 항상 로컬로 복사됩니다.
Lustre를 살펴보고 성공적인 테스트를 수행했지만 분산 스토리지에 파일을 상당히 균일하게 분배하는 것으로 보입니다. 설명서를 발굴했으며 원격 저장소보다 로컬 저장소를 자동으로 “선호”하는 것을 찾지 못했습니다. 지연 시간이 가장 낮은 스토리지와 함께 제공되는 것도 괜찮습니다. 대부분의 경우 작동하며이 응용 프로그램의 요구 사항을 충족합니다.
아래에 몇 가지 질문에 대한 답변이 있습니다.
- 서버 노드 : 2 또는 3을 시작합니다. 각 서버에는 수십 개의 동시 읽기 / 쓰기 클라이언트가 연결되어 있습니다.
- WAN 토폴로지는 완전한 메시이며 신뢰할 수 있습니다. (대기업, 비용은 레드 테이프만큼 제한되지 않습니다)
- 클라이언트 장애 조치 : 실제로 클라이언트 장애 조치에 대해 생각하지 않았습니다 (대부분 현재 응용 프로그램은 한 사이트에서만이를 수행하지 않기 때문에). 실제로 대답은 지리적으로 분산 된 각 사이트의 서버가 서비스를 제공하는 클라이언트에 대해 단일 지점 장애 일 것으로 예상됩니다. 비록 당신이 여기에 특정한 것을 생각하고 있다면, 나는 그것이 토론에 아주 밀접한 것이라고 생각합니다.
- Roll-my-own : rsync / unison에 대해 생각했지만이 작업의 “동적”부분을 원활하게 만들기 위해서는 약간의 멋진 논리가 필요합니다. 즉, 파일이 로컬 인 것처럼 보이지만 요청시에만 검색됩니다.
- MS-DFS : 확실히 살펴 봐야 할 것 같습니다. 연결하는 많은 클라이언트가 NFS 클라이언트이므로 Windows의 NFS 서버 구성 / 신뢰성 / 성능에 대해 확신이 서지 않을 수 있습니다.
답변
리눅스 요구 사항에 대한 수치심. 이것이 바로 Windows DFS의 기능입니다. 2003 R2 이후로 블록 수준에서도 수행됩니다.
답변
몇 가지 질문 :
-
이 일에 참여하고있는 “서버”노드는 몇 개입니까?
-
허브 및 스포크, 풀 메시와 같은 WAN 연결 토폴로지는 무엇입니까? 얼마나 신뢰할 수 있습니까?
-
로컬 서버에 장애가 발생하는 경우 클라이언트가 지리적으로 로컬이 아닌 서버로 장애 조치를 수행 하시겠습니까?
Windows DFS-R은 잠재적으로 막대한 라이센스 비용이 들더라도 확실히 찾고있는 것입니다.
충돌은 문제가 아니며 분산 잠금 관리자가 필요하지 않으므로 rsync 또는 Unison 과 같은 사용자 도구 로이 작업을 수행 하고 NFS로 파일의 결과 모음을 로컬 클라이언트로 내보낼 수 있습니다. 그것은 추악하고 복제 토폴로지 생성과 실제로 사용자 랜드 도구 실행을 처리하기 위해 일종의 시스템을 두드려 처리해야하지만 라이센스 비용이 갈수록 확실히 저렴합니다.
답변
AFS 를 고려 했습니까 ?
Andrew File System (AFS)은 신뢰할 수있는 서버 세트를 사용하여 모든 클라이언트 워크 스테이션에 동종의 위치 투명 파일 이름 공간을 제공하는 분산 네트워크 파일 시스템입니다.
알다시피, 최근 개발의 대부분은 OpenAFS 프로젝트의 배후에 있습니다.
“선호하는 지역성”기능을 사용할 수 있는지 알기 위해 프로젝트에 대해 잘 알고있는 척 할 수 없지만 그렇지 않은 경우에는 적합합니다.
답변
Lustre의 OST 수영장 을 보셨습니까 ?
자동은 아니지만 OST 풀을 사용하면 OST의 기본 라운드 로빈 / 스트라이핑 대신 기본적으로 정책 기반 스토리지 할당 인 특정 OST / OSS에 디렉토리 / 파일을 할당 할 수 있습니다.
따라서 사이트 당 디렉토리를 설정하고 해당 디렉토리를 해당 사이트의 로컬 OST에 할당하면 모든 I / O가 로컬 OST로 전달됩니다. 여전히 글로벌 네임 스페이스가됩니다.
WAN 연결을 통한 Luster (로컬 캐싱 서버 및 이와 유사한 것)를 개선하는 데 많은 작업이 진행되고 있지만 여전히 AFAIK가 많이 개발 중입니다.
답변
아마도 NFS이지만 응용 프로그램 서버에 Cachefs 가 있으면 목표의 일부를 달성 할 수 있습니다. 이해할 수 있듯이 모든 기록은 여전히 중앙 서버로 진행되지만 적어도 읽기는 로컬로 캐시 될 수 있습니다. 사용 패턴에 따라 읽기에서 많은 지연이 발생할 수 있습니다.
또한 mabye UnionFS를 살펴볼 가치가 있습니다. 이를 통해 각 위치가 NFS 내보내기가 될 것이라고 생각한 다음 각 위치에서 UnionFS를 사용하여 해당 위치에서 다른 모든 NFS 마운트가 하나의 파일 시스템으로 표시되도록 할 수 있습니다. 그래도 경험이 없습니다.
답변
DRBD를 조사하여 디스크를 복제 할 수 있습니다. http://www.drbd.org/ . 이것은 지금 막 커널로 만든 리눅스 고 가용성 솔루션입니다.
그러나 여기에는 몇 가지 제한 사항이 있습니다.
- 두 개의 노드 만 설정할 수 있습니다
- DRBD를 강력하게 유지하기에는 WAN이 너무 신뢰할 수 없습니다.
답변
간단하게 유지하려면 rsync를보고 많은 문제를 해결하고 스크립팅 할 수 있습니다.
