와 함께하둡그리고카우치DB실제로 작동하는 분산 내결함성 스토리지(엔진)가 무엇인지 블로그 및 관련 뉴스 전반에 걸쳐 나와 있습니다.
- CouchDB에는 실제로 배포 기능이 내장되어 있지 않습니다. 제가 아는 바로는 항목이나 전체 데이터베이스를 자동으로 배포하는 기능이 없습니다.
- Hadoop은 매우 널리 사용되는 것으로 보입니다. 적어도 언론에서는 좋은 평가를 받고 있지만 여전히 단일 실패 지점인 NameNode가 있습니다. 게다가 FUSE를 통해서만 마운트할 수 있습니다. HDFS가 실제로 Hadoop의 주요 목표가 아니라는 것을 알고 있습니다.
- GlusterFS공유 없음 개념이 있지만 최근에는 그다지 안정적이지 않다는 의견을 제시하는 여러 게시물을 읽었습니다.
- 광택또한 전용 메타데이터 서버를 사용하므로 단일 실패 지점이 있습니다.
- 세프선택한 플레이어인 것 같지만 홈페이지에는 아직 알파 단계에 있다고 나와 있습니다.
따라서 문제는 어떤 분산 파일 시스템이 다음 기능 세트(특정 순서 없음)를 가지고 있는지입니다.
- POSIX 호환
- 손쉬운 노드 추가/제거
- 아무것도 공유하지 않는 개념
- 저렴한 하드웨어(AMD Geode 또는 VIA Eden 클래스 프로세서)에서 실행됩니다.
- 인증/권한 부여 내장
- 네트워크 파일 시스템(다른 호스트에 동시에 마운트하고 싶습니다)
가져서 좋다:
- 로컬로 액세스 가능한 파일: 표준 로컬 파일 시스템(ext3/xfs/무엇이든...)을 사용하여 파티션을 마운트하고 노드를 내려 파일에 계속 액세스할 수 있습니다.
나는~ 아니다호스팅된 애플리케이션을 찾고 있는 것은 오히려 각 하드웨어 상자에서 10GB를 가져가서 해당 스토리지를 네트워크에서 사용할 수 있고 여러 호스트에 쉽게 마운트할 수 있는 것입니다.
답변1
나는 POSIX 요구 사항을 포기해야 한다고 생각합니다. 이를 구현하는 시스템은 거의 없습니다. 실제로 NFS조차도 실제로는 그렇지 않으며(잠금 등을 생각하면) 중복성이 없습니다.
동기식 복제를 사용하는 모든 시스템은 극도로 느려질 것입니다. 비동기 복제(또는 "최종 일관성")가 있는 시스템은 POSIX 규칙을 위반하고 "기존" 파일 시스템처럼 작동하지 않습니다.
답변2
다른 분들에게 말씀드릴 수는 없지만 '분산 스토리지 엔진'과 '분산 파일 시스템'을 혼동하시는 것 같습니다. 그것들은 똑같은 것이 아니며, 똑같은 것으로 착각해서는 안 되며, 결코 똑같은 것이 될 수 없습니다. 파일 시스템은 하드 드라이브에서 항목의 위치를 추적하는 방법입니다. hadoop과 같은 스토리지 엔진은 키로 식별되는 데이터 덩어리를 추적하는 방법입니다. 개념적으로는 큰 차이가 없습니다. 문제는 파일 시스템이 스토리지 엔진의 종속성이라는 것입니다. 결국 블록 장치에 쓸 수 있는 방법이 필요하지 않습니까?
그 모든 것을 제쳐두고, 나는~할 수 있다프로덕션 환경에서 분산 파일 시스템으로 ocfs2를 사용하는 방법에 대해 설명합니다. 거친 세부 사항을 원하지 않으면 다음 줄 이후 읽기를 중단하십시오. 꽤 멋지지만 생각보다 가동 중지 시간이 길어질 수 있습니다.
우리는 지난 몇 년 동안 프로덕션 환경에서 ocfs2를 실행해 왔습니다. 괜찮지만 많은 응용 프로그램에는 적합하지 않습니다. 실제로 요구 사항을 살펴보고 그것이 무엇인지 파악해야 합니다. 생각했던 것보다 결함에 대한 허용 범위가 훨씬 더 크다는 것을 알 수 있습니다.
예를 들어, ocfs2에는 파티션을 마운트할 클러스터의 각 시스템에 대한 저널이 있습니다. 따라서 4개의 웹 시스템이 있고 mkfs.ocfs2를 사용하여 해당 파티션을 만들 때 성장할 수 있는 공간을 제공하기 위해 총 6개의 시스템이 있도록 지정한다고 가정해 보겠습니다. 각 저널은 공간을 차지하므로 디스크에 저장할 수 있는 데이터의 양이 줄어듭니다. 이제 7대의 머신으로 확장해야 한다고 가정해 보겠습니다. 그런 상황에서는, 당신은 아래로 내려야합니다전체클러스터를 만들고(즉, 모든 ocfs2 파티션을 마운트 해제하고) tunefs.ocfs2 유틸리티를 사용하여 사용 가능한 공간이 있는 경우 추가 저널을 생성합니다. 그런 다음에만 일곱 번째 시스템을 클러스터에 추가하고(유틸리티를 사용하지 않는 한 클러스터의 나머지 부분에 텍스트 파일을 배포해야 함) 모든 것을 백업한 다음 일곱 번째 시스템 모두에 파티션을 마운트할 수 있습니다. 기계.
무슨 말인지 알겠어요? 이는 '항상 온라인'을 의미하는 고가용성이어야 하지만 바로 거기에는 많은 가동 중지 시간이 있으며... 디스크 공간이 부족하다는 것은 신의 뜻입니다. 당신은 ocfs2를 크라우드할 때 무슨 일이 일어나는지 보고 싶지 않습니다.
ocfs2 클러스터를 관리하는 데 '선호되는' 방법이었던 evms는 clvmd 및 lvm2를 선호하는 도도새의 길을 갔다는 점을 명심하십시오. (그리고 evms에 대한 좋은 제거입니다.) 또한 heartbeat는 openais/pacemaker 스택을 선호하는 좀비 프로젝트로 빠르게 바뀔 것입니다. (참고: ocfs2에 대한 초기 클러스터 구성을 수행할 때 하트비트가 아닌 클러스터 엔진으로 'pcmk'를 지정할 수 있습니다. 아니요, 이에 대해서는 문서화되어 있지 않습니다.)
그 가치를 위해 우리는 Pacemaker가 관리하는 nfs로 돌아갔습니다. 왜냐하면 Pacemaker가 nfs 공유를 다른 시스템으로 마이그레이션할 때 발생하는 몇 초의 가동 중지 시간 또는 몇 개의 TCP 패킷 삭제는 기본 시스템에서 확인했던 가동 중지 시간에 비해 사소하기 때문입니다. ocfs2를 사용할 때 머신 추가와 같은 공유 스토리지 작업.
답변3
귀하의 요구 사항을 오해했을 수도 있지만 살펴 보셨습니까?http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems