CEPH의 원시 공간 사용량

ceph 원시 공간 사용량을 이해할 수 없습니다.

7 서버에 14 개의 HDD (14 개의 OSD)가 있으며 각 HDD 당 3TB ~ 총 42TB의 원시 공간이 있습니다.

ceph -s 
     osdmap e4055: 14 osds: 14 up, 14 in
      pgmap v8073416: 1920 pgs, 6 pools, 16777 GB data, 4196 kobjects
            33702 GB used, 5371 GB / 39074 GB avail

4 개의 블록 장치 (각각 5TB)를 만들었습니다.

df -h
 /dev/rbd1       5.0T  2.7T  2.4T  54% /mnt/part1
/dev/rbd2       5.0T  2.7T  2.4T  53% /mnt/part2
/dev/rbd3       5.0T  2.6T  2.5T  52% /mnt/part3
/dev/rbd4       5.0T  2.9T  2.2T  57% /mnt/part4

df는 총 10,9TB가 사용되고 ceph는 33702GB가 사용됨을 보여줍니다. 사본이 2 개인 경우 ~ 22TB 여야하지만 이제는 33,7TB를 사용했습니다. 11TB가 누락되었습니다.

ceph osd pool get archyvas size
size: 2


ceph df
GLOBAL:
    SIZE       AVAIL     RAW USED     %RAW USED
    39074G     5326G       33747G         86.37
POOLS:
    NAME          ID     USED      %USED     MAX AVAIL     OBJECTS
    data          0          0         0         1840G           0
    metadata      1          0         0         1840G           0
    archyvas      3      4158G     10.64         1840G     1065104
    archyvas2     4      4205G     10.76         1840G     1077119
    archyvas3     5      3931G     10.06         1840G     1006920
    archyvas4     6      4483G     11.47         1840G     1148291

장치 및 OSD FS 차단-XFS

centos xfs ceph

— 처녀성
소스

답변:

혼동의 원인 중 하나는 GB vs. GiB / TB vs. TiB (base 10 / base 2)이지만, 여기서 차이점을 모두 설명 할 수는 없습니다.

Ceph / RBD는 볼륨을위한 공간을 "지연 적으로"할당하려고합니다. 이것이 4 개의 5TB 볼륨을 생성했지만 20TB가 아니라 16TB가 사용되었다고보고하는 이유입니다. 그러나 16TB는 RBD 지원 파일 시스템의 "활성"내용의 합보다 많으며 이는 11TB에 불과합니다. 몇 가지 참고할 사항 :

RBD 지원 파일 시스템에서 파일을 삭제하면 파일 시스템은 내부적으로 블록을 사용 가능한 것으로 표시하지만 일반적으로 기본 블록 장치 (RBD)로 "복귀"하려고하지는 않습니다. 커널 RBD 버전이 최신 버전 (3.18 이상)이면 fstrim해제 된 블록을 RBD에 반환하는 데 사용할 수 있어야합니다 . 이 파일 시스템에서 다른 파일을 작성하고 삭제 한 것 같습니다.

로 표시된 순 데이터 사용량을 넘어서는 파일 시스템 오버 헤드도 있습니다 df. "슈퍼 블록"및 기타 파일 시스템 내부 데이터 구조 외에도 RBD가 데이터를 할당하는 세분성으로 인해 약간의 오버 헤드가 예상됩니다. RBD는 그 중 일부만 사용하더라도 항상 4MB 청크를 할당한다고 생각합니다.

— 슬레인
소스

그리고 나는 사이먼에 동의합니다. 우리의 두 대답이 모두 하나를 완성한다고 생각하십시오. btw. 젠장 20 시간 된 질문에 35 초 대답하는 데 나를 이겼습니까? : D

— 폭스

답변 해 주셔서 감사합니다. 이제 문제의 위치와 해결 방법을 이해합니다.

— virgism

가능한 옵션 : 1. Linux 커널> 3.18로 업그레이드하고 폐기 옵션으로 마운트하십시오. (커널 3.19.0-1.el6.elrepo.x86_64로 테스트했지만 매일 교착 상태가 발생했습니다); 2. 크기가 5TB 미만인 블록 장치를 다시 만듭니다 (XFS를 축소 할 수 없음). 3. HDD를 추가하고 OSD를 추가로 만듭니다.

— virgism

제대로 작동하는지 확인할 수 있습니다. 지난 주말 Ubuntu LTS 14.04.3 ( sudo apt-get install --install-recommends linux-generic-lts-vivid) 에서 Ceph 클라이언트 시스템의 커널을 3.19로 업그레이드하고 , rbd 볼륨을 재부팅, 다시 매핑 및 마운트 fstrim하고 각각의 볼륨을 실행 하고 작은 25TB 클러스터에서 450GB를 종합적으로 복구했습니다. 업그레이드 한 후에는 discard옵션을 사용 하여 rbd 볼륨 마운트를 시작하십시오 .

— 브라이언 클라인

나는 ceph 전문가는 아니지만 조금 추측 해 보도록하겠습니다.

블록 장치는 discard옵션 없이 장착되지 않습니다 . 따라서 작성 및 삭제 한 데이터는 파일 시스템 ( /mnt/part1) 에 표시되지 않지만 한 번 작성되고 트리밍되지 않은 경우 기본 파일 시스템에 유지됩니다.

USED풀 을 살펴보고 풀을 추가하면 16777GB가 ceph -s표시됩니다. 그리고 2 배 (2 부)를 곱하면 33554GB가 사용됩니다. 이는 거의 사용 된 공간입니다.

— 여우
소스

Fox의 답변에 동의합니다 (아래의 광산과 동시에 작성되었습니다 :-). discard"trim"은 기본적으로 사용되지 않는 블록을 블록 장치로 반환하는 데 사용할 수있는 동일한 메커니즘에 대해 다른 단어입니다. discard옵션으로 장착 하면 원하는 효과가 있습니다. 어떤 사람들 fstrim은 파일 시스템에 의한 연속적인 폐기로 인한 오버 헤드를 피하기 위해 주기적으로 실행하는 것을 선호합니다 . 이 기능이 작동하려면 RBD 드라이버가 TRIM / 삭제를 지원해야합니다. 앞에서 말했듯이 RBD 커널 드라이버는 Linux 3.18 부터이 작업을 수행 합니다 ( tracker.ceph.com/issues/190 참조) .

— sleinen