Ceph的示例分析

這篇文章主要介紹了Ceph的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

   Ceph起源于2003年，2003年~2007年是Ceph的研究開發時期，2012年7月3日，Sage宣布版本Argonaut（0.48版本）發布，這是Ceph版本發布的一個非常重要的里程碑。Ceph在國內的應用從2014年開始走強，從此Ceph的架構設計理念在國內倍受追捧。

  Ceph為云平臺提供后端存儲，我覺得這個目標和定位非常清晰。Ceph一開始作為OpenStack的一個后端存儲，我認為這是非常好的切入方式。摘錄自Cephalocon APAC 2018前夕的社區訪談內容：“雖然Ceph的市場規模尚無官方結論，但據Ceph中國社區聯合創始人孫琦粗略統計，市場上70%～80%的云平臺都在采用Ceph作為底層的存儲平臺。”

  Ceph采用Crush算法的去中心化設計，底層基于對象存儲。Ceph開始的時候以業界流行的對象存儲為切入點，后來提供了塊和文件存儲功能。Ceph在一個統一的系統中同時提供了對象、塊和文件存儲功能。

  設計巧妙、功能齊全是Ceph引以為傲的亮點，但我們要看到其中潛在的隱患。作為同行，我最近對大名鼎鼎的Ceph進行了一些學習和了解，發現了解得越多，對Ceph在特定領域（如數據庫）的應用就越沒有信心。

  Ceph官方宣傳Ceph具有高可靠、高性能和易擴容三大特性。Ceph高可靠我沒有做過太多了解，姑且認為在非數據庫這樣嚴苛的場景下可以達到。易擴容是分布式系統必備特性，我相信Ceph做得還不錯。對于高性能這點我持保留意見。為什么這么說呢，Ceph作為后端存儲可以跑數據庫嗎？有在Ceph上跑過數據庫的朋友，我們可以好好交流一下。接下來著重分析Ceph在性能方面做得不盡人意的地方。

  Ceph底層基于對象存儲，剛開始用于對象存儲功能，無可厚非。但后來增加了塊和文件存儲功能，底層存儲還是基于對象存儲，這個做法的局限性就非常明顯了。

  我舉個例子大家可能就明白了。FastDFS目前是類似于Kev-Value的分布式文件存儲系統，沒有對大文件進行分片存儲，只能使用專有API訪問，簡潔高效。如果FastDFS要提供通用文件接口（客戶端可以mount到本地的標準文件系統），并且對大文件進行分片存儲，server端最省事的實現方式就是 FastDFS + 文件目錄服務（文件元數據管理）。這種搭積木的實現方式性能會很好嗎？請大家自行評估。

  去中心化的Crush算法或一致性hash算法在存儲業界倍受推崇，我覺得還是辯證地看待這個問題比較好。去中心化的分布式算法必然帶來更大的系統復雜度，這點從Ceph發布第一個版本到推出穩定可用版本的時間跨度就可以得到印證。另外，去中心化的算法針對對象存儲方式比較有效，但對于其他存儲方式，可能就非常雞肋甚至不合時宜了。比如文件存儲方式，因為這種方式必然要引入中心節點管理文件元數據，此時通過算法實現去中心化的做法已經喪失了其原本意義。

  最后說一下Ceph的寫放大問題。“3副本情況下，當數據寫入量較大時，WAF（寫放大系數）逐漸收斂于6，符合我們上文WAF=2*N的推理（N為副本數）；但是當寫入對象很小時，WAF則會很大。”

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Ceph的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!