歡迎光臨
每天分享高質量文章

Ceph儲存後端ObjectStore架構和技術演進

      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”“掃一掃”二維碼關註公眾號,點擊原文鏈接閱讀更多內容

求知若渴, 虛心若愚

赞(0)

分享創造快樂