[Ceph] 개요 및 특징 (1) (Object storage 특징, File 저장 예시)

Ceph는 단일 분산 클러스터 상에 구축되는 object-based 분산 스토리지 시스템(distributed storage system)으로, file-level, object-level, block-level 모든 레벨의 interface를 제공한다[2].

 

이번 포스터에서는 이 Ceph라는 분산 스토리지 시스템에 대해서 정리해보고자 한다. 공부하는 수준에서 정리하는 자료이기에 틀린 내용이 있을 수도 있다. 

 

 

 

Ceph Overview

Ceph는 단일 분산 클러스터 상에 구축되는 object-based 분산 스토리지 시스템이다. Fig 1.을 통해 일단 한번 간단히 정리해보자.

 

Fig 1. Ceph Architecture 개요 [3]

 

Fig 1.은 Ceph 아키텍처를 표현한 그림이다. 그림의 오른쪽에 붙은 명칭들은 개인적으로 붙인 것으로 공식적인 용어가 아니다.

 

사용자 application(Ceph-client 혹은 직접 만든 애플리케이션)은 Ceph의 interface를 이용하여 Ceph에 데이터를 쓰거나 읽는 프로그램이다. 특히 후술하겠지만 Ceph는 다양한 interface를 제공하기에 Ceph를 사용하는 application은 다양한 방식으로 Ceph를 이용할 수 있다.

 

다음으로 Ceph interface layer이다. 앞서 말했듯, Ceph는 하나의 스토리지 시스템임에도 불구하고 스토리지 시스템의 3가지 유형, block-level, object-level, file-level interface를 모두 제공한다. 따라서 Ceph는 파일을 저장하는 file storage(Ceph fs), 오브젝트를 저장하는 object storage(rados gw, librados), 혹은 block storage(rbd) 역할을 동시에 수행할 수 있다.

 

이렇게 다양한 interface를 제공하지만 Ceph 내부는 object storage로 설계되었다. Ceph의 object-based software architecture를 RADOS(Reliable Autonomic Distributed Object Store)라고 한다. 이름에서 알 수 있다시피 Ceph는 object 포맷으로 데이터를 다루는 object storage로, Ceph의 interface를 통해 들어온 데이터(File, Block, Object)는 모두 RADOS를 통해 RADOS object 포맷으로 변환되어 Ceph에 저장된다.

 

마지막으로 Ceph Cluster of Computers이다. Ceph는 여러 컴퓨터들의 단일 클러스터 위에 구축이 된다. 이 컴퓨터들은 MON(monitor), MDS(metadata server), OSD(object storage daemon), MNG(manager) 역할 중 하나를 수행한다. OSD들은 실제 데이터 object가 저장되는 노드(컴퓨터)이며, 나머지 MON, MDS, MNG는 데이터가 저장되는 저장소 역할이 아닌 Ceph를 안정적으로 운영하기 위해 필요한 노드이다.

 

 

 

Object Storage의 장점

본격적으로 Object storage인 Ceph가 어떻게 데이터를 저장하는 지 정리하자. 앞선 포스터에서도 정리하였지만, Object storage는 데이터를 object 단위로 관리한다. Fig 2.는 Ceph에서 사용되는 RADOS object 형식을 나타낸 그림이다. 

 

Fig 2. Object 저장 형식 [5]

 

Binary Data는 저장하고자 하는 데이터, Metadata는 이 오브젝트와 관련된 정보(owner, 생성 시간, 최종 변경된 시간 등), ID는 이 오브젝트를 구별하는 유일한 값을 의미한다. Object storage는 Fig 2.와 같이 실제 데이터에 meatadata + ID를 추가하고 하나의 object로 만들어 이를 스토리지에 저장한다.

 

이때 주목할 것은 ID라는 값이다. 스토리지에 저장된 Object를 구별하는 유일한 값이 이 ID이다. 우리가 일반적으로 사용하는 파일 시스템(파일 스토리지)에서 파일을 구별하는 것은 파일이 위치한 경로와 파일의 이름이다. 예를 들면, [/home/user1/hello.txt],  [/home/user1/bye.txt], [/home/user2/hello.txt] 모두 다른 파일이라고 구별할 수 있다. 또한 우리가 파일 시스템에 데이터를 저장 혹은 읽고자 할 때, 파일의 [경로 + 이름]을 통해 저장 혹은 읽기를 요청한다.

 

반면에 object storage에서는 모든 object에는 유일한 ID가 부여되며, ID라는 값을 이용하여 구별 및 검색된다. ID가 다른 object는 다른 object를 의미한다. 또한 사용자가 데이터를 저장할 경우 object storage는 데이터를 포함한 object의 ID를 사용자에게 반환한다. 사용자가 만약 다시 데이터를 읽고 싶을 때는 이 ID를 기억했다가 object storage에 이 ID에 해당하는 object를 반환하도록 요청한다. Object storage의 장점은 데이터 구분이 하나의 숫자(ID)로 가능하다는 것이다.

 

File system에서는 File들의 hierarchy(디렉토리, 폴더 구조)를 누군가가 계속 관리해야 한다. 파일 생성 시 이름뿐만 아니라 경로(디렉토리) 또한 고려하여야 중복되는 파일 존재 유무를 확인할 수 있기 때문이다. 또한 distributed 시스템을 설계할 시에도 해당 파일이 어떤 컴퓨터에 저장될 지 설계하는 것도 매우 어렵다. [/home/user1/hello1.txt], [/home/user1/hello2.txt], [/home/user1/hello3.txt] 3가지 파일을 컴퓨터 1, 2, 3에 분산 저장한다고 생각해보자.

 

[hello1.txt]를 컴퓨터 1에, [hello2.txt]를 컴퓨터 2에, [hello3.txt]를 컴퓨터 3에 저장할 수도 있다. 이 경우 컴퓨터 1,2,3 모두에게 잘 분산 저장되었다고 생각할수도 있다. 하지만 만약 ls 명령어를 통해 폴더 [/home/user1/]에 무슨 데이터가 있는 지 알고자 한다면 문제가 발생한다. [/home/user1/] 내 파일이 컴퓨터 1, 2, 3 모두 저장되어 있다는 것도 알아야 하고, 안다고 하더라도 컴퓨터 1, 2, 3 모두 방문해서 정보를 얻어가야 한다.

 

이를 해결하기 위해 [/home/user1/] 폴더는 컴퓨터 1에만 저장한다고 하자. 이 경우에는 ls 명령어 사용 시 컴퓨터 1만 사용하면 되지만, 컴퓨터 2, 3은 놀고 있다. 이처럼 File system은 사용자가 편리하게 사용할 수 있지만, 그 자체는 분산 시스템으로 구현하기에 매우 복잡하고 비효율적인 부분이 있다.

 

그에 비해 object storage는 데이터를 숫자로 관리하기에 위와 같은 문제는 발생하지 않는다. 애초에 ls 명령어도 없고, 데이터 분산 또한 작은 규칙(Ceph에서는 CRUSH)만으로도 쉽게 데이터를 분산저장할 수 있다. 예를 들면 홀수면 컴퓨터 1에, 짝수면 컴퓨터 2에 저장한다 등. (File system에서는 숫자가 아닌 문자열을 사용하기에 이러한 규칙을 만들기도 복잡하다)

 

 

 

Ceph의 File 저장 예시

Fig 3. 은 Ceph에서 File을 저장하는 예시를 나타낸다. Ceph는 File system interface 또한 제공하기에 파일을 Ceph 내에 저장할 수 있다. 다만 Ceph 자체는 object storage이기에 파일을 objects들로 나누어 저장한다. 정리하자면 파일을 여러 objects들로 나눈 후 OSD에 저장한다. 이때 두 가지 의문이 들 수 있는데 왜, 어떤 기준으로 파일을 여러 개의 object로 나누는 지, 그리고 OSD에는 어떤 방식으로 저장되는 지이다.

 

Fig 2. Ceph File 저장 예시 [4]

 

일단 Ceph는 object의 size에 제한을 두지 않는다. 따라서 하나의 파일이 하나의 object가 될수도 있다. 다만 성능을 위해서 Ceph file system은 파일을 여러개의 objects로 나누어 저장한다. 이를 data striping이라고 한다. 10G짜리 파일 하나를 하나의 컴퓨터에 저장하는 것보다, 파일을 10개로 쪼개어 1G씩 컴퓨터 10개에 병렬로 저장하는 것이 더 빠르다. 10G짜리 파일을 읽을 때도 컴퓨터 하나에서 읽는 것보다는 10개에서 1G씩 병렬적으로 읽는 것이 더 빠르다.

 

다음으로 object들이 어떻게 OSD에 저장되는 지 알아보자. Fig 2.에서 object들이 OSD에 저장되기 이전에 PG(Placement Group)라는 단위로 묶이는 것을 볼 수 있다. 그림처럼 object들은 먼저 PG에 속하게되고, 같은 PG에 속하는 object들은 같은 OSD들에 저장된다. 이때, object는 여러개(3개)의 OSD에 중복되어 저장된다. 이는 안전한 데이터 보관을 위한 것으로 RAID1과 같은 원리이다. 하나의 OSD가 고장나더라도 나머지 OSD가 살아있기에 데이터를 계속 유지할 수 있다.

 

앞서 말했듯, object storage는 N번째 object가 어디 OSD(s)에 저장되는 지를 알고 있어야 한다. 그래야 N번째 object를 요구할 때, 해당 OSD에서 object를 읽어올 수 있다. 이때 모든 object 하나하나에 대해 어떤 OSD에 저장되어 있는 지 기록해두는 것은 비효율적이다. 이를 해결하기 위해 Ceph는 PG 개념과 CRUSH 개념을 도입하였다.

 

일단 Object ID에 따라 object들을 PG로 분류한다. 그리고 PG마다 어떤 OSD에 저장될 지 정보를 관리한다. 이러면 object 하나하나에 대해서 OSD 정보를 관리할 필요없이, PG 마다만 어떤 OSD들에 저장될 지 정보를 관리해도 된다. 특히 object ID로부터 PG를 구하는 식도 hash 함수를 통해 간단히 구현된다.

 

CRUSH(Controlled, Scalable, Decentralized Placement of Replicated Data)는 PG이 OSD에 저장되는 지를 알려주는 간단한 알고리즘이다. 즉 (PG-ID, OSDs) 정보를 하나하나 저장소에 저장해두는 것이 아닌, 실시간으로 해당 PG는 어디 OSD에 저장되어야 하는 지를 계산한다. 

 

이제 다시 파일을 쓰는 예시로 돌아오자. 사용자가 파일 하나를 Ceph 파일 시스템에 저장한다. Ceph가 자동으로 파일을 여러 object들로 나눈다. 각 object는 object ID가 부여된다. 이 object ID를 기반으로 각각의 object들은 PG에 할당된다. 이때 CRUSH 알고리즘을 통해 해당 PG는 어떤 OSD들에 저장되는 지를 계산한다. 이 정보를 바탕으로 Ceph는 모든 object를 OSDs에 안전하게 저장한다. 저장이 완료되면 사용자에게 파일 object들의 ID를 알려준다.

 

사용자가 파일을 읽고자 한다. 사용자는 자신의 object들의 ID를 이용해 직접 <PG정보+CRUSH 알고리즘>를 통해 어떤 OSD에 저장되어 있는 지를 알 수 있다. 이 정보를 바탕으로 사용자는 해당 OSD에 데이터를 달라고 요청하면 파일 읽기도 잘 작동한다. (사실 사용자가 직접 ID를 관리하는 것이 아닌 Ceph FS가 직접해주는 걸 수도 있다. 이는 확인이 필요하다.)

 

 

 

Reference

[1] https://ceph.io/en/

[2] https://en.wikipedia.org/wiki/Ceph_(software)

[3] https://subscription.packtpub.com/book/application-development/9781784393502/1/ch01lvl1sec12/ceph-the-architectural-overview

[4] Ken Birman. Spring, 2019. CS 5412/LECTURE 24. CEPH: A SCALABLE HIGH-PERFORMANCE DISTRIBUTED FILE SYSTEM. CORNELL

[5] https://docs.ceph.com/en/latest/architecture/

[6] Christian Bandulet, Principal Engineer, Sun Microsystems, The Storage Evolution: From Blocks, Files and Objects to Object Storage Systems, SNIA, 2008