「CEPH淺析」系列之三——CEPH的設計思想

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

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

3.1    Ceph針對的目標應用場景

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

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

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

        在Sage的思想中，對於這樣一個大規模的存儲系統，是不能以靜態的眼光來看待的。對於其動態特性，筆者歸納爲以下三個「變化」：

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

        上述三個「變化」就是Ceph目標應用場景的關鍵特徵。Ceph所具有的各類主要特性，也都是針對這些場景特徵所提出的。

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

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

• 高可靠性。所謂「高可靠」，首先是針對存儲在系統中的數據而言，也即，儘量保證數據不會丟失。其次，也包括數據寫入過程當中的可靠性，也即，在用戶將數據寫入Ceph存儲系統的過程當中，不會由於意外狀況的出現形成數據丟失。
• 高度自動化。具體包括了數據的自動replication，自動re-balancing，自動failure detection和自動failure recovery。整體而言，這些自動化特性一方面保證了系統的高度可靠，一方面也保障了在系統規模擴大以後，其運維難度仍能保持在一個相對較低的水平。
• 高可擴展性。這裏的「可擴展」概念比較廣義，既包括了系統規模和存儲容量的可擴展，也包括了隨着系統節點數增長的聚合數據訪問帶寬的線性擴展，還包括了基於功能豐富強大的底層API提供多種功能、支持多種應用的功能性可擴展。

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

        針對3.2節中介紹的預期技術特性，Sage對於Ceph的設計思路基本上能夠歸納爲如下兩點：

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

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

        不管多麼新穎奇妙的設計思路，最終落地一定須要有技術實力的支撐。而這也正是Ceph最爲閃亮的地方。

        Ceph最爲核心的技術創新就是前面所歸納的八個字——「無需查表，算算就好」。通常而言，一個大規模分佈式存儲系統，必需要可以解決兩個最基本的問題：

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

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

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

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

        至此爲止，Ceph的設計思想已經獲得了較爲全面深刻的介紹。此後幾篇文章將依次介紹Ceph的系統架構、工做原理與流程、主要特性等內容，並聯系OpenStack，將Ceph和Swift加以對比分析。

說明：轉載請註明出處。謝謝。