처리 기능에 사용하는 GlusterFS 클러스터가 있습니다. Windows를 통합하려고하지만 GlusterFS 볼륨을 제공하는 Samba 서버 인 단일 장애 지점을 피하는 방법을 알아내는 데 어려움이 있습니다.
파일 흐름은 다음과 같이 작동합니다.
- 파일은 Linux 처리 노드에서 읽습니다.
- 파일이 처리됩니다.
- 결과 (작거나 클 수 있음)가 완료되면 GlusterFS 볼륨에 다시 기록됩니다.
- 대신 데이터베이스에 결과를 쓰거나 다양한 크기의 여러 파일을 포함 할 수 있습니다.
- 처리 노드는 큐와 GOTO 1에서 다른 작업을 선택합니다.
Gluster는 즉각적인 복제뿐만 아니라 분산 된 볼륨을 제공하기 때문에 훌륭합니다. 재난 복원력이 좋습니다! 우리는 그것을 좋아합니다.
그러나 Windows에는 기본 GlusterFS 클라이언트가 없으므로 Windows 기반 처리 노드가 비슷한 방식으로 파일 저장소와 상호 작용할 수있는 방법이 필요합니다. 글루 스터 FS (GlusterFS) 문서 상태 윈도우 액세스를 제공 할 수있는 방법은 위에 삼바 서버를 설정하는 것입니다은 글루 스터 FS (GlusterFS) 볼륨을 탑재. 그러면 다음과 같은 파일 흐름이 발생합니다.
그것은 하나의 실패 지점처럼 보입니다.
하나의 옵션은 Samba 를 클러스터링하는 것이지만 현재 불안정한 코드를 기반으로 실행 중입니다.
그래서 다른 방법을 찾고 있습니다.
우리가 던지는 데이터 종류에 대한 몇 가지 주요 세부 사항 :
- 원본 파일 크기는 몇 KB에서 수십 GB 사이 일 수 있습니다.
- 처리 된 파일 크기는 몇 KB에서 1GB 또는 2GB가 될 수 있습니다.
- .zip 또는 .tar와 같은 아카이브 파일을 파는 것과 같은 특정 프로세스는 포함 된 파일을 파일 저장소로 가져올 때 많은 추가 쓰기를 유발할 수 있습니다.
- 파일 수는 수천만에이를 수 있습니다.
이 워크로드는 "정적 작업 단위 크기"Hadoop 설정에서 작동하지 않습니다. 마찬가지로 S3 스타일 객체 저장소를 평가했지만 부족한 것으로 나타났습니다.
우리의 응용 프로그램은 Ruby로 작성된 사용자 정의이며 Windows 노드에 Cygwin 환경이 있습니다. 이것은 우리에게 도움이 될 수 있습니다.
내가 고려하고있는 한 가지 옵션은 GlusterFS 볼륨이 마운트 된 서버 클러스터의 간단한 HTTP 서비스입니다. Gluster로 수행하는 모든 작업은 본질적으로 GET / PUT 작업이므로 HTTP 기반 파일 전송 방법으로 쉽게 전송할 수 있습니다. 그것들을로드 밸런서 쌍 뒤에 놓으면 Windows 노드는 작은 푸른 마음의 내용에 HTTP PUT 할 수 있습니다.
내가 모르는 것은 GlusterFS 일관성이 유지되는 방법 입니다. HTTP 프록시 계층은 처리 노드에서 쓰기 작업이 완료되었다고보고 할 때와 실제로 GlusterFS 볼륨에서 볼 수있을 때 사이에 충분한 대기 시간을 제공합니다. 그것을 찾아라. 나는 꽤 반드시 사용하는 것이 해요 direct-io-mode=enable마운트 옵션을하면 도움이 될 것입니다, 하지만 확실하지가 충분한 경우 해요 . 일관성을 향상시키기 위해 무엇을해야합니까?
아니면 다른 방법을 완전히 추구해야합니까?
Tom이 아래에서 지적했듯이 NFS는 다른 옵션입니다. 그래서 나는 시험을 치렀다. 위에서 언급 한 파일에는 클라이언트가 제공 한 이름이 있어야하며 어떤 언어로도 제공 될 수 있으므로 파일 이름을 보존해야합니다. 그래서 나는이 파일들로 디렉토리를 만들었습니다 :
NFS 클라이언트가 설치된 Server 2008 R2 시스템에서 마운트하면 다음과 같은 디렉토리 목록이 표시됩니다.
분명히, 유니 코드는 보존되지 않습니다. 따라서 NFS가 작동하지 않습니다.
ctdb안정적이고 프로덕션 사용 준비가 된 것으로 간주 하고 링크의 첫 번째 문장은 두 번째 문장이 업데이트되지 않았으므로 무효로 만듭니다. 나는 이것을 확립하려고 계획하고 있었지만, 이것에 도착하기 전에 거의 창문이없는 환경으로 작업을 전환했습니다.