Ceph從2004年提交了第一行代碼，至今為止已經10年了。這個起源于Sage博士論文，最早致力于開發下一代高性能分布式文件系統的項目，現在也成為了開源社區眾人皆知的明星項目。特別是隨著云計算的發展，Ceph乘上了OpenStack的春風，受到各大廠商的待見，Intel、 DreamHost、SanDisk、CISCO、Yahoo等公司都或多或少的參與其中。RedHat更是一擲千金，直接砸了1.75億美金將Sage 創建的Inktank公司及其Ceph團隊收入囊中，將其作為IaaS三大組件計算、網絡、存儲之一。
在這十年的發展過程中，Ceph似乎越來越向著云計算的方向靠攏，最先的CephFS文件系統已經不再是開發重點，甚至開發已經陷入了停滯狀態。而與虛擬化相關的RBD、RGW則成了發展重點，成為發展最快的模塊。但是從代碼中仍然能夠看到各種遺跡，似乎在告訴后來人這段饒了一個大彎的歷史。
Ceph發展現在仍然快的眼花繚亂，讓我們暫時停下腳步，看看經過十年發展后，現在Ceph的優勢與缺點。
一、優勢
CRUSH算法
CRUSH算法是Ceph最初的兩大創新之一(另一個是基于動態子樹分區的元數據集群)，也是整個RADOS的基石，是Ceph最引以為豪的地方。
CRUSH在一致性哈希基礎上很好的考慮了容災域的隔離，能夠實現各類負載的副本放置規則，例如跨機房、機架感知等。同時， CRUSH算法支持副本和EC兩種數據冗余方式，還提供了四種不同類型的Bucket(Uniform, List, Tree, Straw)，充分考慮了實際生產過程中硬件的迭代式部署方式，雖然實際生產中大多數情況下的都是只用了一種Straw。
另外根據Sage的論文，CRUSH算法具有相當好的可擴展性，在數千OSD的情況下仍然能保證良好的負載平衡。但這更多是理論層面的，目前還沒有人給出在數PB規模的生產環境中的測試結果。
總的來看，CRUSH算法仍然是目前經過實踐檢驗的最好的數據分布算法之一。
2. 統一存儲架構
Ceph最初設計的RADOS是為其實現一個高性能的文件系統服務的，并沒有考慮對于塊設備、對象存儲的支持，也就沒有什么RBD、RADOS GateWay，跟別提OpenStack和qemu之類的了。但誰想無心插柳柳成蔭，由于 RADOS 出色的設計和獨立簡潔的訪問接口，再加上Sage敏銳的眼光，Ceph社區果斷推出了用于支持云計算的分布式塊存儲RBD和分布式對象存儲RADOS GateWay，并將開發中心全面轉向云計算領域。
不得不說，RADOS的設計還是非常的優秀。從架構上來看，RBD和RADOSGateWay實際上都只是RADOS的客戶端而已，但得益于RADOS的優秀設計，RBD和RADOSGateWay的設計和實現都很簡單，不需要考慮橫向擴展、冗余、容災、負載平衡的等復雜的分布式系統問題，同時能夠提供足夠多的特性和足夠優秀的性能，因此迅速得到了社區的認可。另一方面，Ceph為OpenStack提供了良好的支持，成為了目前最火的OpenStack底層存儲系統。乘著云計算和OpenStack的東風，Ceph作為一個統一存儲系統，似乎大有舍我取誰之勢。
3.豐富的特性
Ceph的特性不可謂不多，從分布式系統最基本的橫向擴展、動態伸縮、冗余容災、負載平衡等，到生產環境環境中非常實用的滾動升級、多存儲池、延遲刪除等，再到高大上的CephFS集群、快照、糾刪碼、跨存儲池緩存等，不可謂不強大。
但是就像大多數開源系統一樣，Ceph的基本特性，或者說真正在生產環境中用的上的特性還是非常靠譜的，但其他“高級”特性就只能打一個問號了。特別是在CephFS模塊，由于Ceph社區目前的開發重點主要還是與云計算相關的部分，即RBD和RADOSGateWay，導致CephFS的開發停滯了很久，相關的特性，例如元數據集群、快照等，目前都不滿足生產環境的要求。
[page]二、缺點
代碼質量
代碼質量的問題，實際上是個仁者見仁智者見智的問題。
Ceph主要使用C/C++語言編寫，同時外圍的很多腳本和工具用了Python。之所以要說明Ceph的語言構成，是因為代碼質量實際上是和語言具有密切的關系。不否認用C++也能寫出優雅的代碼，但相比于更加“現代”的語言，要想寫出具備同樣可讀性、結構良好、調理清晰代碼，C++要困難很多。但是，由于存儲作為底層系統，對效率的追求是無止境的，因此不太可能舍棄對于內存等底層系統資源的控制，而使用 Java/Python這類的語言。而作為一個開源項目，期望所有的貢獻者都是C++的高手，未免有些強人所難，這似乎成了一個死結。其他類似的開源項目怎么辦呢?貌似他們都用的純c……
另一方面，Ceph廣泛使用了STL，在部分核心代碼中還是用了BOOST，這兩者在底層核心系統代碼中的可用性也一直存在爭議。這更加加劇了代碼質量的挑戰性。
最關鍵的是，Ceph似乎已經被太多已經背負了太多的歷史包袱，比如最核心的osd模塊，最初的設計包含OSD 和PG類，其中PG類負責PG的通用邏輯，OSD負責管理所有的PG。然后PG的子類ReplicatedPG實現了以副本作為冗余模式的PG。這里就存在了兩個半類：OSD、PG及其子類ReplicatedPG，這兩個半類實現了osd模塊99%的邏輯，可以想象這兩個半類會有多大。
在目前的master分支上，相關文件的大小分別是：
OSD.h+OSD.cc = 2383行+8604行 = 10987行
PG.h+PG.cc = 2256行+7611行 = 9867行
ReplicatedPG.h+ReplicatedPG.cc = 1487行+12665行 = 14152行
需要特別注意的是，從C++繼承的角度上，理解一個類，必須理解他的父類，也就是說，如果你想理解ReplicatedPG，理論上你必須同時理解PG，也就是說，要同時理解20000+行代碼!
更加喪心病狂的是，這兩個半類之間存在密切而復雜的調用關系，相互之間直接使用整個類，而沒有什么實際上的接口隔離。嚴重加劇了理解代碼的難度。
在EC功能以一種奇葩的方式加入到osd中之后，整個場面更加混亂。按照最初的設計，實現EC應該增加PG的一個子類，類似 ErasureCodePG。但是由于ReplicatedPG包含了太多通用的代碼，實際上已經和PG合二為一了，所以EC只能在 ReplicatedPG的基礎上改造。于是又出現了PGBackend的概念和相關的實現，這只能說是挑戰人腦的極限了。
Ceph社區也曾試著梳理代碼，比如添加OSDService類，作為PG與OSD通訊的接口。這樣所有的PG全部調用OSDService而非OSD，相當于做了OSD與PG之間的隔離。但是似乎并沒有起到足夠的效果，現在已經名存實亡了。
Ceph在這樣的代碼質量下，還能向前走多久，委實是一件令人擔憂的事情。
2. 性能
Ceph的性能總的來說還是不錯的，基本上能發揮出物理硬件的性能，但是存在以下幾個隱患：
1)數據雙倍寫入。Ceph本地存儲接口(FileStore)為了支持事務，引入了日志(Journal)機制。所有的寫入操作都需要先寫入日志(XFS模式下)，然后再寫入本地文件系統。簡單來說就是一份數據需要寫兩遍，日志+本地文件系統。這就造成了在大規模連續IO的情況下，實際上磁盤輸出的吞吐量只有其物理性能的一半。
2)IO路徑過長。這個問題在Ceph的客戶端和服務器端都存在。以osd為例，一個IO需要經過message、OSD、FileJournal、FileStore多個模塊才能完成，每個模塊之間都涉及到隊列和線程切換，部分模塊在對IO進行處理時還要進行內存拷貝，導致整體性能不高。
3)對高性能硬件的支持有待改進。Ceph最開始是為HDD設計的，沒有充分考慮全SSD，甚至更先進的PCIe SSD和NVRAM的情況NVRAM。導致這些硬件的物理性能在Ceph中無法充分發揮出來，特別是延遲和IOPS，受比較大的影響。
3. CephFS
CephFS現在在整個Ceph系統中處于一個較為尷尬的情況，因為POSIX這種借口似乎在云計算中沒有用武之地，導致了社區對這個模塊的關注不足，也就沒有什么進展。
CephFS作為最初Ceph的設計目標，Sage投入了巨大的精力，幾乎實現了所有需要的特性，并且進行了大量工程層面的優化。
正所謂成也蕭何敗蕭何，Ceph想把CephFS模塊做到足夠強大，甚至是最強大，但強大的同時也意味著不菲的代價。元數據動態子樹分區、目錄分片、快照、權限控制、IOPS優化、故障恢復、分布式緩存、強弱一致性控制，這些高大上的名詞背后都意味著復雜的工程性任務，更不要說將這些疊加在一起。很多時候，疊加不是想加，而是相乘的關系。最終的結果就是整個MDS的工程難度已經超過了可以掌控的程度，無法做出足夠成熟、穩定的系統。
目前CephFS宣稱其單MDS的模式是穩定的，MDS的集群的模式是不穩定的。而快照功能默認關閉，今后也夠嗆會有開啟的可能了。
4. 業務連續性
Ceph中的RADOS采用強一致性設計，即Write-All-Read-One，這種模式的好處在于讀取效率較高，而且工程難度較低，比較適合與讀多寫少的系統。
Write-All-Read-One的特點是必須等待所有的副本全部寫入完畢才算是寫入成功，這實際上對系統硬件的可靠性要求較高，因為如果在寫入過程中存在任意硬件故障，則寫入過程都要受影響。通常表現為卡頓，一般在數秒級別，時間長短和判斷故障的機制以及故障恢復過程中IO的處理策略相關。
但是當集群非常非常大時，Write-All-Read-One對于硬件可靠性的要求幾乎是無法滿足的。想象一下一個10PB的系統，按照最大4TB每塊盤的計算，就有2500塊磁盤。按照我們以往的運維經驗，每周存在一塊磁盤故障是完全正常的。這種場景下，如果數據分布足夠分散，實際上一塊磁盤可能涉及到很多數據塊，也就是說一塊磁盤故障會影響很多IO，而這種情況每周發生一次。這對業務連續性的影響是已經是不可忽略的。
生產環境中的場景比這個更加復雜，因為磁盤或者硬件的故障可能不僅表現為不可寫，還有可能是慢或者不穩定。這些情況對于業務連續性的影響也更加嚴重。
5. 社區
Ceph社區現在已經有很多廠商實際上或者號稱參入進來，其中不乏Intel、Dreamhost、SanDisk這樣的大廠，也不乏UnitedStack這樣的Start-Up公司，還有電信、大學、研究所這類非存儲領域的公司或單位。但實際上整個Ceph還是掌握在Inktank或者說RedHat的手中，絕大多數核心代碼由他們貢獻，也是他們Review和Merge。總的來說還是一個集權組織。
更加重要的是，Ceph相比OpenStack這種成熟完善的開源社區，缺乏足夠的基礎設施，例如成熟的單元測試、集成測試、測試環境、Reivew流程、貢獻指引、代碼規范等。導致整個社區仍然是人治、而非法制的過程，代碼和系統的發展方向本質是由RedHat公司控制的。
對于以上這些問題，Ceph社區也非常清楚，并且正在或者將要改進。例如為了增加了對于SSD的支持，改進數據雙倍寫入問題以及更完善的社區建設和基礎設施等。這些都增加了人們對Ceph的信心。
總的來說，Ceph瑕不掩瑜，仍然是一個優秀，甚至出色的開源存儲系統。如果說分布式存儲在云計算時代是風口上的豬，那么Ceph也是一直優秀的豬。
未來是什么樣子，我們拭目以待。
關于作者
袁冬博士，UnitedStack產品副總裁，負責UnitedStack產品、售前和對外合作工作;云計算專家，在云計算、虛擬化、分布式系統和企業級應用等方面有豐富的經驗;對分布式存儲、非結構數據存儲和存儲虛擬化有深刻地理解，在云存儲和企業級存儲領域有豐富的研發與實踐經驗;Ceph等開源存儲項目的核心代碼貢獻者。
京公網安備 11010502049343號