1、Ceph 的組成
基本的 Ceph 包含 Monitor 節點與 OSD 節點。Monitor 節點主要的職責在於收集並記錄當前的各種叢集資訊；OSD 節點則負責儲存物件。另外還有 MDS 節點，在一般的 Ceph 環境中用不到，只有當需要使用 Ceph 去提供 File System 服務時，才會需要 MDS 節點。
上圖為官方網站中可以看到的 Ceph 的架構圖。Ceph 本身的核心稱為 RADOS（Reliable, Autonomic Distributed Object Store），由名稱可以看出 Ceph 核心是一個 Object Storage。在 Ceph 的核心之上，藉由額外安裝的三種附加元件，可以讓 Ceph 提供更多種類的介面，即 RadosGW（提供 RESTful 介面，同時相容於 S3、Swift 等常見的 RESTful 儲存介面）、RBD（提供 Block Device 介面）以及 CephFS（提供 File System 介面）。而外部的應用程式想要操作 Ceph 時，除了透過 RadosGW、RBD 或 CephFS 介面操作之外，也可以直接透過 LibRados 函式庫，可以跨過上層介面，直接跟底層的 RADOS 溝通。
2、Ceph 如何儲存資料？
在 Ceph 的架構中，每個 OSD 節點負責存放使用者上傳的物件，而這些物件實際上被存放在被稱為 PG 的單元中。PG 是 Ceph 實際存放資料的單元，每個 PG 都會隸屬於一個 Pool，而一個 Pool 可以擁有很多個 PG。當使用者要求寫入一個物件時，Ceph 會依照使用者要求寫入的 Pool 以及物件的相關資訊，透過 CRUSH 演算法決定要將物件放在哪一個 PG，然後讓使用者直接跟擁有該 PG 的 OSD 節點進行傳輸。
Pool 可以設定資料的複製量（Data Replication），以確保當某個 OSD 節點或 OSD Daemon 故障時，使用者的資料皆能被恢復。物件在寫入至 PG 內後，PG 會依照所屬 Pool 設定的複製數目，將物件複製到其他位於不同 OSD 節點的 PG 上。以上圖為例，Pool - A 設定的複製數目為 3，因此粉紅色的物件會被複製到三台 OSD 節點上。基於複製的概念，我們也可以推導出若有一個 Pool 設定的複製數目為 3，則同時有超過三個 OSD Daemon 發生永久性故障時，有可能導致部分資料永遠無法恢復，因為若某個物件的所有複製剛好都落在這三個 OSD Daemon，就無法救援資料了。
3、Ceph 如何處理 OSD 損毀？
建議參閱 解析Ceph: 恢复与数据一致性
4、如何部署 Ceph？
請參閱後續的文章：
分散式儲存系統 Ceph（二）：利用 ceph-deploy 部署 Ceph 叢集
分散式儲存系統 Ceph（三）：使用 inkScope 觀察 Ceph 狀態
沒有留言:
張貼留言