Ceph中存儲引擎實現FileStore的示例分析

這篇文章給大家分享的是有關Ceph中存儲引擎實現FileStore的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

Ceph作為一個高可用和強一致性的軟件定義存儲實現，去使用它非常重要的就是了解其內部的IO路徑和存儲實現。

ObjectStore

ObjectStore是Ceph OSD中最重要的概念之一，它封裝了所有對底層存儲的IO操作。從上圖中可以看到所有IO請求在Clieng端發出，在Message層統一解析后會被OSD層分發到各個PG，每個PG都擁有一個隊列，一個線程池會對每個隊列進行處理。

當一個在PG隊列里的IO被提出后，該IO請求會被根據類型和相關附帶參數進行處理。如果是讀請求會通過ObjectStore提供的API獲得相應的內容，如果是寫請求也會利用ObjectStore提供的事務API將所有寫操作組合成一個原子事務提交給ObjectStore。ObjectStore通過接口對上層提供不同的隔離級別，目前PG層只采用了Serializable級別,保證讀寫的順序性。

ObjectStore主要接口分為三部分，第一部分是Object的讀寫操作，類似于POSIX的部分接口，第二部分是Object的屬性(xattr)讀寫操作，這類操作的特征是kv對并且與某一個Object關聯。第三部分是關聯Object的kv操作(在Ceph中稱為omap)，這個其實與第二部分非常類似，但是在實現上可能會有所變化。

目前ObjectStore的主要實現是FileStore，也就是利用文件系統的POSIX接口實現ObjectStore API。每個Object在FileStore層會被看成是一個文件，Object的屬性(xattr)會利用文件的xattr屬性存取，因為有些文件系統(如Ext4)對xattr的長度有限制，因此超出長度的Metadata會被存儲在DBObjectMap里。而Object的omap則直接利用DBObjectMap實現。因此，可以看出xattr和omap操作是互通的，在用戶角度來說，前者可以看作是受限的長度，后者更寬泛(API沒有對這些做出硬性要求)。

FileJournal

DBObjectMap是FileStore的一部分，利用KeyValue數據庫實現了ObjectStore的第三部分API，DBObjectMap主要復雜在其實現了clone操作的no-copy。因為ObjectStore提供了clone API，提供對一個Object的完全clone(包括Object的屬性和omap)。DBObjectMap對每一個Object有一個Header，每個Object聯系的omap(kv pairs)對會與該Header聯系，當clone時，會產生兩個新的Header，原來的Header作為這兩個新Header的parent，這時候無論是原來的Object還是cloned Object在查詢或者寫操作時都會查詢parent的情況，并且實現copy-on-write。那么Header如何與omap(kv pairs)聯系呢，首先每個Header有一個唯一的seq，然后所有屬于該Header的omap的key里面都會包含該seq，因此，利用KeyValueDB的提供的有序prefix檢索來實現對omap的遍歷。

上面提到FileStore會將每個Object作為一個文件，那么Object的一些屬性會與Object Name一起作為文件名，Object 所屬的PG會作為文件目錄，當一個PG內所包含的文件超過一定程度時(在目錄內文件太多會造成文件系統的lookup性能損耗)，PG會被分裂成兩個PG。

感謝各位的閱讀！關于“Ceph中存儲引擎實現FileStore的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！