Ceph從2004年提交了第一行程式碼，至今為止已經10年了。這個起源於Sage博士論文，最早致力於開發下一代高效能分散式檔案系統的專案，現在也成為了開源社群眾人皆知的明星專案。特別是隨著雲端計算的發展，Ceph乘上了OpenStack的春風，受到各大廠商的待見，Intel、DreamHost、SanDisk、CISCO、Yahoo等公司都或多或少的參與其中。RedHat更是一擲千金，直接砸了1.75億美金將Sage建立的Inktank公司及其Ceph團隊收入囊中，將其作為IaaS三大元件計算、網路、儲存之一。

在這十年的發展過程中，Ceph似乎越來越向著雲端計算的方向靠攏，最先的CephFS檔案系統已經不再是開發重點，甚至開發已經陷入了停滯狀態。而與虛擬化相關的RBD、RGW則成了發展重點，成為發展最快的模組。

Ceph發展現在仍然快的眼花繚亂，讓我們暫時停下腳步，看看經過十年發展後，現在Ceph的優勢與缺點。

一、優勢

1. 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的開發停滯了很久，相關的特性，例如元資料叢集、快照等，目前都不滿足生產環境的要求。

二、缺點

1. 程式碼質量

程式碼質量的問題，實際上是個仁者見仁智者見智的問題。

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也是一直優秀的豬。

未來是什麼樣子，我們拭目以待。