Ceph針對的目標應用場景
理解Ceph的設計思想，首先還是要了解Sage設計Ceph時所針對的目標應用場景，換言之，“做這東西的目的是啥？”
事實上，Ceph最初針對的目標應用場景，就是大規模的、分佈式的存儲系統。所謂“大規模”和“分佈式”，是指至少能夠承載PB級別的數據，並且由成千上萬的存儲節點組成。
在大數據口號深入人心的今天，PB已經遠遠不是一個激動人心的系統設計目標了。但是，應該指出，Ceph項目起源於04年。那是一個商用處理器以單核爲主流，常見硬盤容量只有幾十GB的年代。這和現在動輒6核12線程還要雙處理器、單塊硬盤3TB已經司空見慣的情況是不可同日而語的。因此，理解這個設計目標，應該考慮當時的實際情況。當然，如前所述，Ceph的設計並沒有理論上限，所以PB級別並不是實際應用的容量限制。
在Sage的思想中，對於這樣一個大規模的存儲系統，是不能以靜態的眼光來看待的。對於其動態特性，筆者概括爲如下三個“變化”：
存儲系統規模的變化： 這樣大規模的存儲系統，往往不是在建設的第一天就能預料到其最終的規模，甚至是根本就不存在最終規模這個概念的。只能是隨着業務的不斷開展，業務規模的不斷擴大，讓系統承載越來越大的數據容量。這也就意味系統的規模自然隨之變化，越來越大。
存儲系統中設備的變化： 對於一個由成千上萬個節點構成的系統，其節點的故障與替換必然是時常出現的情況。而系統一方面要足夠可靠，不能使業務受到這種頻繁出現的硬件及底層軟件問題的影響，同時還應該儘可能智能化，降低相關維護操作的代價。
存儲系統中數據的變化： 對於一個大規模的，通常被應用於互聯網應用中的存儲系統，其中存儲的數據的變化也很可能是高度頻繁的。新的數據不斷寫入，已有數據被更新、移動乃至刪除。這種場景需求也是設計時必須予以考慮的。
上述三個“變化”就是Ceph目標應用場景的關鍵特徵。Ceph所具備的各種主要特性，也都是針對這些場景特徵所提出的。
針對目標應用場景所提出的預期技術特性
針對上述應用場景，Ceph在設計之初的幾個技術特性是：
高可靠性。 所謂“高可靠”，首先是針對存儲在系統中的數據而言，也即，儘可能保證數據不會丟失。其次，也包括數據寫入過程中的可靠性，也即，在用戶將數據寫入Ceph存儲系統的過程中，不會因爲意外情況的出現造成數據丟失。
高度自動化。 具體包括了數據的自動replication，自動re-balancing，自動failure detection和自動failure recovery。總體而言，這些自動化特性一方面保證了系統的高度可靠，一方面也保障了在系統規模擴大之後，其運維難度仍能保持在一個相對較低的水平。
高可擴展性。 這裏的“可擴展”概念比較廣義，既包括了系統規模和存儲容量的可擴展，也包括了隨着系統節點數增加的聚合數據訪問帶寬的線性擴展，還包括了基於功能豐富強大的底層API提供多種功能、支持多種應用的功能性可擴展。
針對預期技術特性所提出的設計思路
針對3.2節中介紹的預期技術特性，Sage對於Ceph的設計思路基本上可以概括爲以下兩點：
充分發揮存儲設備自身的計算能力。 事實上，採用具有計算能力的設備（最簡單的例子就是普通的服務器）作爲存儲系統的存儲節點，這種思路即便在當時來看也並不新鮮。但是，Sage認爲這些已有系統基本上都只是將這些節點作爲功能簡單的存儲節點。而如果充分發揮節點上的計算能力，則可以實現前面提出的預期特性。這一點成爲了Ceph系統設計的核心思想。
去除所有的中心點。 一旦系統中出現中心點，則一方面引入單點故障點，另一方面也必然面臨當系統規模擴大時的規模和性能瓶頸。除此之外，如果中心點出現在數據訪問的關鍵路徑上，事實上也必然導致數據訪問的延遲增大。而這些顯然都是Sage所設想的系統中不應該出現的問題。雖然在大多數系統的工程實踐中，單點故障點和性能瓶頸的問題可以通過爲中心點增加備份加以緩解，但Ceph系統最終採用創新的方法更爲徹底地解決了這個問題。
支撐設計思路實現的關鍵技術創新
無論多麼新穎奇妙的設計思路，最終落地必定需要有技術實力的支撐。而這也正是Ceph最爲閃亮的地方。
Ceph最爲核心的技術創新就是前面所概括的八個字——“無需查表，算算就好”。一般而言，一個大規模分佈式存儲系統，必須要能夠解決兩個最基本的問題：
一是“我應該把數據寫入到什麼地方”。 對於一個存儲系統，當用戶提交需要寫入的數據時，系統必須迅速決策，爲數據分配一個存儲位置和空間。這個決策的速度影響到數據寫入延遲，而更爲重要的是，其決策的合理性也影響着數據分佈的均勻性。這又會進一步影響存儲單元壽命、數據存儲可靠性、數據訪問速度等後續問題。
二是“我之前把數據寫到什麼地方去了”。 對於一個存儲系統，高效準確的處理數據尋址問題也是基本能力之一。
針對上述兩個問題，傳統的分佈式存儲系統常用的解決方案是引入專用的服務器節點，在其中存儲用於維護數據存儲空間映射關係的數據結構。在用戶寫入/訪問數據時，首先連接這一服務器進行查找操作，待決定/查到數據實際存儲位置後，再連接對應節點進行後續操作。由此可見，傳統的解決方案一方面容易導致單點故障和性能瓶頸，另一方面也容易導致更長的操作延遲。
針對這一問題，Ceph徹底放棄了基於查表的數據尋址方式，而改用基於計算的方式。簡言之，任何一個Ceph存儲系統的客戶端程序，僅僅使用不定期更新的少量本地元數據，加以簡單計算，就可以根據一個數據的ID決定其存儲位置。對比之後可以看出，這種方式使得傳統解決方案的問題一掃而空。Ceph的幾乎所有優秀特性都是基於這種數據尋址方式實現的。
至此爲止，Ceph的設計思想已經得到了較爲全面深入的介紹。此後幾篇文章將依次介紹Ceph的系統架構、工作原理與流程、主要特性等內容，並聯系OpenStack，將Ceph和Swift加以對比分析。