Ceph的結構
在【Ceph淺析筆記】Ceph是什么.md里面我們介紹了Ceph的基本思想。下面我們先來介紹一下Ceph的基本結構。
-
基礎存儲系統RADOS
最底層是數據真正存放的地方，物理上由大量的節點所構成，然后在上面加了一個中間層，可以實現Ceph的可靠性、自動化、可擴展等特性，所有我們將之稱為RADOS(Reliable,Autonomic,Distributed Object Store)
-
librados
然后我們希望能對客戶透明，也就是用戶不需要關心底層如何實現的，只需要直接在Ceph上進行開發。所以又加了一堆庫函數librados。這些庫函數與應用一般來說在同一臺節點上，所以也被稱為本地API
-
Restful API
由于Ceph是基于C++開發的，那么librados提供的結構也是C或者C++的。
而且我們也希望Ceph能于Amazon S3和Swift這些分布式系統所兼容，所以可以再在上面加一個中間層，比如RADOS GW, RDD,Ceph FS。
比如說RADOS GW，本質就是一個網關，也就是可以提供協議的轉換，這樣對外就可以兼容S3和Swift的了。
RBD，全稱是Reliable Block Device，也就是一個塊設備接口，這樣上層的操作系統看到的其實就是裸硬盤。
有了塊存儲接口，當然也有文件系統接口，Ceph FS就是一個POSIX兼容的分布式文件系統。
那么librados API和RADOS GW有啥區別呢？
抽象程度不一樣，也就是對應的場景不同而已。librados更偏底層，允許開發者對存儲的對象的狀態進行提取，這樣用戶可以進行深度定制。
而RADOS GW屏蔽了很多細節，它主要是針對于應用開發者的，所以有用戶賬戶、存儲數據的容器、數據對象的概念，適合于常見的WEb對象存儲應用開發。
RADOS 的邏輯結構
上一章主要介紹了Ceph的分層架構，那么里面最重要最底層的RADOS是我們接下來介紹的重點。
首先我們來介紹一下RADOS里面的幾個角色
-
Clients
顧名思義，就是客戶端，它可以是一個程序，也可能是命令行，反正用戶必須通過Clients程序與存儲節點打交道。
-
OSD(對象存儲設備)
我們把存儲數據的節點叫OSD，實際上OSD是一臺安裝了操作系統和文件系統的Server，一般來說，一個OSD至少包含了單核CPU、內存、一塊硬盤、一張網卡等。但是事實上一臺這么小的Server幾乎找不到，所以我們可以把若干OSD部署在更大的服務器上。
每個OSD都有一個deamon，它的作用是介紹Client的訪問連接，與monitor以及其他的OSD通信，與其他的OSD工程進行數據存儲維護等。也就是說deamon完成了OSD的邏輯功能
-
monitor：
主要用來進行系統狀態檢測和維護。OSD會與monitor交互節點狀態信息，形成全局的元數據，也即Cluster map。使用這個Cluter map就可以得到數據存放的地點。
對于傳統的分布式存儲，一般來說會有一個單獨的元數據服務器，存放數據塊與節點的映射關系，缺點是性能受限于此元數據服務器。而RADOS系統中，Client與OSD以及monitor交互獲得Cluster Map，并存放于本地，然后可以在本地進行計算，獲得對象存儲位置。很顯然避開了元數據服務器，不需要再進行查表操作了。
但是Cluster Map不是一成不變的，當OSD出現故障或者說有新的OSD加入的時候，Cluster Map應該進行更新，但是這種事件的頻率遠遠低于Client對數據的訪問頻率。
