Ceph
每個Ceph叢集必定具備兩種角色的元件，一個是Monitor（監視器），另一個是OSD

Monitor：主要負責叢集內的結點生命週期管理，資料分佈策略計算並維護叢集的成員和狀態等工作，Monitor通過實現Paxos演算法來提供強一致性的選舉策略。
OSD：主要負責儲存盤的生命週期管理，每一個DISK、SSD或者RAID
Group，任何一個物理儲存裝置都應成為一個OSD，其實現了物件資料的儲存和查詢，並且負責向該物件的複製結點分發和恢復，也是客戶端IO的服務者，保證資料的完整性、高可靠性和回覆一致性。

若干個Monitor和OSD通過部署在伺服器互聯形成一個RADOS叢集。

Reliable Autonomous Distributed Objectstore

LibRADOS：封裝了面向RADOS叢集的操作，通過Ceph原生協議使得任意客戶端可以直接訪問資料儲存結點。值得一提的是RADOS支援外掛式架構，每個OSD允許支援動態連結庫的載入，這些動態連結庫通過註冊操作介面可用作為OSD提供給LibRADOS操作的一部分
RBD(RADOS BlockDevice)：塊裝置作為最通用的儲存方式，可以提供給作業系統或者大型系統軟體作為儲存介質，Ceph通過將多個物件聚合來提供簡單的塊介面訪問，同時利用資料切片能力使得物件分佈在不同的OSD中，客戶端可以併發地從不同的OSD獲得資料來得到高效能儲存體驗。與企業級塊儲存累死，RBD同樣提供了快照、克隆、精簡配置、增量備份等高階儲存服務。
RADOS Object Storage

：指通過AWS S3/Openstack Swift這類HTTP RESTful物件儲存協議提供塊儲存服務。是目前Ceph用來支撐大規模檔案儲存服務、備份歸檔場景的主要介面，其通過配合ErauseCode能夠獲得較高的可用儲存空間和更高的資料可靠性。
CephFS：提供共享檔案系統服務，相容嚴格Posix語意實現傳統檔案服務。CephFS提供了一個額外的元件稱為MDS（Meta Data Server），MDS本身並不會儲存維護元資料，而是將所有元資料也像資料一樣儲存到RADOS叢集中。

RADOS資料分佈計算
根據Ceph致力於提供PB級的叢集儲存能力，並且提供自動故障恢復、方便的擴容和縮容能力，這些能力在典型的分散式儲存系統要麼採用元資料伺服器中心化提供，要麼採用一致性雜湊進行完全無中心化處理，但後者缺少叢集一致性檢視，對於資料遷移和擴容會存在非常複雜並且很難保證強一致的痛點，而前者在中心化叢集檢視後需要避免單點故障和元資料“瓶頸”的問題。
而Ceph要提供更自由和更強大的叢集自動故障處理和恢復能力，這使得叢集的一致性檢視是不可或缺的，但是為了避免叢集“震盪”時元資料服務存在“瓶頸”問題，維護儘量少的叢集元資料成為最重要的問題。因此Monitor作為Ceph的叢集元資料服務維護了整個叢集的檢視資訊，它包括了6個Map，分別是MONMap,OSDMap,PGMap,LogMap,AuthMap,MDSMap，其中PGMap和OSDMap是最重要的兩張Map。

Ceph採用Crush演算法進行資料位置的計算。Crush可以理解為一個帶“引數”的雜湊演算法，這個演算法並不會簡單地根據輸入的KEY通過數學運算來一致地輸出，而是會接納更多的引數來獲得更加只能的雜湊效果。Crush還支援設定OSD的權重和親和度，權重影響了OSD資料量的大小，而親和度可以決定OSD所需要承擔的主副本的可能性。

在Ceph裡，OSDMap維護了叢集的所有資料節點資訊，所有OSD節點的改變如節點的加入和退出，節點權重的變化都會反映到OSDMap。OSDMap不僅會被Monitor掌握，而且所有OSD服務和客戶端也會從Monitor得到這張表，因此實際上我們需要處理所有參與Ceph資料流服務（包括OSD，Monitor和Client）的OSDMap持有的情況。每次叢集結點發生變化時，顯然不能讓所有服務都去更新它的OSDMap來獲取權威的資料位置，這樣的大規模的震盪很容易使得叢集崩潰。
這時候Ceph通過複雜的OSDMap灰度釋出機制來解決這個問題。在叢集的執行狀態中，每個服務可能會攜帶多個版本的OSDMap，當Monitor所掌握的權威OSDMap由於叢集節點變化而發生變化時，它並不會傳送OSDMap給所有“Client”，而是主動推送給需要了解到變化的“Client”，如一個新的OSD加入會導致一部分資料遷移，那麼這些資料的OSD會得到通知。除此以外，Monitor也會隨機地挑選一些OSD傳送OSDMap。這個時候每個OSD儲存自己OSDMap，在其它OSD需要它的OSDMap資訊時，通過版本比較來確定是否需要向其推送OSDMap。Ceph通過管理多個版本的OSDMap來避免叢集狀態的同步，這使得Ceph絲毫不會畏懼在上千個OSD節點和大量客戶端規模下結點變更導致叢集可能出現的狀態同步。

RADOS資料管理
RADOS中的物件可以理解為由物件名、屬性（類似Posix檔案的擴充套件屬性）、資料和擴充套件資料（鍵值對）組成的一個實體。物件是Ceph資料讀寫的基本單位，對於單個物件的操作可以有多個並且保證事務性，而物件與物件之間並不存在任何關聯，因此不能實現跨物件的事務。
面對大規模叢集中數以億計的物件，Ceph採用PG來對資料進行管理。PG實際就是一堆物件的集合，在控制平面，比如叢集的資料遷移、控制指令下發、資料統計都是將PG作為最小粒度，物件在控制平面是不可見的。而在資料平面，所有客戶端的資料讀寫都是對PG透明的，而實際上在底層發生物件到PG的對映，然後計算PG的所屬OSD再訪問。但是PG這個概念在資料平面是不存在的。

● 在叢集視角只需要記錄並跟蹤PG位置和狀態而不是對每個物件進行關注
● 當儲存超過數百萬物件時，物件級的管理將變得不切實際，OSD實際上是將每個PG視為獨立的“機器人”，每個PG的主副本分別在不同的OSD會進行P2P互聯溝通並自治
● 當叢集內節點發生變化時，通過PG隔離物件使得大部分PG在資料遷移發生時保持不變
● Crush可以針對PG這個級別進行優化計算

在一般的叢集內，為了對一定業務資料之間進行隔離，又或者地下儲存裝置存在巨大差異時，統一的名稱空間無法滿足使用者的需求。因此Pool起到了邏輯隔離的作用，當然實際上Pool和Crush物理拓撲配合時也能達到物理隔離的作用。

Ceph的Pool具有一下獨立的特點：
● 單獨的許可權體系
● 副本數獨立
● PG數目
● Crush規則
● 副本位置策略
● 資料儲存方式
● 分割槽和效能分層

簡單而言，Ceph叢集內部幾乎所有的重要資料策略都是與Pool相關聯而不是叢集，因此Pool在複雜的使用者場景和叢集中起到了關鍵的邏輯隔離和儲存優化放置的作用。

看了好幾天的書和資料，並且動手實踐了很多，這個時候對Ceph的框架終於能理解了