【4.分佈式存儲】-ceph

http://docs.ceph.org.cn/archi...
擴展性極強的分佈式對象存儲（swift python寫的），塊存儲，文件存儲（hdfs和hadoop的結合緊密性能居然更好，NN節點PB，cephEB，java寫的）。
特色：

• 無路由存儲CRUSH，造就極高擴展性；自動failover,rebalance等
• 日誌文件系統（原子+順序批量）緩存分級，原來默認filestore,日誌SSD+無內核緩存+數據fs的正常存儲。發展中的Bluestore，ROCKSDB+裸設備，全完無內核緩存，rocksdb還能夠優化用NVRAM斷電不影響的RAM。
• 三副本或EC
• 帶條化

組件

客戶端：{塊，對象，文件}，計算路由，與監視器認證和取配置
監視器：認證密鑰下發，元數據一致性保證，集羣自身可用性（paxos），輕量（數據少，OSD集羣相互上報，對它依賴少，6s一次，20s*3個斷定失效）
存儲集羣OSDs：上報狀態，與副本集通訊複製數據一致性，主要計算髮現副本（序號靠前是主）
元數據：包含集羣狀態沒有路由看下官網吧

流程

讀寫過程

與monitor認證，獲取集羣配置，
計算pgid(hash，提早規定好pgid,不能改了)
發送到osd機器上
osd副本之間同步返回ack(能夠配置SSD緩存，分別ACK確認，第一次返回第二次到磁盤後刪除)

帶條化

CRUSH

File -> object 映射
Object -> PG 映射 hash(oid) & mask -> pgid。Ceph也推薦PG總數應該爲OSD總數的數百倍，以保證有足夠數量的PG可供映射。2的冪
PG -> OSD 映射

failover、reblance

新OSD，與monitor通訊。Monitor將其加入cluster map，並設置爲up且out狀態，再將最新版本的cluster map發給這個新OSD。
收到monitor發來的cluster map以後，這個新OSD計算出本身所承載的PG，以及和本身承載同一個PG的其餘OSD。而後，新OSD將與這些OSD取得聯繫。若是這個PG目前處於降級狀態（即承載該PG的OSD個數少於正常值，如正常應該是3個，此時只有2個或1個。這種狀況一般是OSD故障所致），則其餘OSD將把這個PG內的全部對象和元數據複製給新OSD。數據複製完成後，新OSD被置爲up且in狀態。而cluster map內容也將據此更新。這事實上是一個自動化的failure recovery過程。固然，即使沒有新的OSD加入，降級的PG也將計算出其餘OSD實現failure recovery。

若是該PG目前一切正常，則這個新OSD將替換掉現有OSD中的一個（PG內將從新選出Primary OSD），並承擔其數據。在數據複製完成後，新OSD被置爲up且in狀態，而被替換的OSD將退出該PG（但狀態一般仍然爲up且in，由於還要承載其餘PG）。而cluster map內容也將據此更新。這事實上是一個自動化的數據re-balancing過程。

若是一個OSD發現和本身共同承載一個PG的另外一個OSD沒法聯通，則會將這一狀況上報monitor。此外，若是一個OSD deamon發現自身工做狀態異常，也將把異常狀況主動上報給monitor。在上述狀況下，monitor將把出現問題的OSD的狀態設爲down且in。若是超過某一預訂時間期限，該OSD仍然沒法恢復正常，則其狀態將被設置爲down且out。反之，若是該OSD可以恢復正常，則其狀態會恢復爲up且in。在上述這些狀態變化發生以後，monitor都將更新cluster map並進行擴散。這事實上是自動化的failure detection過程。

即使由數千個甚至更多OSD組成，cluster map的數據結構大小也並不驚人。同時，cluster map的狀態更新並不會頻繁發生。即使如此，Ceph依然對cluster map信息的擴散機制進行了優化，以便減輕相關計算和通訊壓力。

首先，cluster map信息是以增量形式擴散的。若是任意一次通訊的雙方發現其epoch不一致，則版本更新的一方將把兩者所擁有的cluster map的差別發送給另一方。
其次，cluster map信息是以異步且lazy的形式擴散的。也即，monitor並不會在每一次cluster map版本更新後都將新版本廣播至全體OSD，而是在有OSD向本身上報信息時，將更新回覆給對方。相似的，各個OSD也是在和其餘OSD通訊時，將更新發送給版本低於本身的對方。
基於上述機制，Ceph避免了因爲cluster map版本更新而引發的廣播風暴。這雖然是一種異步且lazy的機制，但根據Sage論文中的結論，對於一個由n個OSD組成的Ceph集羣，任何一次版本更新可以在O(log(n))時間複雜度內擴散到集羣中的任何一個OSD上。
若是一個client和它要訪問的PG內部的各個OSD看到的cluster map狀態一致，則訪問操做就能夠正確進行。而若是這個client或者PG中的某個OSD和其餘幾方的cluster map不一致，則根據Ceph的機制設計，這幾方將首先同步cluster map至最新狀態，並進行必要的數據re-balancing操做，而後便可繼續正常訪問。

數據格式

底層都是對象：ID,二進制數據，metadata（隨意定義）

OSD的日誌與bluestore

日誌

OSD使用日誌的緣由有兩個：

• 速度： 日誌使得 OSD 能夠快速地提交小塊數據的寫入， Ceph 把小片、隨機 IO 依次寫入日誌，這樣，後端文件系統就有可能歸併寫入動做，並最終提高併發承載力。所以，使用 OSD 日誌能展示出優秀的突發寫性能，實際上數據尚未寫入 OSD ，由於文件系統把它們捕捉到了日誌
• 一致性：OSD須要一個能保證原子化複合操做的文件系統接口。 OSD 把一個操做的描述寫入日誌，並把操做應用到文件系統。這確保了對象（例如歸置組元數據）的原子更新。每隔一段時間（由filestore max sync interval 和 filestore min sync interval控制 ）， OSD 會中止寫入，把日誌同步到文件系統，這樣容許 OSD 修整日誌裏的操做並重用空間。若失敗， OSD 從上個同步點開始重放日誌。日誌的原子性表如今，它不使用操做系統的文件緩存（基於內存），避免斷電丟數據的問題

bluestore

直接管理裸設備，拋棄了ext4/xfs等本地文件系統，BlockDevice實如今用戶態下使用linux aio直接對裸設備進行I/O操做。
Onode是常駐內存的數據結構，持久化的時候會以kv的形式存到rocksdb裏。rocksdb自己是基於文件系統的，封裝實現了一個小的文件系統BlueFS，在系統啓動mount這個文件系統的時候將全部的元數據都加載到內存中，BluesFS的數據和日誌文件都經過BlockDevice保存到裸設備上
https://www.sysnote.org/2016/...
使用HDD做爲數據盤
使用SSD做爲RockDB元數據盤
使用NVRAM做爲RockDB WAL
參考資料：
https://blog.gmem.cc/ceph-stu...
https://www.siguadantang.com/...