最近部署ceph，硬是在工作之外擠時間研究了下ceph的相關的內部的東西，下面主要是通過看別人的文章以及自己工作用到的的知識總結而成。這可以算是ceph的筆記吧。
ceph使用C++語言開發,主要是考慮到性能因素。
Ceph是一種爲優秀的性能,可靠性和可擴展性而設計的統一的、分佈式的存儲系統。
Ceph提供對象存儲（對應openstack裏的Swift）、塊存儲和文件系統存儲三種功能。
ceph分佈式實現了真正無中心結構。
設計思路：1、發揮存儲設備的計算能力。2、去除所有的中心點
傳統的分佈式存儲系統是以查表的數據存儲方式，每個數據對應着一個地址，對數據操作就去找他的地址。
標準說法就是，引入專用的服務器節點，在其中存儲維護數據存儲空間映射關係的數據結構。用戶訪問數據，首先連接此服務器查找數據實際存儲位置，再連接對應節點進行後續操作。這種存儲方式會導致操作延遲，性能瓶頸，單點故障。
ceph是基於計算的數據存儲方式。即任何一個ceph存儲系統的客戶端程序，使用不定期更新的少量本地元數據，簡單計算，就可得到一個數據的ID決定其存儲位置。
Ceph存儲系統的邏輯層次結構4層：
1、基礎存儲系統RADOS（Reliable,Autonomic,Distributed objectStore,即可靠的，自動化的，分佈式的對象存儲系統）。採用C++開發。存儲ceph系統中的用戶數據。RADOS由很多存儲設備節點組成。
2、基礎庫librados，是對RADOS抽象和封裝，並向上提供API，以便直接基於RADOS進行應用開發。實現的API是隻針對對象存儲系統。不是針對整個ceph。物理上，librados和基於其上開發的應用是在同一臺機器，所以也叫本地API。應用調用本地API，再由API通過socket和RADOS集羣中的節點通信完成各種操作。
3、高層應用接口。包括三個部分：RADOS GW(RADOS Gateway)、RBD(Reliable Block Device)和ceph FS（ceph file system）。這是librados庫的基礎上提供抽象層次更高，更便於應用或客戶端使用的上層接口。 RADOS GW提供與amazon S3 和Swift 兼容的 restful api gateway，供相應對象存儲應用開發使用。 RBD提供標準塊設備接口，用於虛擬化場景下爲虛擬機創建volume。 ceph FS是一個posix（可移植操作系統接口）兼容的分佈式文件系統。
4、應用層。不同場景下對於ceph各個應用接口的各種應用。如基於RBD的雲硬盤。
swift 提供的API功能包括：
用戶管理操作：用戶認證、獲取賬戶信息、列出容器列表等；
容器管理操作：創建/刪除容器、讀取容器信息、列出容器內對象列表等；
對象管理操作：對象的寫入、讀取、複製、更新、刪除、訪問許可設置、元數據讀取或更新等。
Swift選擇了Python語言進行開發。
swift不涉及存儲系統的底層硬件或系統信息，針對對賬戶和數據的管理感興趣的人。librados針對對系統有深刻理解，並對功能定製擴展和性能深度優化有需求的人。基於librados開發適合基於ceph共有存儲系統開發後臺數據管理，處理應用。RADOS GW適合基於web的對象存儲應用開發，如公有云上的對象存儲服務。
RADOS的系統邏輯結構如下圖所示：
過程：新osd上線，配置信息與monitor通信，monitor將其加入到cluster map，設置up且out狀態（osd正常，未承載PG）。將最新版cluster map 發給新osd，收到monitor發的cluster map後，新osd計算所承載的PG，和自己承載同一個PG的其他osd。新的osd和其他osd聯繫，若新osd處於degrade，（即承載的osd個數少於正常值，正常是三個）。則其他osd將把這個PG內的所有對象和元數據複製給新osd。複製結束，新osd被置爲up且in狀態。而cluster map內容頁更新。事實是一個自動化的failure recovery。（這裏osd和monitor之間的cluster map有點類似ospf協議裏的動態對象狀態庫構建過程）
Ceph對cluster map 信息擴散機制的優化：cluster map（全局系統狀態記錄數據結構）信息以增量形式擴散，達到cluster map的一致；以異步且lazy擴散。
總結：ceph是基於cluster map機制，由monitor，osd和client共同配合完成集羣狀態的維護和數據訪問的。
RADOS集羣
由兩種節點組成:OSD(數據存儲和維護功能)：object storage device。Monitor（系統狀態檢測盒維護）。Osd和monitor之間相互傳遞狀態信息，得出全局系統狀態記錄數據結構，即cluster map，這個數據結構和rados的特定算法配合，計算數據的ID得出存儲位置，與對應的OSD通信，完成數據各種操作。
Ceph系統中的尋址流程
File：用戶直接操作的對象（文件）。Object：RADOS看到的對象。最大的size由RADOS限定，爲了方便實現底層存儲的組織和管理。當file很大，需要切分成統一大小的object(最後一個object除外)。PG（placement Group），對object存儲進行組織和位置映射。PG和object是一對多映射，PG和OSD是多對多關係。
File和object映射：將用戶操作的file切分變爲RADOS可處理的object。每一個object獲得唯一oid即object id。Ino爲file ID，ono爲切分的序號，oid即爲序號兩者連接而成。
Object和PG映射：hash(oid)&mask->pgid。哈希算法。
PG->osd映射：將作爲object邏輯組織單元的PG映射到數據實際存儲單元osd。CRUSH（pgid）->(osd1,osd2，…osdn),n個osd存儲維護一個對應的PG中的object（osd一般爲3個）。Deamon負責執行映射到本地的object在本地文件系統中的存儲，訪問，元數據維護等操作。Crush算法結果可變，受系統狀態和存儲策略影響。
引入PG好處：1、實現了object和osd之間動態映射，爲ceph的可靠性，自動化等特性實現留下空間。2、簡化了數據存儲組織，大大降低了系統的維護管理開銷。
OSD使用cluster map進行數據的維護，而client使用clustermap進行數據的尋址。
Up且out，該osd正常運行，爲承載pg。down且in，osd故障，不能承載osd。
OSD使用cluster map進行數據的維護，而client使用clustermap進行數據的尋址。
對於一個IaaS系統，涉及到存儲的部分主要是塊存儲服務模塊、對象存儲服務模塊、鏡像管理模塊和計算服務模塊。具體針對OpenStack而言，則分別對應爲其中的Cinder、Swift、Glance和Nova四個項目
Swift和ceph的選擇：
如果需要一個純粹的對象存儲系統，則選擇Swift；
如果需要一個純粹的塊存儲系統，則只能選擇Ceph；
如果是一個小規模的、希望控制系統複雜度的OpenStack部署方案，則選擇Ceph；
如果是一個規模較大的系統，塊存儲和對象存儲分別有較大的業務需求，則可以考慮將二者分離，分別採用Ceph和Swift。
常用到的單詞：
Deamon：守護進程。
最後感謝以下介紹ceph的文章，講的很詳細：
Ceph淺析：http://www.infoq.com/cn/news/2014/01/ceph-overview
官網：http://ceph.com/
