최근에 저는 두 가지 서버 구성으로 ceph를 구축했습니다.
가장 불안한 점은 ceph 클러스터에 두 서버가 올바르게 복제되었는지 확인하는 방법을 모른다는 것입니다.
ceph를 사용하는 사람이 데이터가 복제되었음을 확인한 사람이 있습니까?
답변1
만일의 경우를 대비해: 일반적으로 2노드 구성은 프로덕션 환경이 아닌 테스트 환경을 위한 것입니다. 2노드 클러스터는 이러한 오류에 더 취약하므로 중복성 또는 가동 시간 중 무엇을 잃을지 선택할 수 있습니다. 풀 구성에 따라 추가 데이터 손실이 발생할 수도 있습니다.
2노드 클러스터가 있고 여기에 데이터를 저장할 풀을 만들어야 한다고 가정해 보겠습니다. ceph에는 미리 구성된 몇 가지 기본값이 있는데, 그 중 하나가 데이터의 복제 크기를 반영하는 기본 풀 크기입니다. 풀 크기 3(기본값)은 클러스터에 업로드하는 모든 객체의 복사본이 3개(원본 복사본 1개와 복사본 2개) 있음을 의미합니다. 다음을 통해 풀 크기를 얻을 수 있습니다.
host1:~ # ceph osd pool get <POOL> size
size: 3
host1:~ # ceph osd pool get <POOL> min_size
min_size: 2
min_size 매개변수는 풀에서 아직 작동 중인 최소 복제본 수를 결정합니다. 예를 들어 min_size와 크기가 모두 3인 경우 객체가 오류 상태에 있을 때 클러스터는 풀에 대한 I/O를 중지합니다. 위와 같은 구성(min_size 2, size 3)이 있으면 복제본 중 하나가 비정상이더라도 데이터가 처리됩니다. 귀하의 경우 풀 크기는 2이고 min_size는 1이 필요합니다. 단, 정상일 때만 풀에 대한 쓰기를 허용하기로 결정한 경우가 아니면 2와 2가 권장됩니다.
이제 두 복제본이 모두 활성 상태인지 확인하려면(HEALTH_OK 상태인 클러스터 제외) 다음을 확인할 수 있습니다.
# Get PGs per pool
host1:~ # ceph pg ls-by-pool <POOL>
PG_STAT OBJECTS MISSING_ON_PRIMARY DEGRADED MISPLACED UNFOUND BYTES LOG DISK_LOG STATE STATE_STAMP VERSION REPORTED UP UP_PRIMARY ACTING ACTING_PRIMARY LAST_SCRUB SCRUB_STAMP LAST_DEEP_SCRUB DEEP_SCRUB_STAMP
3.0 24 0 0 0 0 100663296 84 84 active+clean 2018-09-24 10:00:31.274193 86'84 182:119 [5,7,0] 5 [5,7,0] 5 86'84 2018-09-23 10:39:06.518211 0'0 2018-09-18 14:41:06.260403
[...]
# Get mapping of a PG
host1:~ # ceph pg map 3.0
osdmap e182 pg 3.0 (3.0) -> up [5,7,0] acting [5,7,0]
보시다시피 이 특정 PG에는 OSD 5, 7, 0에 3개의 복제본(크기 = 3)이 있으며 OSD.5는 클라이언트에 데이터를 제공하는 기본 OSD입니다.
클러스터가 Filestore 또는 Bluestore에 구축되어 있나요? 파일 스토리지 클러스터가 있는 경우 서버의 파일 시스템에 있는 개체의 파일 위치를 확인할 수 있습니다.이것이 정보를 검색하는 방법에 대한 예는 "클러스터에서 개체 검색" 섹션을 참조하세요. 현재 파일 저장소 클러스터가 없습니다. 하지만 bluestore 클러스터에서는 이것이 작동하지 않습니다. 파일을 더 이상 찾아볼 수 없습니다.