# Learning Ceph

<style>
.indent-title-1{
margin-left: 1em;
}
.indent-title-2{
margin-left: 2em;
}
.indent-title-3{
margin-left: 3em;
}
</style>

## Preface

<div class="indent-title-1">

本篇文章會主要會先認識 Ceph，並介紹 Ceph 如何儲存/讀取資料和管理 Metadata

可以透過點擊以下目錄，選擇想看的內容，跳轉至特定章節

:::warning

:::spoiler {state="open"} 目錄

[TOC]

:::

</div>

# An overview of Ceph

## What is Ceph?

<div class="indent-title-1">

Ceph 是個由軟體定義的分散式儲存系統有以下幾個特點：

1. 在同一平台下可同時提供 Object Storgae、Block Storage 和 file Storage 等三種不同的服務。
2. 強大的擴展能力，能提供 PB 甚至 EB 級的資料。
3. 不受限於任何硬體規格的限制，no vendor lock-in !

Ceph 不像傳統的存儲系統那樣管理區塊 ( block ) 和檔案，而是管理物件（objects），並在此基礎上支援區塊和檔案型存儲。在傳統的檔案型存儲系統中，檔案是透過檔案路徑來定位的；同樣地，在 Ceph 中，物件透過唯一標識符來定位，並儲存在一個 flat addressed space ( 平面地址空間 ) 。物件透過消除元數據操作，提供了無限的擴展性和提升的性能。Ceph 使用一種演算法來動態計算物件應該儲存和檢索的位置。

</div>

## Ceph 如何管理 Metadata

### 認識 Metadata

<div class="indent-title-1">

一個檔案的 Metadata 就是用來 <font color=red>**描述檔案本身的資料，決定了檔案的寫入和讀取位置**</font>。如果在傳統的檔案系統中，Metadata 指的就是檔案的存取權限、檔案擁有者或是檔案大小...等資訊。

</div>

### 傳統集中式管理 Metadata

<div class="indent-title-1">

在系統中有一個節點專門擔任 Metadata 的管理員，所有 Metadata 都儲存在該節點的儲存設備上，所有客戶端對檔案的請求前，都要先對該 Metadata 管理器請求 Metadata。

因為集中式管理實作簡單，一致性維護容易，在一定的操作頻繁內可以提供較滿意的效能。缺點是單一失效的問題，若該伺服器失效，整個系統將無法正常運作。而且，當 Metadata 的操作過於頻繁時，集中的 Metadata 管理會成為整個系統的效能瓶頸。

</div>

### Ceph 管理 Metadata

<div class="indent-title-1">

Ceph 並非遵循傳統的儲存架構來儲存和操作 Metadata，而是引入了一種更新的方式，即 CRUSH 演算法。
> CRUSH is stands for Controlled Replication Under Scalable Hashing.

CRUSH 演算法不需要為每個客戶端請求在 Metadata 表中執行查找，而是<font color=red>**依照需求計算資料應寫入的位置或讀取的位置**</font>。 透過計算 Metadata，無需管理集中的 Metadata 表。 現代電腦的運算速度快得驚人，可以快速執行 CRUSH 查找；此外，較小的運算負載可以分佈在叢集節點上，充分利用分散式儲存的強大功能。 CRUSH 對元資料進行了清潔管理，這是比傳統儲存系統更好的方式。

除此之外，CRUSH 還具有獨特的基礎架構感知特性，它<font color=red>**了解基礎設施各組成部分之間的關係，從系統硬碟、pool、node、機架、電源板、switch 和 data center row，到資料中心機房，甚至更遠，這些都是任何基礎設施的 failure zones ( 故障區域 )**</font>。 CRUSH 以這樣一種方式儲存資料的主副本及其副本，即使故障區中的幾個元件發生故障，資料也將可用。 使用者可以完全控制在 Ceph 的 CRUSH MAP 中為其基礎架構定義這些故障區，這賦予了 Ceph 管理員高效管理自己環境資料的權力。

<font color=red>**CRUSH 可使 Ceph 實現資料的自我管理和自我修復**</font>。 當故障區中的組件發生故障時，CRUSH 會感知哪個組件發生故障，並確定故障對群集的影響。 不需要任何管理幹預，CRUSH 就能透過對因故障而遺失的資料執行復原操作來實現自我管理和自我修復。 CRUSH 從叢集維護的副本中重新產生資料。 在每個時間點，群集都會有一個以上的資料副本，這些副本將分佈在整個群集中。

</div>

### Ceph 設計理念

<div class="indent-title-1">

Ceph 是在一種架構理念的薰陶下成長起來的，這種理念包括以下特徵：
- 每個 component 都必須是可擴展的
- 不能有單點故障
- 解決方案必須以軟體為基礎、開源且適應性強
- Ceph 軟體應在現成的商品硬體上運行
- 一切都必須盡可能實現自我管理

</div>

## Ceph block storage

block storage ( 區塊儲存 ) 是儲存區域網路中使用的一類資料儲存。在這種類型中，資料以 ( blocks ) 區塊的形式儲存在節點上，這就提供了應用程式所需的更大儲存容量，並具有更高的可靠性和效能。 這些作為磁碟區的區塊被映射到作業系統，並受其檔案系統佈局的控制。

Ceph 引入了一個新協定 RBD，現在稱為 Ceph Block Device。 **RBD 為 Client 端提供可靠、分散式且高效能的區塊儲存硬碟**。 RBD 區塊在眾多物件上進行條帶化 ( striped ) 處理，這些物件內部分散在整個 Ceph 叢集中，從而為客戶提供了資料可靠性和效能。 RBD 本身支援 Linux 核心。 換句話說，自過去幾年以來，RBD 驅動程式已與 Linux 核心很好地整合在一起。 幾乎所有的 Linux 作業系統都支援 RBD。 除了可靠性和效能，RBD 還提供了企業級功能，如完整和增量快照、精簡配置、寫入時複製複製等。 RBD 還支援記憶體緩存，從而大大提高了效能。

Ceph RBD 支援最大達 16 exabytes 大小的影像。這些影像可以映射成硬碟，供給裸金屬機器、虛擬機器，或一般主機使用。領先業界的開源虛擬化軟體，如 KVM 和 Zen，完全支援 RBD 並善用其特性供應虛擬機器。其他專有虛擬化軟體，如 VMware 和 Microsoft HyperV，將很快支援。社群中一直有很多工作在進行，以支援這些虛擬化

# Ceph Architecture


### RADOS

<div class="indent-title-1">

是 Ceph Storage Cluster 的基礎，這一層本身就是一個完整的分散式物件儲存系統。Ceph 的高可靠、高可擴展、高效能、高自動化等等特性本質上也都是由這一層所提供的。

在 Ceph 中，所有無論什麼類型的資料都以 **RADOS Object** 的形式存儲。

</div>

### Librados

<div class="indent-title-1">

它是一個 Library，應用程式透過它可以直接跟 RADOS 存取資料。

</div>

### RADOS GW

<div class="indent-title-1">

RADOS GW（簡稱 RGW）提供 Object Storage 的服務，透過這個 RESTful gateway 能夠讓 Application 以 Object 的方式儲存資料

> 一個是RGW中的對象存儲；一個是Ceph 的後端存儲的對象，這兩個需要區分：
第一個對象面向用戶，是用戶接口能訪問到的對象；
第二個對像是ceph 服務端操作的物件
eg：使用RGW接口，存放一個1G的檔案，在使用者介面看到的就是存放了一個物件（1）；而後透過RGW 分片成多個物件（2）後最終儲存到硬碟上；

</div>

### RBD

<div class="indent-title-1">

於 LIBRADOS 之上，RBD ( RADOS Block Device ) 提供區塊設備，主要以虛擬機器為基礎提供虛擬磁碟，可以被映射、格式化，像磁碟一樣掛載到伺服器使用。

</div>

### Ceph FS

<div class="indent-title-1">

於 LIBRADOS 之上，Ceph FS 提供檔案系統，會透過 Metadata Server 來管理檔案的 Metadata

> Ceph Object Storage & Ceph Block Device 不會使用到 Metadata Server。

</div>

## Storing Data

<div class="indent-title-1">

Ceph Storage Cluster 從 Ceph Client 端接收資料，無論是透過 Ceph block storage、Ceph object storage、 Ceph Filesystem 或使用 librados，Ceph Storage Cluster 接收的資料都會儲存為 **RADOS Object**。每個物件都儲存在 Object Storage Device 之上。Ceph OSD Daemons 控制儲存磁碟機上的讀取、寫入和複製操作。

> “Object Storage Device”, which refers to a physical or logical storage unit (for example: LUN)


Ceph OSD 背景程序將資料儲存為在平面的 Namespace 中的物件。 這意味著物件不儲存在某個目錄底下。 一個物件有一個識別符、二進位資料和由 key/value 組成的 Metadata。

Ceph Client 端決定物件的 Metadata。 例如，CephFS 使用 metadata 來儲存檔案屬性，例如檔案擁有者、建立日期和最後修改日期。


為了避免使用集中式的方式管理檔案的 Metadata ，Ceph 使用了一種叫做 CRUSH 演算法來完成這點。

The default object size is 4 MB

</div>

## CRUSH 演算法

<div class="indent-title-1">

讓 Client 端和 Ceph OSD Daemon 可以計算出要把 Object 放在哪一台 Node 的哪一顆硬碟上，Client 端可以自行決定要如何處理資料或從哪裡取得。

更準確的定義 :

只要給定整個 Ceph Storage Cluster 的結構資訊和 CRUSH Map，Client 端就可以計算出 Object 要到哪個儲存節點來儲存或讀取資料。

整個 Ceph Storage Cluster 的結構資訊在 Ceph 中的術語，被稱為 Cluster map。

</div>

## Ceph 正常 IO 流程


1. client 連接上 monitor，取得 Cluster map 資訊。
1. client 讀寫 io 根據 crshmap 演算法請求對應的主osd資料節點。
1. 主osd資料節點同時寫入另外兩個副本節點資料。
1. 等待主節點以及另外兩個副本節點寫完資料狀態。
1. 主節點及副本節點寫入狀態都成功後，回傳給client，io寫入完成。

## Ceph RBD IO 流程

<div class="indent-title-1">


1. Client 端建立一個 pool，需要為這個 pool 指定 pg 的數量。
2. 建立 pool/image rbd 設備進行掛載。
3. 使用者寫入的資料進行切塊，每個區塊的大小預設為 4MB。
4. 跟將每個 object 透過 pg 進行副本位置的分配。
5. pg 根據 CRUSH 演算法會找 3 個 osd，把這個 object 分別保存在這三個 osd 上。

</div>

### 實作

<div class="indent-title-1">

## list objects in CPA pool
$ rados -p CPA ls

## 查看 Object 的大小
$ rados -p CPA stat rbd_data.3f9c67cf08a29.00000000000000de

## List rbd images.
$ rbd ls CPA

## 查看 RBD Image 的詳細資訊
$ rbd info CPA/vm-100-disk-0

## 算 vm-100-disk-0 被切成幾個 object
$ rados -p CPA ls | grep 'rbd_data.3fe346edd0fa9*' | wc -l

</div>

### 12/09

$ ceph fs ls
$ ceph fs set testfs down true
$ ceph fs status
$ ceph fs rm testfs --yes-i-really-mean-it

$ ceph osd pool ls
$ ceph osd pool rm testfs_data testfs_data --yes-i-really-really-mean-it
$ ceph osd pool rm testfs_metadata testfs_metadata --yes-i-really-really-mean-it