ceph로 데이터 날려보면서 계속 배우고 있네요.
이번에 배운것은.. RBD pool을 erasure code로 사용하면서 발생 했습니다.
결론부터 말하자면 복구 성능 이슈로 RBD pool을 erasure code로 사용하면 안됩니다.
어떤 환경에서 사용중이었는지 설명해주세요.
저는 proxmox 머신 3대를 clustering하여 사용하고 있습니다.
proxmox의 ceph도 사용 중입니다.
당연히 vm 부팅에 사용되는 가상디스크 이미지는 mirror된 풀에 저장되어있습니다.
왜 disk 이미지가 저장되는 RBD pool을 erasure coded pool을 만들게 되었는가?
Timemachine 백업 이미지가 포함되는 가상디스크였습니다.
timemachine 백업은 5기가 바이트 백업에 20, 30분씩 걸리는 작업입니다.
어차피 느린 작업이라는 이야기죠.
그래서 디스크 사용햐는 용량을 줄이기 위하여 Erasure coded pool을 생성하게 되었습니다.
그런데… pveceph를 통해서 디스크 이미지 저장용 erasure coded pool을 생성하였더니 osd pool이 되게가 생성되더군요
cephfs를 사용하려면 metadata pool과 data pool이 필요한 것처럼, metadata pool과 data pool이 생성되었습니다.
timemachine 백업하는데 별로 성능 차이가 안나더군요.
특히 vm의 disk에 writeback cache를 설정하면 더욱더 차이가 안납니다.
그래서 사용하게 되었죠. 하지만…
문제점: ceph recovery 성능의 하락
그러던 중 디스크 하나를 교체하게 되었는데…
recovery 성능이 반의 반토막이 나버리는 것입니다.
보통은 20~30MB/s씩 꾸준히 작업되는데, 이 때는 3MB/s 되었다가, 5초 이상이 0MB/s가 되어버리는 일이 반복 되었죠.
이유를 찾기 위해 많은 조사를 했습니다.
원인: 너무 많은 objects
recovery는 0 MB/s인 경우라도 recovery가 중단된것은 아닐 수 있습니다.
recovery에서는 크게 두가지를 복원 합니다.
data와 object이죠.
다르게 말해서 데이터가 복원되고 있지 않아 0 MB/s이더라도
object는 복원중일 수 있다는 이야깁니다.
어쨋든 둘 중 하나라도 복원 중이라면 복원은 진행중이라고 볼수 있으니까요.
예를 들어 아래의 ceph df detail 명령 실행 결과에서 cephfs-userdata-hdd_data를 보면 크기는 24 KiB인데, object는 451.58k개가 존재하는 것을 볼수 있죠.
root@pve3:~[1]#ceph df detail 0.231s 23:31:37
--- RAW STORAGE ---
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 33 TiB 16 TiB 17 TiB 17 TiB 51.56
hdd-mirror 1.9 TiB 1.7 TiB 137 GiB 137 GiB 7.22
ssd 5.7 TiB 4.4 TiB 1.3 TiB 1.3 TiB 22.46
TOTAL 41 TiB 22 TiB 19 TiB 19 TiB 45.50
--- POOLS ---
POOL ID PGS STORED (DATA) (OMAP) OBJECTS USED (DATA) (OMAP) %USED MAX AVAIL QUOTA OBJECTS QUOTA BYTES DIRTY USED COMPR UNDER COMPR
osdpool_rbd_diskimage_nvme 8 128 579 GiB 579 GiB 13 KiB 220.30k 954 GiB 954 GiB 38 KiB 18.93 1.3 TiB N/A N/A N/A 492 GiB 1.1 TiB
cephfs-userdata-nvme_data 11 16 127 GiB 127 GiB 0 B 166.74k 107 GiB 107 GiB 0 B 2.55 1.3 TiB N/A N/A N/A 38 GiB 218 GiB
cephfs-userdata-nvme_metadata 12 4 891 MiB 530 MiB 361 MiB 921.63k 1.2 GiB 193 MiB 1.1 GiB 0.03 1.3 TiB N/A N/A N/A 177 MiB 1.5 GiB
cephfs-userdata-snapshotless_data 23 1 2.9 GiB 2.9 GiB 0 B 815 5.3 GiB 5.3 GiB 0 B 0.13 1.3 TiB N/A N/A N/A 2.3 GiB 5.9 GiB
cephfs-userdata-snapshotless_metadata 24 1 492 MiB 492 MiB 41 KiB 182 1.4 GiB 1.4 GiB 122 KiB 0.03 1.3 TiB N/A N/A N/A 51 MiB 110 MiB
cephfs-userdata-hdd_data 89 32 6.0 KiB 6.0 KiB 0 B 451.58k 24 KiB 24 KiB 0 B 0 3.0 TiB N/A N/A N/A 0 B 0 B
cephfs-userdata-hdd_metadata 90 16 511 MiB 436 MiB 76 MiB 48.81k 352 MiB 126 MiB 227 MiB 0 1.3 TiB N/A N/A N/A 109 MiB 1.3 GiB
cephfs-userdata-hdd_data_ec 123 128 6.9 TiB 6.9 TiB 0 B 2.22M 15 TiB 15 TiB 0 B 63.72 3.9 TiB N/A N/A N/A 156 GiB 312 GiB
.mgr 125 1 61 MiB 61 MiB 0 B 17 183 MiB 183 MiB 0 B 0 1.3 TiB N/A N/A N/A 0 B 0 B
osdpool_rbd_diskimage_hdd 131 32 667 GiB 667 GiB 3.9 KiB 170.85k 2.0 TiB 2.0 TiB 12 KiB 18.03 3.0 TiB N/A N/A N/A 3.2 GiB 6.5 GiB이 pool에 문제가 발생하여 복원하면서 data가 0MB/s로 복원이 되는 증상이 발생한다면
obj가 복구되는 순간이라고 볼수 있습니다.
조금 전, 위에서 제가 3MB/s 되었다가, 5초 이상이 0MB/s가 되어버리는 일이 반복 되었죠라고 말씀 드렸습니다.
이 때도 똑같이 object가 더 많이 복구 되는 중이라서 발생한 문제였습니다.
erasure coded rbd pool은 object가 너무 많이 생성된다.
결론은 이것입니다.
object가 무지막지하게 많이 생성됩니다.
그래서 object 복구하는데 너무나도 많은 시간이 소요되요.
erasure code를 사용했을 때는 5일 복원 하는동안, 5%가 복원 되었습니다.
하지만 erasure coded를 없애니, 5일이면 70%가 복원이 됩니다.ㅎㅎㅎ
답글 남기기