知識星球
Ceph是分散式和強一致性的軟體定義儲存產品，隨著越來越多的企業和組織不斷加入，Ceph儲存系統穩定性、可靠性和易管理性得到了很大的提升，在版本演進和迭代中，Ceph儲存的企業特性也得到了完善。如CephFS、iSCSI協議、InfiniBand網路等特性，但今天筆者將帶領大家深入分析下Ceph最新後端儲存BlueStore的架構和ObjectStore歷史技術演進，因為儲存後端的架構在一定程度上決定Ceph儲存系統的效能。SUSE也是在最新Enterprise Storage 5版本中率先支援最新的BlueStore後端儲存技術。
BlueStore是Ceph儲存後端ObjectStore的最新實現。在Ceph系統中，資料首先透過Hash演演算法分佈到每個節點OSD上，最終由ObjectStore寫到磁碟上實現資料儲存和持久化。那麼，首先來看看ObjectStore架構。
ObjectStore架構介紹
Ceph後端支援多種儲存引擎，這些儲存後端模組是以外掛式的方式被管理，目前支援的實現方式包括Filestore(預設儲存後端)，KeyValue Store、Memstore、NewStore和最新的Bluestore。
從架構上來看，ObjectStore封裝了下層儲存引擎的所有IO操作，並向上層提供物件(Object)、事務(Transaction)語意介面。在這裡，MemStore是基於記憶體的實現儲存介面功能；KeyValue Store主要基於KV資料庫(如LevelDB，RocksDB等)實現介面功能。
一直以來，FileStore是Ceph目前預設的ObjectStore後端儲存引擎(仍然是其他Ceph儲存的預設後端)，FileStore基於Journal機制實現了事務處理能力，除了支援事務特性(consistency、atomic等)以外，Journal還可將多個小IO寫合併為順序寫Journal來提升系統效能。
ObjectStore介面主要包括三個部分，第一部分是Object的讀寫操作，類似於POSIX的部分介面；第二部分是Object的屬性(xattr)讀寫操作，這類操作是KV操作，它與某一個Object關聯；第三部分是關聯Object的KV操作(在Ceph中稱為omap)。
ObjectStore後端儲存引擎之FileStore
FileStore是利用檔案系統的Posix介面實現ObjectStore API。每個Object在FileStore層會被看成是一個檔案，Object的屬性(xattr)會利用檔案的xattr屬性進行存取，由於有些檔案系統(如ext4)對xattr的長度有限制，因此，在FileStore中，超出長度限制的Metadata會被儲存在DBObjectMap裡。而Object的KV關係則直接利用DBObjectMap功能實現。
但是FileStore存在一些問題，例如Journal機制使一次寫請求在OSD端往下寫時，變為兩次寫操作(同步寫Journal，非同步寫入Object)；當然，可以透過SSD實現Journal可緩解Journal和object寫操作的效能影響；寫入的每個Object都對應OSD本地檔案系統的一個物理檔案，對於大量小Object儲存場景來說，OSD端無法快取本地所有檔案的元資料，這使讀寫操作可能需要多次本地IO操作，系統效能差等。
ObjectStore後端儲存引擎之NewStore
為瞭解決上述FileStore的問題，Ceph引入了新的儲存引擎NewStore(又被稱為KeyFile Store)，其關鍵結構如下圖所示：
NewStore解耦Object與本地物理檔案間的一一對應關係，透過索引結構(上圖中ONode)在Object和本地物理檔案建立對映關係，並使用KV資料庫儲存索引資料；在保證事務特性的同時，對於Object的操作無需Journal支援；在KV資料庫上層建立Onode資料cache以加速讀取操作；單個Object可以有多個fragement檔案，多個Object也可共存於一個fragement檔案，更加靈活。
ObjectStore後端儲存引擎之BlueStore
NewStore使用RocksDB儲存Ceph日誌，同時Ceph的真正資料物件儲存在檔案系統中。如今有了BlueStore技術，資料物件可以無需任何檔案系統的介面支援，而是直操作儲存在物理磁碟裝置上的資料。
BlueStore初衷就是為了減少寫放大，並針對SSD做最佳化，直接管理裸盤(物理磁碟裝置)，從理論上來講，進一步規避瞭如ext4、xfs等檔案系統部分的開銷，BlueStore是一個全新的 OSD儲存後端，透過塊裝置提升儲存效能。Bluestore整體架構如下。
BlueStore直接管理裸裝置，拋棄了本地檔案系統，BlockDevice實現在使用者態下直接對裸裝置進行I/O操作。既然是直接管理裸裝置就必然需要進行裸裝置的空間管理，對應的就是Allocator，目前支援Stupid Allocator和Bitmap Allocator兩種分配器。
相關的元資料以KV的形式儲存到KV資料庫裡，預設使用的是RocksDB，RocksDB本身雖然是基於檔案系統，不能直接操作裸裝置，但是RocksDB可將系統相關的處理抽象成Env，使用者可用實現相應的介面來操作。
RocksDB預設的Env是PosixEnv，直接對接本地檔案系統。為此Bluestore實現了一個BlueRocksEnv來為RocksDB提供底層系統的封裝，實現了一個小的檔案系統BlueFS對接BlueRocksEnv，在系統啟動掛載這個檔案系統的時候，將所有的元資料都載入到記憶體中，BluesFS的資料和日誌檔案都透過BlockDevice儲存到裸裝置上，BlueFS和BlueStore可以共享裸裝置，也可以分別指定不同的裝置。
當BlueFS和BlueStore共享裝置時，裸裝置通常被分為兩部分:
-
裝置的一部分為BlueFS的小分割槽，它實現了RocksDB所需的類似檔案系統的功能。
-
裝置的其餘部分通常是佔據裝置其餘部分的大分割槽。它由BlueStore直接管理，包含所有實際資料。
在Filestore儲存引擎裡，物件的表現形式是對應到檔案系統裡的檔案，預設4MB大小的檔案，但是在目前最新的ObjectStore實現——Bluestore裡，已經沒有傳統的檔案系統，而是自己管理裸盤，要求管理物件Onode需要常駐記憶體的資料結構中，持久化的時候會以KV的形式存到RocksDB裡。
總結一下，從SUSE Enterprise storage 5儲存版本開始，BlueStore成為Ceph的一個新的儲存後端，它的效能優於FileStore，並提供完整的資料檢驗和和內建壓縮能力。
FileStore將資料儲存到與Posix相容的檔案系統(例如Btrfs、XFS、Ext4)。在Ceph後端使用傳統的Linux檔案系統儘管提供了一些好處，但也有代價，如效能、物件屬性與磁碟本地檔案系統屬性匹配存在限制等。
然而，NewStore儲存後端技術解耦Object與本地物理檔案間的對應關係，透過KV資料庫、索引技術最佳化日誌操作。
BlueStore可使資料物件無需任何檔案系統的介面，就可以直接儲存在物理塊裝置上，所以，BlueStore可以極大的提升Ceph儲存系統效能。
推薦閱讀：
溫馨提示：
請搜尋“ICT_Architect”或“掃一掃”二維碼關註公眾號，點選原文連結閱讀更多內容。
求知若渴, 虛心若愚
