Ceph 의 이해(1)
Tags: ceph, storage, cloud
Published: 2024-06-28 13:45:05

## 개요
요번에 ceph 장비를 모니터링해야 된다는 말이 있어서... Ceph에 대해 좀 리서치 해봤다.
우린 사실 Ceph 관련된 모니터링 요소만 알면 되는데, 메트릭을 분석하려면 기본지식이 좀 있어야 하니 어쩔 수 없이[?] 메트릭에 나오는 단어들 위주로 분석을 한번 해봤다.

- 여담인데, 요즘은 참 좋은 시대긴 하다. GPT로 일단 간단하게 단어 스크리닝하고, 애매한 부분이나 이해가 안 되는 부분등은 도큐먼트로 채워 봤는데, GPT가 틀린 말을 거의 안 했음.
- 그래서 쪼금 틀린 부분이 있을 수 있고...어느정도 내 편의대로 생각한 부분도 있을것이다...대부분 문서로 확인은 했지만...

## Ceph?
[Ceph Intro](https://docs.ceph.com/en/reef/start/intro/)
![ceph intro](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/voqdf9by7j7k2cgebkv7.png)


- Ceph는 redhat이 만든 클라우드 플랫폼에 적합한 스토리지...서비스 같은 거?
- Object storage, block device, Filesystem 모두 지원!(대단하다)
- Cluster로 구성 가능하고, 대규모 파일 관리에 매우 좋아 보인다.
- Ceph는 매우 당연하게도 데이터 분산, 복제, 무결성 등을 지원하고, 데이터 분산 같은 것들은 CRUSH 라는 해시 알고리즘을 통해 분배하고 관리한다. CRUSH에 관해서는 자세히 찾아보진 않았지만, 상당히 자주 언급됨.


## OSD, object

![OSD](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/40aqubzdqcs1uofp0vzi.png)

1. object는 '논리적 최소 단위'로서, 일반적으로 생각하는 Object Storage의 객체와는 조금 동떨어진 것으로 보인다.(ceph에서는 RADOS object라고 함)
일반적인 Object storage와는 비슷한 점이 있는데 object는 filesystem처럼 특정 디렉토리 구조에 얽매이는 것이 아니라 'flat한 namespace'에 저장된다고 함. 계층이 존재하지 않는다.

2. OSD(object storage device)는 '물리 장비의 논리적 단위'로서 쉽게 말하면 disk 정도에 매핑될 것 같다. object는 OSD에 저장되고, OSD는 실제 디스크에 파일 세그먼트를 기록하는 형식이 되겠다.

## Placement Group

![PG](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vkos3kqaw4a6syny6xu1.png)

PG(Placement group)은 '논리적 단위'인데, 대부분의 분산, 복제 작업이 이 단위를 기준으로 이루어진다.

'논리적 관점'에서는 object < PG.
'물리적 관점'에서는 object < OSD
가 된다.<br>
이 PG의 개념을 도큐먼트에서는 'layer of indirection'(간접 계층) 라고 부르는데, PG라는 간접 계층을 둠으로서 object와 OSD간의 결합도를 줄이고 유연성을 증대시키는 효과를 가져온다.

대충 살펴봤을때도 PG는 대부분의 데이터 무결성에 반드시 등장하는 존재이며, 해당 존재를 통해 Client가 접근해야 할 OSD를 정확하게 계산할 수 있다고 한다. 당연히 CRUSH 알고리즘을 통해서 ㅋㅋ

### Replication

![Replication](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xiosliopim7an9k8zi5v.png)

PG의 Replication은 나름대로 단순하다면 단순한 구조로, Primary, Secondary(+@)로 이루어진다.
Primary에 먼저 데이터를 쓰고, Primary라 secondary에 분배하는 형식으로 무난한 구조라고 볼 수 있다.

### Sharding

![erasure encoding](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sy61mvt9a7cyyn927nos.png)

PG의 Sharding은 erasure coding이라고 부르는데, erasure encoding function을 통해 데이터를 분해하고 추가 패리티를 붙여 OSD에 따로 저장한다.


![erasure decoding](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/929c733xq2r6gv511bkz.png)

마찬가지로 데이터 통합 시에는 decoding function을 이용하게 됨. 단순하다면 단순한 구조기도 하고...예시의 그림은 shard 하나가 실패(too slow)하는 것을 전제로 했는데, 이 상황에서는 데이터를 못 읽어오는 hang상태겠지만 실제로는 복제본이 있으니까 괜찮지 않을까 싶긴 하다.


## Pool

![Pool](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7s0aq62eeexgf6i8yp23.png)

Pool 또한 '논리 단위'로, Cluster보다는 작은 개념이지만 일종의 파티션 역할을 하는 단위이다.
살펴봤을때 Openstack의 project라던가, k8s의 namespace와 같은 분리 파티션 역할을 하는 것 같다.
<br>
Pool을 분리하면 해당 요소들이 달라지게 된다.

- Ownership/Access to Objects
- Number of Placement Groups
- CRUSH Rule

단순히 논리적 분리 뿐만 아니라 Crush rule이나 PG 조절, 설정 분리와 같은 것도 있기 때문에 분리가 잘 된다면 storage의 사용 용도나 장비의 여건에 따라 아예 다른 장비처럼 운용이 가능하다는 게 가장 큰 메리트.

## 전체 관계도

![ceph Architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0h4pe9j3i74aygiqqg00.png)

단순 도식화긴 하지만, 앞의 설명을 통해 어느정도 이해가 가능할 것이다.
<br>

## 결론
- 익숙한 개념들도 있고, 생소한 개념도 있고.
- 현대의 데이터 분산 시스템을 차용함과 동시에, object 단위를 기반으로 대규모 클러스터 시스템과 함께 쓸 수 있게 고안한 것 같다. 일반적인 Cloud-k8s 시스템에서 스토리지를 따로 찾아서 설정하고 볼륨 지정하고 이게 좀 귀찮았는데 ceph를 잘 이용하면 하나의 엔드포인트만 봐도 되니 꽤 좋아 보임.
- 다음은 PG를 중심으로 어떻게 데이터를 관리하고 분산하고 무결성을 확보하는지 알아본다.