過去兩年，我的主要工作都在Hadoop這個技術棧中，而最近有幸接觸到了Ceph。我覺得這是一件很幸運的事，讓我有機會體驗另一種大型分散式儲存解決方案，可以對比出HDFS與Ceph這兩種幾乎完全不同的儲存系統分別有哪些優缺點、適合哪些場景。

對於分散式儲存，尤其是開源的分散式儲存，站在一個SRE的角度，我認為主要為商業公司解決了如下幾個問題：

可擴充套件，滿足業務增長導致的海量資料儲存需求；

比商用儲存便宜，大幅降低成本；

穩定，可以駕馭，好運維。

總之目標就是：又好用，又便宜，還穩定。但現實似乎並沒有這麼美好……

本文將從這三個我認為的根本價值出發，分析我運維Ceph的體會，同時對比中心化的分散式儲存系統，比如HDFS，橫向說一說。

一、可擴充套件性

Ceph聲稱可以無限擴充套件，因為它基於CRUSH演算法，沒有中心節點。 而事實上，Ceph確實可以無限擴充套件，但Ceph的無限擴充套件的過程，並不完全美好。

首先梳理一下Ceph的寫入流程。Ceph的新物件寫入物件，需要經過PG這一層預先定義好的定額Hash分片，然後PG，再經過一次叢集所有物理機器硬碟OSD構成的Hash，落到物理磁碟。

因此，Ceph的所有物件，是先被pre-hash到了一個固定數量的桶（PG）當中，然後根據叢集的整體物理架構crushmap，選擇落在具體的機器磁碟上。

這對擴容有什麼影響呢？

1.擴容粒度

我給擴容粒度的定義是：一次可以擴容多少臺機器。

Ceph在實踐中，擴容受“容錯域”制約，一次只能擴一個“容錯域”。

容錯域就是：副本隔離級別，即同一個replica的資料，放在不同的磁碟/機器/Rack/機房。

容錯域這個概念，在很多儲存方案裡都有，包括HDFS。為什麼Ceph會受影響呢？因為Ceph沒有中心化的元資料結點，導致資料放置策略受之影響。

資料放置策略，即一份資料replica，放在哪臺機器，哪塊硬碟。

中心化的，比如HDFS，會記錄每一個檔案，下面每一個數據塊的存放位置。這個位置是不會經常變動的，只有在1.檔案新建立；2.balancer重平衡；3.有硬碟壞了，中心節點針對損壞硬體上的資料重新放置時才會改變。

而Ceph，因為去中心化，導致容納資料的PG的位置，會根據crushmap的變化而變化。 來了新的機器、硬碟，就要為一些受影響的PG計算新的位置。 基於一致性雜湊的技術，在擴容時也要面臨同樣的問題。

因此，Ceph擴容需要PG們調整。正因為這個調整，導致Ceph受“容錯域”制約。

例如：有一個PG，是3副本，Ceph叢集有一個配置是PG要向外提供正常服務，至少有2個完整的副本。而當這個資料pool的容錯域是host時，同時擴容2臺機器，一些PG就有可能把3副本中的2個都對映到2臺新機器上去。而這2個副本都是新副本，都沒有完整的最新資料。剩下的一個副本，無法滿足老機器至少有完整的2副本的要求，也就不能提供正常讀寫服務了。

這就會導致這個PG裡的所有物件，停止對外服務。

作為admin，當然可以把配置降低，把資料pool的min_size下降為1。但這種配置，即使在正常情況下，因為磁碟故障，都有可能丟失資料，因此一般不會這樣設定。

那在擴容時，一次只擴容一臺機器時，是不是就安全了呢？

這樣就能保證所有PG都至少在老機器有2個完整的副本了。可是，即使是擴容一臺機器，也還要面臨擴容時老機器中有硬碟壞掉，導致PG的完整副本又下降為1的極端情況發生。

雖然PG有可能不能服務，但資料的永續性是沒有問題的。國內AT的雲，服務可靠性都沒有做得特別高，做到像永續性那樣3個9、4個9。雖然我不確定這兩朵大雲裡的物件儲存是不是使用的Ceph，但只要是基於類似CRUSH演算法，或者一致性雜湊等類似的去中心化技術實現的物件儲存，應該都會面對部分資料暫時不可服務的情況。

我們拋開最極端的情況，即假設在擴容時，以一個“容錯域”加入機器時，暫時沒有磁碟損壞。那麼有沒有辦法可以提升擴容粒度呢？

辦法是，在開始規劃Ceph叢集時，設定好更大層次的“容錯域”，比如Rack。 可以是真實的Rack，即使沒有也可以是邏輯的Rack。這樣擴容時，可以擴一個邏輯“容錯域”，就可以打破擴一臺機器的限制，擴一整個Rack，至少有好幾臺機器。

Tips：這裡我沒有講為什麼擴容粒度小是個不好的事。其實在很多公司，資料的日均增長量是很有可能大於一臺機器的儲存容量的。這就會造成擴容速度趕不上寫入速度的尷尬局面。這對於開始沒有設計好，圖快速deploy而架設的叢集，在後期是一個不小的傷害。

2.擴容時crushmap的改變

Ceph是根據crushmap去放置PG的物理位置的，倘若在擴容進行了一半時，又有硬碟壞掉了，那Ceph的crushmap就會改變，Ceph又會重新進行PG的re-hash，很多PG的位置又會重新計算。如果運氣比較差，很可能一臺機器的擴容進度被迫進行了很久才回到穩定的狀態。

這個crushmap改變導致的Ceph重平衡，不單單在擴容時，幾乎在任何時候，對一個大的儲存叢集都有些頭疼。在建立一個新叢集時，硬碟都比較新，因此故障率並不高。但是在運行了2-3年的大儲存叢集，壞盤真的是一個稀鬆平常的事情，1000臺規模的叢集一天壞個2-3塊盤很正常。crushmap經常變動，對Ceph內部不穩定，影響真的很大。隨之而來，可能是整體IO的下降（磁碟IO被反覆的rebalance佔滿），甚至是某些資料暫時不可用。

所以總的來說，Ceph的擴容是有那麼一丁點不痛快的。Ceph確實提供了無限的擴充套件能力，但擴容過程並不平滑，也不完全可控。crushmap的設計，達到了很好的去中心化效果，但也給叢集大了之後的不穩定埋下了一個坑。

而對比中心化元資料的HDFS，在擴容時幾乎無限制，你可以撒歡地擴容。老資料的搬遷，重平衡都會由單獨的job來處理，處理也很高效。它採用了滿節點和空節點兩兩配對的方式，從老節點移動足夠的資料，填滿新機器即可。中心化元資料在擴容&重平衡時，反而變成了一個優點。

3.擴容到一定量級後，PG數量需調整

如上文的Ceph資料寫入流程圖所示，Ceph物件的最小放置單位是PG，PG又會被放在硬碟上，PG理論上肯定是越大越好。因為這樣資料的分片隨機性更好，更能掩蓋偽隨機造成的單塊盤容量偏差過大問題。但PG數量在現實中不是越大越好的，它要受限於硬體，如CPU、記憶體、網路。 因此我們在規劃PG數時，不會盲目調大，一般社群也是建議200pg / osd。

假設我們現在有10臺機器，每臺一塊硬碟一共10塊盤，有1024個PG，PG都是單副本，那麼每個盤會存100個PG。此時這個設定非常健康，但當我們叢集擴容到1000臺機器，每臺硬碟就只放一個PG了，這會導致偽隨機造成的不平衡現象放大。因此，admin就要面臨調整PG數量，這就帶來了問題。

調PG，基本也就意味著整個叢集會進入一種嚴重不正常的狀態。幾乎50%的物件，涉及到調整後的PG都需要重新放置物理位置，這會引起服務質量的嚴重下降。

雖然調整PG不是一個經常性的事件，但在一個大型儲存，隨著發展，不可避免會經歷這個大考。

二、比商用儲存便宜

我們所說的和商業儲存比較，一般就是和EMC、IBM這類硬體軟體儲存解決方案廠家，或者雲解決方案Aliyun、AWS之類的對比。

自己建設機房，當然在硬體單價上更為便宜，但需要考慮綜合成本，包括：1.硬體成本；2.自養運維人員成本；3.服務質量由一般向好慢慢收斂。

人的成本這種玄學的問題，我就不談了，本文只談Ceph在硬體成本這塊有什麼有趣的地方。講道理，自己建機房，硬體成本應該是毫無疑問的便宜，那麼Ceph在這裡有什麼特殊呢？

問題在於，叢集可靠利用率。

叢集可靠利用率，即整個叢集在容量達到某個水平時不可對外服務，或者說不能保持高可用的服務。

打個比方，我們的手機快閃記憶體/電腦硬碟，是不是到99%了還能正常工作？ 當然，因為是本地儲存嘛。對於雲解決方案，也天然就沒有這個問題了。

對於商用儲存解決方案，比如EMC的Isilon分散式檔案系統，儲存容量達到甚至98-99%，仍能對外提供服務。

對於HDFS，在95%以下，儲存也能很好地對外提供服務。跑在HDFS上的Hadoop Job，會因為沒辦法寫入本地而掛掉。

而對於Ceph，在這一塊表現得並不好。根據經驗，在叢集整體使用率達到70%後，就有可能進入不穩定的狀態。

這是為什麼呢？問題在於，去中心化帶來的tradeoff。

Ceph是去中心化的分散式解決方案，物件的元資料是分佈在各臺物理機上的。因此所有物件，是被“偽隨機”地分配到各個磁碟上的。偽隨機不能保證所有磁碟的完全均勻分配，不能降低很多大物件同時落在一塊盤上的概率（我理解加入一層PG，又使PG多replica，是可以讓磁碟的方差變小的），因此總有一些磁碟的使用率會高出均值。

在叢集整體使用率不高時，都沒有問題。而在使用率達到70%後，就需要管理員介入了。因為方差大的盤，很有可能會觸及95%這條紅線。admin開始調低容量過高磁碟的reweight，但如果在這一批磁碟被調整reweight沒有結束時，又有一些磁碟被寫滿了，那管理員就必須被迫在Ceph沒有達到穩定狀態前，又一次reweight過高的磁碟。  這就導致了crushmap的再一次變更，從而導致Ceph離穩定狀態越來越遠。而此時擴容又不及時的話，更是雪上加霜。

而且之前的crushmap的中間狀態，也會導致一些PG遷移了一半，這些“不完整的”PG並不會被馬上刪除，這給本來就緊張的磁碟空間又加重了負擔。

有同學可能會好奇，一塊磁碟滿了，Ceph為什麼就不可用了。Ceph還真的就是這樣設計的，因為Ceph沒法保證新的物件是否落在空盤而不落在滿盤，所以Ceph選擇在有盤滿了時，就拒絕服務。

在我諮詢了一些同事和業界同行後，基本上大家的Ceph叢集都是在達到50%使用率時，就要開始準備擴容了。這其實是挺不省錢的，因為必須空置一大批機器的儲存資源。並且未來叢集的規模越大，空置效應就會放得越大，意味著浪費的錢/電費越多。

而很多傳統的中心化的分散式儲存系統，由於寫入時可以由主控節點選擇相對空閒的機器進行寫入，因此不會存在某些磁碟滿了，導致整個叢集不可寫入的問題。也正是如此，才可以做到整體寫入到95%了，仍然保持可用性。

我沒有真正核算過這種效應帶來的成本waste，但至少看上去是有點不夠完美的。

打個比方，當我預估有50pb的儲存時，需要300臺物理機了，我居然要提前採購好另外200-300臺物理機，還不能馬上用上，還要插上電。

因此Ceph也並不一定會很便宜，去中心化的分散式儲存也並沒有那麼美好。

但中心化的危害，似乎又是沒有爭議的問題（單點問題、中心節點擴充套件性問題等等 ），因此分散式裡真的沒有銀彈，只有tradeoff。

還有一種辦法，就是Ceph的叢集按整個pool來擴容，一個pool滿了，就不擴容了，開新的pool，新的物件只准寫新的pool，老的pool的物件可以刪除，可以讀取。 這乍看之下是一個很棒的解決方案，但仔細想想，這和HDFS的federation，和MySQL的分庫分表，做前端的大Hash，似乎沒有區別。

這也就談不上是“無限擴容”了，而且還需要寫一個前面的路由層。

三、穩定，可駕馭，好運維

這個穩定好運維，基本就看團隊的硬實力了。對開源軟體是否熟悉，是否有經驗，真的會有很大不同。

同時，這還受開源社群文件質量的影響。Ceph的開源社群還是不錯的，Red Hat收購併主導了Ceph之後，重新整理了Red Hat版本的Ceph文件，我認為讀起來邏輯感更強。

在公司內積累自己的運維文件也很關鍵。一個新手很可能會犯很多錯誤，導致事故發生。但對於公司，踩了一次的坑，就儘量不要再踩第二次了。這對公司的技術積累管理、技術文件管理、核心人才流失管理，都產生了一些挑戰。

我在Ceph運維中，曾遇到一個棘手的問題。即Ceph叢集達到了80%後，經常有磁碟變滿，然後管理員就要介入，調低過高磁碟的reweight。而在這臺磁碟使用量沒降下來之前，又有更多的磁碟被寫滿了，管理員就又要介入，又調整reweight，Ceph至此就再也沒有進入過穩定狀態了，管理員還必須時時刻刻盯著叢集。這導致了極大的運維投入，所以像這種事情一定要避免，這對運維人員的士氣是很大的傷害。

那麼，是否應該在早期進行容量預警，啟動採購流程呢？

可是這樣做，又回到了資源浪費的問題上。

此外，Ceph的物件是沒有last_access_time這種元資料的，因此Ceph物件的冷/熱之分，需要二次開發，做額外的工作。叢集大了之後，如何清理垃圾資料、如何歸檔冷資料，也帶來了不小的挑戰。

總結思考

1、Ceph確實有無限擴容的能力，但需要良好的初始規劃，擴容過程也並不完美。中心化造就了擴容的上限是單臺master結點的物理極限，造就了無限擴容的理論基礎，但實際擴容時，服務質量會受嚴重製約。

2、Ceph有些浪費硬體，成本核算時要考慮更多。

3、Ceph本身的去中心化設計犧牲了不少元資料，比如lastacesstime，這給未來資料治理帶來了壓力，也需要更強的團隊來運維和二次開發。積累運維經驗，積累運維團隊，是駕馭好開源分散式儲存的核心。對手隨著時間越來越強大，應對的運維團隊也需要越來越好，才能讓生產關係匹配生產力的要求。

4、技術本身沒有絕對的好壞，不同的技術是用來解決不同問題的。但在場景下，技術是有好壞的。因為在場景下，你有了立場，就有了亟待解決的問題的優先順序，也就一定能按優先順序選擇出最適合你的技術。