Ceph從2004年提交了第一行代碼，至今為止已經(jīng)10年了。這個(gè)起源于Sage博士論文，最早致力于開(kāi)發(fā)下一代高性能分布式文件系統(tǒng)的項(xiàng)目，現(xiàn)在也成為了開(kāi)源社區(qū)眾人皆知的明星項(xiàng)目。特別是隨著云計(jì)算的發(fā)展，Ceph乘上了OpenStack的春風(fēng)，受到各大廠商的待見(jiàn)，Intel、 DreamHost、SanDisk、CISCO、Yahoo等公司都或多或少的參與其中。RedHat更是一擲千金，直接砸了1.75億美金將Sage 創(chuàng)建的Inktank公司及其Ceph團(tuán)隊(duì)收入囊中，將其作為IaaS三大組件計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)之一。

在這十年的發(fā)展過(guò)程中，Ceph似乎越來(lái)越向著云計(jì)算的方向靠攏，最先的CephFS文件系統(tǒng)已經(jīng)不再是開(kāi)發(fā)重點(diǎn)，甚至開(kāi)發(fā)已經(jīng)陷入了停滯狀態(tài)。而與虛擬化相關(guān)的RBD、RGW則成了發(fā)展重點(diǎn)，成為發(fā)展最快的模塊。但是從代碼中仍然能夠看到各種遺跡，似乎在告訴后來(lái)人這段饒了一個(gè)大彎的歷史。

Ceph發(fā)展現(xiàn)在仍然快的眼花繚亂，讓我們暫時(shí)停下腳步，看看經(jīng)過(guò)十年發(fā)展后，現(xiàn)在Ceph的優(yōu)勢(shì)與缺點(diǎn)。

一、優(yōu)勢(shì)

CRUSH算法

CRUSH算法是Ceph最初的兩大創(chuàng)新之一(另一個(gè)是基于動(dòng)態(tài)子樹(shù)分區(qū)的元數(shù)據(jù)集群)，也是整個(gè)RADOS的基石，是Ceph最引以為豪的地方。

CRUSH在一致性哈希基礎(chǔ)上很好的考慮了容災(zāi)域的隔離，能夠?qū)崿F(xiàn)各類負(fù)載的副本放置規(guī)則，例如跨機(jī)房、機(jī)架感知等。同時(shí)， CRUSH算法支持副本和EC兩種數(shù)據(jù)冗余方式，還提供了四種不同類型的Bucket(Uniform, List, Tree, Straw)，充分考慮了實(shí)際生產(chǎn)過(guò)程中硬件的迭代式部署方式，雖然實(shí)際生產(chǎn)中大多數(shù)情況下的都是只用了一種Straw。

另外根據(jù)Sage的論文，CRUSH算法具有相當(dāng)好的可擴(kuò)展性，在數(shù)千OSD的情況下仍然能保證良好的負(fù)載平衡。但這更多是理論層面的，目前還沒(méi)有人給出在數(shù)PB規(guī)模的生產(chǎn)環(huán)境中的測(cè)試結(jié)果。

總的來(lái)看，CRUSH算法仍然是目前經(jīng)過(guò)實(shí)踐檢驗(yàn)的最好的數(shù)據(jù)分布算法之一。

2. 統(tǒng)一存儲(chǔ)架構(gòu)

Ceph最初設(shè)計(jì)的RADOS是為其實(shí)現(xiàn)一個(gè)高性能的文件系統(tǒng)服務(wù)的，并沒(méi)有考慮對(duì)于塊設(shè)備、對(duì)象存儲(chǔ)的支持，也就沒(méi)有什么RBD、RADOS GateWay，跟別提OpenStack和qemu之類的了。但誰(shuí)想無(wú)心插柳柳成蔭，由于 RADOS 出色的設(shè)計(jì)和獨(dú)立簡(jiǎn)潔的訪問(wèn)接口，再加上Sage敏銳的眼光，Ceph社區(qū)果斷推出了用于支持云計(jì)算的分布式塊存儲(chǔ)RBD和分布式對(duì)象存儲(chǔ)RADOS GateWay，并將開(kāi)發(fā)中心全面轉(zhuǎn)向云計(jì)算領(lǐng)域。

不得不說(shuō)，RADOS的設(shè)計(jì)還是非常的優(yōu)秀。從架構(gòu)上來(lái)看，RBD和RADOSGateWay實(shí)際上都只是RADOS的客戶端而已，但得益于RADOS的優(yōu)秀設(shè)計(jì)，RBD和RADOSGateWay的設(shè)計(jì)和實(shí)現(xiàn)都很簡(jiǎn)單，不需要考慮橫向擴(kuò)展、冗余、容災(zāi)、負(fù)載平衡的等復(fù)雜的分布式系統(tǒng)問(wèn)題，同時(shí)能夠提供足夠多的特性和足夠優(yōu)秀的性能，因此迅速得到了社區(qū)的認(rèn)可。另一方面，Ceph為OpenStack提供了良好的支持，成為了目前最火的OpenStack底層存儲(chǔ)系統(tǒng)。乘著云計(jì)算和OpenStack的東風(fēng)，Ceph作為一個(gè)統(tǒng)一存儲(chǔ)系統(tǒng)，似乎大有舍我取誰(shuí)之勢(shì)。

3.豐富的特性

Ceph的特性不可謂不多，從分布式系統(tǒng)最基本的橫向擴(kuò)展、動(dòng)態(tài)伸縮、冗余容災(zāi)、負(fù)載平衡等，到生產(chǎn)環(huán)境環(huán)境中非常實(shí)用的滾動(dòng)升級(jí)、多存儲(chǔ)池、延遲刪除等，再到高大上的CephFS集群、快照、糾刪碼、跨存儲(chǔ)池緩存等，不可謂不強(qiáng)大。

但是就像大多數(shù)開(kāi)源系統(tǒng)一樣，Ceph的基本特性，或者說(shuō)真正在生產(chǎn)環(huán)境中用的上的特性還是非常靠譜的，但其他“高級(jí)”特性就只能打一個(gè)問(wèn)號(hào)了。特別是在CephFS模塊，由于Ceph社區(qū)目前的開(kāi)發(fā)重點(diǎn)主要還是與云計(jì)算相關(guān)的部分，即RBD和RADOSGateWay，導(dǎo)致CephFS的開(kāi)發(fā)停滯了很久，相關(guān)的特性，例如元數(shù)據(jù)集群、快照等，目前都不滿足生產(chǎn)環(huán)境的要求。

二、缺點(diǎn)

代碼質(zhì)量

代碼質(zhì)量的問(wèn)題，實(shí)際上是個(gè)仁者見(jiàn)仁智者見(jiàn)智的問(wèn)題。

Ceph主要使用C/C++語(yǔ)言編寫(xiě)，同時(shí)外圍的很多腳本和工具用了Python。之所以要說(shuō)明Ceph的語(yǔ)言構(gòu)成，是因?yàn)榇�碼質(zhì)量實(shí)際上是和語(yǔ)言具有密切的關(guān)系。不否認(rèn)用C++也能寫(xiě)出優(yōu)雅的代碼，但相比于更加“現(xiàn)代”的語(yǔ)言，要想寫(xiě)出具備同樣可讀性、結(jié)構(gòu)良好、調(diào)理清晰代碼，C++要困難很多。但是，由于存儲(chǔ)作為底層系統(tǒng)，對(duì)效率的追求是無(wú)止境的，因此不太可能舍棄對(duì)于內(nèi)存等底層系統(tǒng)資源的控制，而使用 Java/Python這類的語(yǔ)言。而作為一個(gè)開(kāi)源項(xiàng)目，期望所有的貢獻(xiàn)者都是C++的高手，未免有些強(qiáng)人所難，這似乎成了一個(gè)死結(jié)。其他類似的開(kāi)源項(xiàng)目怎么辦呢?貌似他們都用的純c……

另一方面，Ceph廣泛使用了STL，在部分核心代碼中還是用了BOOST，這兩者在底層核心系統(tǒng)代碼中的可用性也一直存在爭(zhēng)議。這更加加劇了代碼質(zhì)量的挑戰(zhàn)性。

最關(guān)鍵的是，Ceph似乎已經(jīng)被太多已經(jīng)背負(fù)了太多的歷史包袱，比如最核心的osd模塊，最初的設(shè)計(jì)包含OSD 和PG類，其中PG類負(fù)責(zé)PG的通用邏輯，OSD負(fù)責(zé)管理所有的PG。然后PG的子類ReplicatedPG實(shí)現(xiàn)了以副本作為冗余模式的PG。這里就存在了兩個(gè)半類：OSD、PG及其子類ReplicatedPG，這兩個(gè)半類實(shí)現(xiàn)了osd模塊99%的邏輯，可以想象這兩個(gè)半類會(huì)有多大。

在目前的master分支上，相關(guān)文件的大小分別是：

OSD.h+OSD.cc = 2383行+8604行 = 10987行

PG.h+PG.cc = 2256行+7611行 = 9867行

ReplicatedPG.h+ReplicatedPG.cc = 1487行+12665行 = 14152行

需要特別注意的是，從C++繼承的角度上，理解一個(gè)類，必須理解他的父類，也就是說(shuō)，如果你想理解ReplicatedPG，理論上你必須同時(shí)理解PG，也就是說(shuō)，要同時(shí)理解20000+行代碼!

更加喪心病狂的是，這兩個(gè)半類之間存在密切而復(fù)雜的調(diào)用關(guān)系，相互之間直接使用整個(gè)類，而沒(méi)有什么實(shí)際上的接口隔離。嚴(yán)重加劇了理解代碼的難度。

在EC功能以一種奇葩的方式加入到osd中之后，整個(gè)場(chǎng)面更加混亂。按照最初的設(shè)計(jì)，實(shí)現(xiàn)EC應(yīng)該增加PG的一個(gè)子類，類似 ErasureCodePG。但是由于ReplicatedPG包含了太多通用的代碼，實(shí)際上已經(jīng)和PG合二為一了，所以EC只能在 ReplicatedPG的基礎(chǔ)上改造。于是又出現(xiàn)了PGBackend的概念和相關(guān)的實(shí)現(xiàn)，這只能說(shuō)是挑戰(zhàn)人腦的極限了。

Ceph社區(qū)也曾試著梳理代碼，比如添加OSDService類，作為PG與OSD通訊的接口。這樣所有的PG全部調(diào)用OSDService而非OSD，相當(dāng)于做了OSD與PG之間的隔離。但是似乎并沒(méi)有起到足夠的效果，現(xiàn)在已經(jīng)名存實(shí)亡了。

Ceph在這樣的代碼質(zhì)量下，還能向前走多久，委實(shí)是一件令人擔(dān)憂的事情。

2. 性能

Ceph的性能總的來(lái)說(shuō)還是不錯(cuò)的，基本上能發(fā)揮出物理硬件的性能，但是存在以下幾個(gè)隱患：

1)數(shù)據(jù)雙倍寫(xiě)入。Ceph本地存儲(chǔ)接口(FileStore)為了支持事務(wù)，引入了日志(Journal)機(jī)制。所有的寫(xiě)入操作都需要先寫(xiě)入日志(XFS模式下)，然后再寫(xiě)入本地文件系統(tǒng)。簡(jiǎn)單來(lái)說(shuō)就是一份數(shù)據(jù)需要寫(xiě)兩遍，日志+本地文件系統(tǒng)。這就造成了在大規(guī)模連續(xù)IO的情況下，實(shí)際上磁盤(pán)輸出的吞吐量只有其物理性能的一半。

2)IO路徑過(guò)長(zhǎng)。這個(gè)問(wèn)題在Ceph的客戶端和服務(wù)器端都存在。以osd為例，一個(gè)IO需要經(jīng)過(guò)message、OSD、FileJournal、FileStore多個(gè)模塊才能完成，每個(gè)模塊之間都涉及到隊(duì)列和線程切換，部分模塊在對(duì)IO進(jìn)行處理時(shí)還要進(jìn)行內(nèi)存拷貝，導(dǎo)致整體性能不高。

3)對(duì)高性能硬件的支持有待改進(jìn)。Ceph最開(kāi)始是為HDD設(shè)計(jì)的，沒(méi)有充分考慮全SSD，甚至更先進(jìn)的PCIe SSD和NVRAM的情況NVRAM。導(dǎo)致這些硬件的物理性能在Ceph中無(wú)法充分發(fā)揮出來(lái)，特別是延遲和IOPS，受比較大的影響。

3. CephFS

CephFS現(xiàn)在在整個(gè)Ceph系統(tǒng)中處于一個(gè)較為尷尬的情況，因?yàn)镻OSIX這種借口似乎在云計(jì)算中沒(méi)有用武之地，導(dǎo)致了社區(qū)對(duì)這個(gè)模塊的關(guān)注不足，也就沒(méi)有什么進(jìn)展。

CephFS作為最初Ceph的設(shè)計(jì)目標(biāo)，Sage投入了巨大的精力，幾乎實(shí)現(xiàn)了所有需要的特性，并且進(jìn)行了大量工程層面的優(yōu)化。

正所謂成也蕭何敗蕭何，Ceph想把CephFS模塊做到足夠強(qiáng)大，甚至是最強(qiáng)大，但強(qiáng)大的同時(shí)也意味著不菲的代價(jià)。元數(shù)據(jù)動(dòng)態(tài)子樹(shù)分區(qū)、目錄分片、快照、權(quán)限控制、IOPS優(yōu)化、故障恢復(fù)、分布式緩存、強(qiáng)弱一致性控制，這些高大上的名詞背后都意味著復(fù)雜的工程性任務(wù)，更不要說(shuō)將這些疊加在一起。很多時(shí)候，疊加不是想加，而是相乘的關(guān)系。最終的結(jié)果就是整個(gè)MDS的工程難度已經(jīng)超過(guò)了可以掌控的程度，無(wú)法做出足夠成熟、穩(wěn)定的系統(tǒng)。

目前CephFS宣稱其單MDS的模式是穩(wěn)定的，MDS的集群的模式是不穩(wěn)定的。而快照功能默認(rèn)關(guān)閉，今后也夠嗆會(huì)有開(kāi)啟的可能了。

4. 業(yè)務(wù)連續(xù)性

Ceph中的RADOS采用強(qiáng)一致性設(shè)計(jì)，即Write-All-Read-One，這種模式的好處在于讀取效率較高，而且工程難度較低，比較適合與讀多寫(xiě)少的系統(tǒng)。

Write-All-Read-One的特點(diǎn)是必須等待所有的副本全部寫(xiě)入完畢才算是寫(xiě)入成功，這實(shí)際上對(duì)系統(tǒng)硬件的可靠性要求較高，因?yàn)槿绻�在�?xiě)入過(guò)程中存在任意硬件故障，則寫(xiě)入過(guò)程都要受影響。通常表現(xiàn)為卡頓，一般在數(shù)秒級(jí)別，時(shí)間長(zhǎng)短和判斷故障的機(jī)制以及故障恢復(fù)過(guò)程中IO的處理策略相關(guān)。

但是當(dāng)集群非常非常大時(shí)，Write-All-Read-One對(duì)于硬件可靠性的要求幾乎是無(wú)法滿足的。想象一下一個(gè)10PB的系統(tǒng)，按照最大4TB每塊盤(pán)的計(jì)算，就有2500塊磁盤(pán)。按照我們以往的運(yùn)維經(jīng)驗(yàn)，每周存在一塊磁盤(pán)故障是完全正常的。這種場(chǎng)景下，如果數(shù)據(jù)分布足夠分散，實(shí)際上一塊磁盤(pán)可能涉及到很多數(shù)據(jù)塊，也就是說(shuō)一塊磁盤(pán)故障會(huì)影響很多IO，而這種情況每周發(fā)生一次。這對(duì)業(yè)務(wù)連續(xù)性的影響是已經(jīng)是不可忽略的。

生產(chǎn)環(huán)境中的場(chǎng)景比這個(gè)更加復(fù)雜，因?yàn)榇疟P(pán)或者硬件的故障可能不僅表現(xiàn)為不可寫(xiě)，還有可能是慢或者不穩(wěn)定。這些情況對(duì)于業(yè)務(wù)連續(xù)性的影響也更加嚴(yán)重。

5. 社區(qū)

Ceph社區(qū)現(xiàn)在已經(jīng)有很多廠商實(shí)際上或者號(hào)稱參入進(jìn)來(lái)，其中不乏Intel、Dreamhost、SanDisk這樣的大廠，也不乏UnitedStack這樣的Start-Up公司，還有電信、大學(xué)、研究所這類非存儲(chǔ)領(lǐng)域的公司或單位。但實(shí)際上整個(gè)Ceph還是掌握在Inktank或者說(shuō)RedHat的手中，絕大多數(shù)核心代碼由他們貢獻(xiàn)，也是他們Review和Merge。總的來(lái)說(shuō)還是一個(gè)集權(quán)組織。

更加重要的是，Ceph相比OpenStack這種成熟完善的開(kāi)源社區(qū)，缺乏足夠的基礎(chǔ)設(shè)施，例如成熟的單元測(cè)試、集成測(cè)試、測(cè)試環(huán)境、Reivew流程、貢獻(xiàn)指引、代碼規(guī)范等。導(dǎo)致整個(gè)社區(qū)仍然是人治、而非法制的過(guò)程，代碼和系統(tǒng)的發(fā)展方向本質(zhì)是由RedHat公司控制的。

對(duì)于以上這些問(wèn)題，Ceph社區(qū)也非常清楚，并且正在或者將要改進(jìn)。例如為了增加了對(duì)于SSD的支持，改進(jìn)數(shù)據(jù)雙倍寫(xiě)入問(wèn)題以及更完善的社區(qū)建設(shè)和基礎(chǔ)設(shè)施等。這些都增加了人們對(duì)Ceph的信心。

總的來(lái)說(shuō)，Ceph瑕不掩瑜，仍然是一個(gè)優(yōu)秀，甚至出色的開(kāi)源存儲(chǔ)系統(tǒng)。如果說(shuō)分布式存儲(chǔ)在云計(jì)算時(shí)代是風(fēng)口上的豬，那么Ceph也是一直優(yōu)秀的豬。

未來(lái)是什么樣子，我們拭目以待。

關(guān)于作者

袁冬博士，UnitedStack產(chǎn)品副總裁、Ceph等開(kāi)源存儲(chǔ)項(xiàng)目的核心代碼貢獻(xiàn)者。

原文鏈接：https://www.ustack.com/blog/sikao/