Gluster는 정확히 무엇을합니까?

나는 지난 이틀 동안 글 러스터를 가지고 놀았으며 여기와 그들의 질문 시스템에 질문을하고 있습니다. 나는 정말로 물건의 일부를 이해하지 못한다. 사람들이 같은 말을하는 것을 봅니다

서버간에 복제 된 브릭을 설정하면 (3 개만 사용하고 복제 된 것이 더 안전하므로) 각 서버는 다른 모든 서버의 파일을 '로컬'인 것으로 간주합니다. 한 서버에 장애가 발생하더라도 파일이 다른 서버.

또는

Gluster는 볼륨 (브릭)간에 파일 동기화를 유지하며 하나의 서버가 오프라인 상태이므로 불일치를 처리하는 '자가 치유'기능이 있습니다.

서버에서 클라이언트로 원격 볼륨을 마운트 하기 때문에 Gluster는 서버 노드의 장애를 어떻게 처리합니까? 볼륨을 마운트 한 클라이언트의 폴더에서 시도한 결과에서 액세스 할 수 없으므로 umount를 사용하여 차단을 해제해야합니다. 그리고 그 후에 서버의 내용이 없습니다.

이것은 기본적으로 설명에서 다루지 않는 것입니다 : 서버 노드가 실패 할 때 발생하는 일과 유니슨 또는 rsync와 같이 실제로 내용을 복제 할 수 있는지 여부는 무엇입니까?

우리는 최근에 우리 자신의 사용법에 대해 GlusterFS를 연구하기 시작했습니다. Gluster는 FUSE 클라이언트에서 '번역기'를 사용하여 데이터 저장 방법을 처리합니다. 여기에는 몇 가지 유형의 번역기가 있습니다.

http://www.gluster.com/community/documentation/index.php/GlusterFS_Translators_v1.3

구체적으로 묻는 것은 자동 파일 복제 번역기 또는 AFR이라고하며 여기에서 자세히 다루고 있습니다.

http://www.gluster.com/community/documentation/index.php/Understanding_AFR_Translator

소스 코드를 보면 데이터가 실제로 rsync보다 훨씬 나은 동시에 노드에 기록되는 것으로 보입니다!

장애 상황에서의 복구와 관련하여 내가 찾은 흥미로운 메모가 하나 있습니다. Gluster 시스템은 복제 상태 변경을 적극적으로 인식하지 않고 '트리거'되어야한다는 점에서 Ceph와 다릅니다. 따라서 클러스터에서 노드가 손실되면 Gluster가 복제되었는지 확인하기 위해 각 파일을 찾아야합니다.

http://www.gluster.com/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate

클라이언트가 문제를 감지하는 방법과 같이 내부적으로 실패 시나리오 메커니즘을 설명하는 좋은 페이지를 찾을 수 없습니다. 그러나 소스 코드를 다운로드하고 클라이언트를 살펴보면 명령에 사용하는 다양한 시간 제한이 있으며 클러스터의 다른 시스템에 대해 자주 수행하는 프로브가 있습니다. 이 중 대부분은 TODO 마크를 가지고 있고 소스 코드 수정을 제외하고는 현재 구성 할 수없는 것 같습니다. 수렴 시간이 중요한 경우 문제가 될 수 있습니다.

2 개의 노드 복제만으로 Gluster는 자동 rsync 스크립트와 크게 다르지 않습니다. 4 개 이상의 스토리지 노드가있는 경우 상황이 실제로 흥미로워지기 시작합니다. 클라이언트 시스템에 공간 풀이 표시되지만 구성 파일은 모든 스토리지 노드 (브릭)에 분산됩니다. 즉, 4 대의 서버에 10TB의 로컬 공간이있는 경우 클라이언트 시스템은 단일 네임 스페이스가 20TB (복제 된 또는 40TB의 비보호 스토리지)를 볼 수 있습니다.

스토리지 브릭을 사용할 수 없게 된 후 IO를 시도 할 때 클라이언트 시스템에서 약 30 초 정도의 짧은 딸꾹질을 보았습니다. 그러나 딸꾹질 후에도 여전히 전체 볼륨 데이터 세트를 보유하는 서버가 온라인 상태 인 한 IO는 정상적으로 계속됩니다.

예상치 못한 동작을 설명하고 있습니다. irc.freenode.net 또는 gluster-users@gluster.org 또는 http://community.gluster.org/ 에서 #gluster를 참조하십시오 .

존 마크 글 러스터 커뮤니티 가이

클라이언트 쪽 서버가 실패하면 (즉, 클라이언트가 파일 시스템을 마운트하기 위해 IP / DNS를 사용한 서버) 실패하면 전체 볼륨이 해당 클라이언트에 대해 오프라인 상태가됩니다. 즉, 볼륨에서 읽거나 쓸 수 없습니다.

그러나 클라이언트가 다른 서버의 IP / DNS를 사용하여 마운트 한 경우 해당 클라이언트의 볼륨은 여전히 ​​온라인 상태입니다. 그러나 읽기 / 쓰기는 실패 / 크래쉬 된 인스턴스로 이동하지 않습니다.