Ceph淺析（上）：概況與設計思想

【編者按】Ceph，當下已成為OpenStack上最通用的存儲之一，也是是目前人氣最高的開源存儲項目之一。近日，擁有海量存儲領域工作經驗的華為@一棹凌煙基于現有資料文檔的學習思考，以及由此而來的心得體會，對Ceph進行介紹與分析。文章內容大致涵蓋Ceph的產生背景、設計思想、技術實現、主要特點、與OpenStack的聯系、與Swift的比較等等。

以下為原文：

Ceph的概況

本文將對Ceph的基本情況進行概要介紹，以期讀者能夠在不涉及技術細節的情況下對Ceph建立一個初步印象。

1. 什么是Ceph？

Ceph的官方網站Ceph.com上用如下這句話簡明扼要地定義了Ceph：

“Ceph is a unified, distributed storage system designed for excellent performance, reliability and scalability.”

也即，Ceph是一種為優秀的性能、可靠性和可擴展性而設計的統一的、分布式的存儲系統。應該說，這句話確實點出了Ceph的要義，可以作為理解Ceph系統設計思想和實現機制的基本出發點。在這個定義中，應當特別注意“存儲系統”這個概念的兩個修飾詞，即“統一的”和“分布式的”。

具體而言，“統一的”意味著Ceph可以一套存儲系統同時提供對象存儲、塊存儲和文件系統存儲三種功能，以便在滿足不同應用需求的前提下簡化部署和運維。而“分布式的”在Ceph系統中則意味著真正的無中心結構和沒有理論上限的系統規模可擴展性。在實踐當中，Ceph可以被部署于上千臺服務器上。截至2013年3月初，Ceph在生產環境下部署的最大規模系統為Dreamhost公司的對象存儲業務集群，其管理的物理存儲容量為3PB。

2. 為什么要關注Ceph？

事實上，Ceph并不是一個剛剛出現的開源項目。與此相反，從最初發布到逐漸流行，Ceph走過了七年以上的漫長路程。筆者以為，之所以應當對Ceph加以了解，其原因大致有兩個方面：

首先，Ceph本身確實具有較為突出的優勢。

Ceph值得一提的優勢頗多，包括統一存儲能力、可擴展性、可靠性、性能、自動化的維護等等。本質上，Ceph的這些優勢均來源于其先進的核心設計思想，筆者將其概括為八個字――“無需查表，算算就好”。基于這種設計思想，Ceph充分發揮存儲設備自身的計算能力，同時消除了對系統單一中心節點的依賴，從而實現了真正的無中心結構。基于這一設計思想和結構，Ceph一方面實現了高度的可靠性和可擴展性，另一方面保證了客戶端訪問的相對低延遲和高聚合帶寬。通過后續內容的介紹，讀者可以看到，Ceph幾乎所有優秀特性的實現，都與這個核心設計思想有關。

其次，Ceph目前在OpenStack社區中備受重視。

OpenStack是目前最為流行的開源云操作系統。而據筆者觀察，Ceph之所以在近一兩年間熱度驟升，其最為有力的推動因素就是OpenStack社區的實際需求。目前而言，Ceph已經成為OpenStack社區中呼聲最高的開源存儲方案之一，其實際應用主要涉及塊存儲和對象存儲，并且開始向文件系統領域擴展。這一部分的相關情況，在后續文章中也將進行介紹。

3. Ceph的產生與發展

通常而言，開源項目的來源有三：一是學校里的大牛作的課題，論文發夠然后開源；二是企業里的大牛搞的產品，機緣巧合于是開源；三是某些大牛突然顯靈，然后一票人跟著一起開源。每一類的例子都有不少，而不同起源的開源項目也有著自身的不同特點。具體而言，第一類項目的原理和技術上很可能頗有獨到之處，而Ceph就正在此列。相比之下，第二類項目的設計實現很可能頗為成熟，并且在開源之前或者開源初期就獲得生產環境下的實際部署應用機會。這種出身背景上的因素，對于一個開源項目的后續發展很有可能產生影響。

言歸正傳。Ceph項目起源于其創始人Sage Weil在加州大學Santa Cruz分校攻讀博士期間的研究課題。項目的起始時間為2004年。在2006年的OSDI學術會議上，Sage發表了介紹Ceph的論文，并在該篇論文的末尾提供了Ceph項目的下載鏈接。由此，Ceph開始廣為人知。

Ceph使用C++語言開發。對于一個典型的強調性能的系統項目，這一選擇可以理解。

作為開源項目，Ceph遵循LGPL協議。

根據Inktank官方網站上的信息，Cpeh的生態系統參加下圖：

不難看出，圖中列出的廠商或組織帶有明顯的云計算氣息。

隨著Ceph的熱度不斷增加，Sage Weil于 2011年創立了Inktank公司以主導Ceph的開發和社區維護。目前，Ceph的發布周期為三個月。

4. Sage Weil其人其事

在展開后續的技術討論之前，適度八卦Sage Weil的人生經歷實在是很有必要，因為這位兄臺委實是 IT男青年中鳳毛麟角的在工程、研究、創業三個領域都有涉獵且都頗有建樹的神人。

Sage在工程上的能力自然不必多言，而他發表Ceph論文的OSDI也是計算機操作系統領域首屈一指的最高水平學術會議。至于創業方面，Sage是 DreamHost的聯合創始人，彼時是1997年，他剛上大學不久。。。有興趣的同學可以去LinkedIn研究一下Sage的個人簡歷，基本上是想工作就工作，想上學就上學，想創業就創業，想讀博就讀博，隨心所欲，天馬行空，令人油然而生一種表示敬佩的沖動。

Ceph的設計思想

分析開源項目，時常遇到的一個問題就是資料不足。有時間寫代碼的大牛們通常是都是沒有時間或者根本不屑于寫文檔的。而不多的文檔通常又是使用手冊之類的東西。即便偶爾有設計文檔通常也是語焉不詳。在這種情況下，想從代碼里反向把設計思想提煉出來，畢竟不是人人都能做到的。

值得我們慶幸的是，Ceph是一個典型的起源于學術研究課題的開源項目。雖然學術研究生涯對于Sage而言只是其光輝事跡的短短一篇，但畢竟還是有幾篇學術文獻可供參考。這也為我們提供了難得的，從頂層視角入手分析一個系統領域的優秀開源項目的機會。本篇文章的內容也正是筆者閱讀這些文獻的心得體會。

1. Ceph針對的目標應用場景

理解Ceph的設計思想，首先還是要了解Sage設計Ceph時所針對的目標應用場景，換言之，“做這東西的目的是啥？”

事實上，Ceph最初針對的目標應用場景，就是大規模的、分布式的存儲系統。所謂“大規模”和“分布式”，是指至少能夠承載PB級別的數據，并且由成千上萬的存儲節點組成。

在大數據口號深入人心的今天，PB已經遠遠不是一個激動人心的系統設計目標了。但是，應該指出，Ceph項目起源于04年。那是一個商用處理器以單核為主流，常見硬盤容量只有幾十GB的年代。這和現在動輒6核12線程還要雙處理器、單塊硬盤3TB已經司空見慣的情況是不可同日而語的。因此，理解這個設計目標，應該考慮當時的實際情況。當然，如前所述，Ceph的設計并沒有理論上限，所以PB級別并不是實際應用的容量限制。

在Sage的思想中，對于這樣一個大規模的存儲系統，是不能以靜態的眼光來看待的。對于其動態特性，筆者概括為如下三個“變化”：

1. 存儲系統規模的變化：這樣大規模的存儲系統，往往不是在建設的第一天就能預料到其最終的規模，甚至是根本就不存在最終規模這個概念的。只能是隨著業務的不斷開展，業務規模的不斷擴大，讓系統承載越來越大的數據容量。這也就意味系統的規模自然隨之變化，越來越大。
2. 存儲系統中設備的變化：對于一個由成千上萬個節點構成的系統，其節點的故障與替換必然是時常出現的情況。而系統一方面要足夠可靠，不能使業務受到這種頻繁出現的硬件及底層軟件問題的影響，同時還應該盡可能智能化，降低相關維護操作的代價。
3. 存儲系統中數據的變化：對于一個大規模的，通常被應用于互聯網應用中的存儲系統，其中存儲的數據的變化也很可能是高度頻繁的。新的數據不斷寫入，已有數據被更新、移動乃至刪除。這種場景需求也是設計時必須予以考慮的。

上述三個“變化”就是Ceph目標應用場景的關鍵特征。Ceph所具備的各種主要特性，也都是針對這些場景特征所提出的。

2. 針對目標應用場景所提出的預期技術特性

針對上述應用場景，Ceph在設計之初的幾個技術特性是：

1. 高可靠性。所謂“高可靠”，首先是針對存儲在系統中的數據而言，也即，盡可能保證數據不會丟失。其次，也包括數據寫入過程中的可靠性，也即，在用戶將數據寫入Ceph存儲系統的過程中，不會因為意外情況的出現造成數據丟失。
2. 高度自動化。具體包括了數據的自動replication，自動re-balancing，自動failure detection和自動failure recovery。總體而言，這些自動化特性一方面保證了系統的高度可靠，一方面也保障了在系統規模擴大之后，其運維難度仍能保持在一個相對較低的水平。
3. 高可擴展性。這里的“可擴展”概念比較廣義，既包括了系統規模和存儲容量的可擴展，也包括了隨著系統節點數增加的聚合數據訪問帶寬的線性擴展，還包括了基于功能豐富強大的底層API提供多種功能、支持多種應用的功能性可擴展。

3. 針對預期技術特性所提出的設計思路

針對3.2節中介紹的預期技術特性，Sage對于Ceph的設計思路基本上可以概括為以下兩點：

1. 充分發揮存儲設備自身的計算能力。事實上，采用具有計算能力的設備（最簡單的例子就是普通的服務器）作為存儲系統的存儲節點，這種思路即便在當時來看也并不新鮮。但是，Sage認為這些已有系統基本上都只是將這些節點作為功能簡單的存儲節點。而如果充分發揮節點上的計算能力，則可以實現前面提出的預期特性。這一點成為了Ceph系統設計的核心思想。
2. 去除所有的中心點。一旦系統中出現中心點，則一方面引入單點故障點，另一方面也必然面臨當系統規模擴大時的規模和性能瓶頸。除此之外，如果中心點出現在數據訪問的關鍵路徑上，事實上也比然導致數據訪問的延遲增大。而這些顯然都是Sage所設想的系統中不應該出現的問題。雖然在大多數系統的工程實踐中，單點故障點和性能瓶頸的問題可以通過為中心點增加備份加以緩解，但Ceph系統最終采用創新的方法更為徹底地解決了這個問題。

4. 支撐設計思路實現的關鍵技術創新

無論多么新穎奇妙的設計思路，最終落地必定需要有技術實力的支撐。而這也正是Ceph最為閃亮的地方。

Ceph最為核心的技術創新就是前面所概括的八個字――“無需查表，算算就好”。一般而言，一個大規模分布式存儲系統，必須要能夠解決兩個最基本的問題：

一是“我應該把數據寫入到什么地方”。對于一個存儲系統，當用戶提交需要寫入的數據時，系統必須迅速決策，為數據分配一個存儲位置和空間。這個決策的速度影響到數據寫入延遲，而更為重要的是，其決策的合理性也影響著數據分布的均勻性。這又會進一步影響存儲單元壽命、數據存儲可靠性、數據訪問速度等后續問題。

二是“我之前把數據寫到什么地方去了”。對于一個存儲系統，高效準確的處理數據尋址問題也是基本能力之一。

針對上述兩個問題，傳統的分布式存儲系統常用的解決方案是引入專用的服務器節點，在其中存儲用于維護數據存儲空間映射關系的數據結構。在用戶寫入/訪問數據時，首先連接這一服務器進行查找操作，待決定/查到數據實際存儲位置后，再連接對應節點進行后續操作。由此可見，傳統的解決方案一方面容易導致單點故障和性能瓶頸，另一方面也容易導致更長的操作延遲。

針對這一問題，Ceph徹底放棄了基于查表的數據尋址方式，而改用基于計算的方式。簡言之，任何一個Ceph存儲系統的客戶端程序，僅僅使用不定期更新的少量本地元數據，加以簡單計算，就可以根據一個數據的ID決定其存儲位置。對比之后可以看出，這種方式使得傳統解決方案的問題一掃而空。Ceph的幾乎所有優秀特性都是基于這種數據尋址方式實現的。

原文連接：

“Ceph淺析”系列之二――Ceph概況

“Ceph淺析”系列之三――Ceph的設計思想

---

以“ 云計算大數據 推動智慧中國 ”為主題的  第六屆中國云計算大會 將于5月20-23日在北京國家會議中心隆重舉辦。產業觀察、技術培訓、主題論壇、行業研討，內容豐富，干貨十足。票價優惠，馬上  報名 ！