如何學習開源專案及Ceph的淺析

學習各種開源專案，已經成為很多朋友不可迴避的工作內容了。筆者本人也是如此。在接觸並學習了若干個開源專案之後，筆者試圖對自己工作過程中的若干體會加以總結，以期對一些希望借鑑的朋友有所裨益。

需要說明的是，筆者本人接觸的開源專案大多屬於計算機系統領域，例如Linux kernel，KVM，QEMU，OpenStack等。因此，此處介紹的經驗必定也有些侷限。請讀者們自行分辨，區別對待。

1. 學習分層和目標管理 

對於一個開源專案，可以將與之相關的各種知識和技能的學習大致劃分為如下五個層次： 

第一層次：瞭解專案的基本概念、基本用途、邏輯結構、基本原理、產生背景、應用場景等基本知識。 

這個層次的基本定位其實就是“科普”。如果對於一個專案只需要有些基本瞭解，且短期內並不需要上手進行實際技術工作，則學習到這個層次也就可以先應付一下了。 

第二層次：掌握專案的基本安裝流程和使用方法。 

這個層次的基本定位是“入門”，以便對這個專案獲得直觀認識，對其安裝和使用獲得親身體驗。如果只是需要以as-is方式使用這個專案，則初步學習到這個層次即可。 

第三層次：瞭解程式碼的組織，找到各個主要邏輯/功能模組與程式碼檔案之間的對應關係，通過程式碼分析走通幾個關鍵的、有代表性的執行流程。 

這個層次的基本定位是“深入”，開始理解這個專案的實際實現，能夠真正將專案的功能、工作原理和程式碼實現對應起來，獲得對這個專案工作過程的直觀認識。這個層次是學習開源專案程式碼的真正開始。如果希望基於這一專案進行應用開發，或者針對與這一專案密切相關的其他專案進行工作時，則對專案本身的程式碼進行這一層次的理解，會很有幫助。 

第四層次：瞭解該專案所有程式碼模組、程式檔案的作用，走通所有主要執行流程。 

這個層次的基本定位是“掌握”，能夠比較全面、系統地理解這個專案的設計和實現，並且熟悉專案各個部分的程式碼。如果希望對專案進行深度定製修改，或者對社群有所貢獻，則應當以達到這個層次作為目標。 

第五層次：鑽研、領悟該專案的各種設計思想與程式碼實現細節。 

這個層次的基本定位是“精通”，精益求精，學無止境。這是大神們追求的境界。如果希望成為專案社群的重要貢獻者乃至核心貢獻者，則應當以這個層次作為努力的目標。 

綜上，對於一個開源專案的學習過程可以大致分為五個層次。至於到底要學習到什麼階段，投入多少相關精力，則完全取決於學習的目的。 

2. 知識基礎 

學習一個開源專案需要的知識基礎主要包括： 

1）該專案涉及的技術領域的背景知識 

舉例而言，分析Linux Kenrel，則應該瞭解作業系統原理；學習OpenStack，則應該知道什麼是雲端計算。如果沒有這些背景知識作為基礎，上來就死磕原始碼，只能是事半功倍。 

2） 該專案開發使用的語言及其各種開發除錯工具 

這個就無需多言了。 

3） 英語 

很遺憾，目前為止真正流行的開源專案大部分不是起源於國內。因此，除了學習個別極其流行、文件完備的專案之外，大家還是需要自行蒐集閱讀英文資料參考。學好英語很重要。 

當然，到底需要準備多少知識基礎，完全取決於學習的目的和層次。如果只是想科普一下，也就不必太過麻煩了。 

3. 學習思路 

學習一個專案的過程，其實就是由表及裡瞭解分析它的過程。上述提及的五個學習層次便組成了這樣一個逐漸深入的過程。在此基礎之上，學習、分析程式碼的過程，也可以嘗試做到由表及裡、逐漸深入。 

在剛開始接觸一個專案的時候，我們看到的其實就是一個黑盒子。根據文件，我們一定會發現盒子上具有若干對外介面。通常而言，這些介面可以被分為三類： 

• 配置介面：用於對盒子的工作模式、基本引數、擴充套件外掛等等重要特性進行配置。這些配置往往是在盒子啟動前一次性配好。在盒子的工作過程中，這些配置或者不變，或者只在少數的情況下發生改變。 
  
• 控制介面：用於在盒子的工作過程中，對於一些重要的行為進行操縱。這是盒子的管理員對盒子進行控制命令注入和狀態資訊讀取的通路。 
  
• 資料介面：用於盒子在工作過程中讀取外部資料，並在內部處理完成後向外輸出資料。這是盒子的使用者真正關心的資料通路。 
  

因此，在分析一個開源專案的程式碼時，可以圍繞重要的配置、控制、資料介面展開分析工作，特別應該注意理解一個關鍵的介面背後隱藏的操作流程。例如，針對資料介面，至少應當走通一條完整的資料輸入輸出流程，也即在程式碼中找到資料從輸入介面進入盒子後，經過各種處理、轉發步驟，最終從輸出介面被傳輸出去的整個執行過程。一旦走通了這樣一條流程，則可以將與資料處理相關的各個主要模組、主要步驟貫穿起來，並將邏輯模組圖上和文件中的抽象概念對應到程式碼實現之中，可以有效推進對於專案的深入理解。 

在實踐這一思路的過程中，筆者建議可以優先從控制介面和資料介面中各自選擇一二重要者進行背後的執行流程詳細分析，力爭找到其中每一步的函式呼叫及資料傳遞關係（對於一些系統、應用庫提供的底層函式可以先行跳過以節省時間）。這一工作完成之後，則第1節中第三層次的學習目標即可初步達成。 

配置介面在不同的專案中的重要程度不同。對於一些架構極為靈活、配置空間甚大的專案（如OpenStack的Ceilometer），則可以適當多花些時間加以研究，否則簡單瞭解即可。 

對於這個學習思路，下文中還將結合例項進行進一步的說明。 

4. 若干小建議 

以下是筆者的一些零散建議，供大家參考。 

1）做好記錄 

在剛剛入手開始學習某個專案的原始碼時，其實很有點破譯密碼的感覺。大量的資料結構和函式方法散落在程式碼的各個角落裡，等待著學習者將它們貫穿到一個個重要的執行流程中。因此，在分析學習的過程中，無論有什麼零散收穫，都值得認真記錄下來。珍珠自然會串成項鍊的。 

2）不要過分糾纏於細節 

立志搞懂一個專案的每行原始碼是值得尊敬的，但至少在剛剛入手的時候是沒有必要的。如果過於糾纏於程式碼的實現細節，則可能很快就被搞得頭暈眼花不勝其煩了（看英文資料的時候，每遇到一個不認識的詞都要立刻查詞典麼？）。不妨避免細節上的過度糾纏，還是先儘快走通關鍵的執行流程，將專案的骨幹框架搭起來，然後再以此為參照，就可以清晰判斷什麼程式碼值得深入分析，什麼地方可以簡單略過了。 

3）想像和聯想很重要 

如前所述，從零開始搞懂一個專案的程式碼，就像破譯密碼。因此，不妨展開合理的想象和聯想，將各個零散的發現和理解聯絡起來，並加以分析印證。在這個過程中，對專案所在領域的背景知識、對專案本身的邏輯框架和工作原理等方面的理解，都是想像和聯想的參照與指導。此外，一些關鍵的函式名、變數名等等都是聯想的hint。本質上，程式語言也是語言，而程式程式碼就是說明文。在分析程式碼時，一定要超越語言和程式碼的細節去理解被說明的事物本身。 

4）該搜就搜 

分析程式碼的時候，很容易出現的情況就是，一個執行流程走到半截找不到下一步了。。。在這種情況下，當然首先還是推薦採用各種除錯工具的單步執行功能加以跟蹤。如果暫時不會，或者種種原因只能進行靜態程式碼分析，那麼該搜就搜吧。各種IDE工具的文字搜尋都能用，哪怕是grep也行。至於到底以什麼為搜尋關鍵詞，就需要琢磨琢磨了。 

5）外事不決問google，內事不決問百度 

如題，不解釋。 

5. 一個例子：OpenStack Cinder分析 

此處將以OpenStack Cinder為例，並結合KVM/Qemu和Ceph，說明如何參考上述思路對一個開源專案進行分析。 

可能有朋友奇怪為什麼選這麼個東東做例子。這個吧。。。寫文章時忽發起想，舉例子是隨手抓來。木有原因。。。 

首先，想對Cinder進行分析，一定要了解若干相關的基礎知識。什麼是雲端計算？什麼是塊儲存？什麼是OpenStack？Cinder在OpenStack裡的作用？等等等等。如果對這些東西沒有概念，則後續學習是很難開展下去的。 

在此基礎上，如果有條件，則最好能夠親自部署和實際操作一下Cinder（包括必要的其他OpenStack元件），以便對Cinder獲得一個直觀的認識和體驗，為後續分析提供一些參考。此處假定Cinder使用的後端是Ceph，而OpenStack上執行的虛擬機器是KVM。 

然後，應該從概念上對我們要分析的系統的邏輯框架有個理解。從總體的範疇上講，應該瞭解Horizon和Nova各自的邏輯模組結構，以及它們和Cinder的協同工作方式、關係。這部分與Cinder的控制介面及執行路徑分析密切相關。此外，還應該瞭解Cinder和KVM/QEMU、Ceph之間的相互關係。這對於真正理解Cinder很有幫助。從Cinder自身而言，應該瞭解其內部邏輯模組構成、各自的功能、相互間的控制、資料連線關係等。 

在完成上述準備之後，則可以開始對Cinder的程式碼進行分析了。如前所述，應該考慮在控制介面和資料介面中各自選擇一兩個關鍵的、有代表性的加以分析。至於配置介面，假定其實現了某一配置即可，暫時不需要過多花費時間。 

Cinder的核心功能其實是OpenStack上的volume管理。至少在Cinder+Ceph方案中，Cinder自身並不在資料傳輸關鍵路徑上。因此，控制介面的分析就是Cinder原始碼分析的重中之重。就入手階段而言，則有兩個介面及其對應執行流程可以作為Cinder分析的起點，即volume的create和attach操作。如果能夠徹底打通這兩個操作的執行流程（至少要看到Cinder與Ceph通過librbd互動的層面），則對於真正理解Cinder的功能與實現大有幫助。 

雖然基於KVM的虛擬機器在通過QEMU訪問Cinder建立的、Ceph提供的volume時並不通過Cinder，也即，這一部分的原始碼其實已經超出了Cinder原始碼學習的範疇，但是，如果希望真正徹底地理解Cinder，則對於這一部分知識還是應該有所涉獵，至少應該有概念上的瞭解。 

在達到上述階段之後，則可以根據自身的需求決定後續計劃了。 

作為OpenStack的人氣儲存技術之一，Ceph與Swift和GlusterFS一樣有著各自的優勢：GlusterFS更適合Hadoop型別的服務；Swift適合更多人訪問；Ceph的未來更被看好，並已得到許多知名機構的支援，比如CERN和天河2。

在之前，我們已經分享過張宇Ceph系列博文的前兩部分“ Ceph淺析（上）：概況與設計思想”與“Ceph淺析（中）：結構、工作原理及流程”，這裡我們將分享該系列博文的最後一部分：

Ceph與OpenStack

在前文概況中即已提到，關注Ceph的原因之一，就是OpenStack社群對於Ceph的重視。因此，本文將對Ceph在OpenStack中的價值進行簡要介紹，並且對Ceph和Swift進行對比。

1. Ceph在OpenStack中的地位

對於一個IaaS系統，涉及到儲存的部分主要是塊儲存服務模組、物件儲存服務模組、映象管理模組和計算服務模組。具體針對OpenStack而言，則分別對應為其中的Cinder、Swift、Glance和Nova四個專案。

在塊儲存服務部分，Ceph目前是Cinder專案的預設儲存後端。前已述及，Red Hat也已經利用自己在KVM/QEMU社群中的影響力，將RBD驅動直接整合在QEMU中。這樣，虛擬機器訪問基於RBD實現的塊裝置的效能將得到優化。

在物件儲存部分，Swift是OpenStack自帶的物件儲存實現方案。但Ceph也已經成為了Swift最強有力的競爭對手。目前Swift也在考慮採用Ceph作為自己的儲存後端。關於Ceph和Swift的故事將在6.2節詳細展開。

在映象管理部分，目前Glance已經支援將Ceph作為自己的本地映象檔案快取。

在計算服務部分，United Stack目前正在推動將Ceph FS作為Nova計算節點的本地檔案系統。

整體而言，Ceph事實上是目前OpenStack生態系統中呼聲最高的開源儲存解決方案。這一點從筆者在OpenStack 2013 HongKong Summit上的親身體驗可以得到印證。目前，以HP、Dell、Intel等為代表的企業IT領導廠商，和以Mirantis、eNovance、United Stack為代表的若干OpenStack社群新興廠商，都將Ceph作為重要的乃至於首選的開源儲存解決方案。

筆者認為，Ceph之所以在誕生多年不溫不火的情況下，迅速在OpenStack社群中受到關注，除了其他一些明顯優點之外，應該還是和其支援統一儲存的能力有關。這一特性恰恰是OpenStack社群所需要的。

OpenStack專案設計的準則之一就是靈活可擴充套件。同時，其各個成員專案的背景也不盡相同。這也就導致各個專案在涉及儲存系統時所採取的選擇各有差異。但是，這一現狀勢必導致OpenStack的部署和運維面臨一定的挑戰。特別是對於一些規模不大的OpenStack部署例項，如果讓塊儲存、物件儲存、映象快取、計算節點本地儲存等模組分別採用三四種不同的後端解決方案，則一方面其部署十分麻煩，另一方面運維人員的後續工作也很繁瑣。在這種情況下，如果能夠採用Ceph作為一種統一儲存後端，則確實可以有效緩解這一問題。當然，這只是筆者的一家直言。任何技術選擇必然都有其複雜的背後原因，這裡的資訊僅供參考。

2. Ceph與Swift：不能不說的故事，不能不作的比較

首先對Swift專案的來龍去脈進行簡單介紹，以便大家更好地瞭解這個專案的特性，及其背後隱藏的原因。此處關於Swift的資訊主要引自。

Swift最早起源於2008年，本來是Rackspace公司內部開發的用於支撐其公有云物件儲存業務的後端系統。當時，Amazon的S3服務已經頗受歡迎，因此，Rackspace決定開發Swift以提供對應業務作為回應。也正是因為這個原因，Swift的設計目標十分純粹，就是一個優秀的、可以和S3相媲美的物件儲存系統。其他要求純屬多餘，因此完全不在Swift開發者的考慮之列。 

Swift的開發大致歷時一年，並在Rackspace成功上線運營。此後，OpenStack專案於2010年正式釋出。Rackspace貢獻了Swift，而NASA貢獻了Nova，二者成為了OpenStack最早的兩個專案。其後，若干Swift開發團隊的核心成員獨立創業，成立了SwiftStack公司，依然活躍在相關社群。 

由此可見，Swift正是一個典型的起源於公司內部的、作為正式產品開發的開源專案。從這一點而言，Swift和“學院範兒”的Ceph可謂截然不同。也正是因為這個原因，Swift獲得了一個得天獨厚的優勢：不缺啟動使用者，一開始就有生產環境下的大規模部署應用案例。事實上，相對成熟、web場景下應用案例多，是Swift社群目前依然反覆強調的一個優勢。 

從技術上講，Swift的特點主要體現在設計目標明確，就是要做一個純粹的物件儲存系統，因此不會考慮Ceph所強調的統一儲存特性。同時，為了便於和其他專案、應用整合，Swift選擇了Python語言進行開發。 

與之相比，Ceph同時考慮了物件儲存、塊儲存和檔案系統儲存能力，且目前在OpenStack中應用最多的場景事實上是塊儲存。同時，Ceph在選擇開發語言時，很可能主要考慮的是效能因素，因而選擇了C++語言。而能夠被用於塊儲存場景這一點，也部分印證了其效能確實比較優秀。 

由此可見，Ceph和Swift的區別，本質上是由其產生背景和應用目標所導致的。對這二者進行對比，並進行技術上的評判，並不非常公平。 

事實上，作為開源分散式儲存系統中的兩個優秀代表，Ceph和Swift的設計和特性之中，也有著不少的相通之處： 

首先，二者都強調良好的可擴充套件性，因此都採用了無中心點結構。只不過Swift的架構中有後設資料伺服器，只是通過多節點擴充套件的方式儘可能解決了其可靠性和效能顧慮。 

第二，二者都能提供可配置的高可靠性。在兩者的叢集中，資料的備份數都可以選擇，在常見生產環境中，也都使用三備份的方式。 

第三，二者都強調自動化的叢集管理。Swift同樣引入了自動化的叢集維護能力。

由此可見，簡單地強調這兩者之中的某一個更為優秀，是不合理的，也是沒有實際意義的。 

當然，在實際使用中，畢竟還是需要進行方案選擇。結合[3]文中的觀點，筆者認為，合適的選擇或許如下： 

• 如果需要一個純粹的物件儲存系統，則選擇Swift；
• 如果需要一個純粹的塊儲存系統，則只能選擇Ceph； 
• 如果是一個小規模的、希望控制系統複雜度的OpenStack部署方案，則選擇Ceph；
• 如果是一個規模較大的系統，塊儲存和物件儲存分別有較大的業務需求，則可以考慮將二者分離，分別採用Ceph和Swift。 

關於Ceph的若干想法

本節的內容，主要是筆者在調研分析Ceph過程中產生的一些思考。因為其中的內容比較自由發散，且大多是筆者的個人見解，故此另啟一文進行討論。

1. 關於Ceph的效能

目前為止，本系列的文章中沒有涉及到Ceph效能的詳細討論，也沒有給出任何的Ceph效能資料。原因很簡單：筆者本人沒有機會進行詳盡的Ceph效能分析研究，也沒有見到比較全面的相關資料。因此，為了避免以片面的資料誤導讀者，便沒有提供任何資訊。

以筆者個人的經驗而言，探討一個系統領域的開源專案的效能，事實上並不容易。其原因在於，影響一個實際部署中系統的效能好壞的因素太多、太複雜。硬體配置、軟體版本、引數調整、應用負載及場景設定，各個方面的因素變化都會導致效能測試結果的不同。因此，很難一言蔽之，認為某個專案的效能是好還是不好。

舉一個不直接相關的例子。在hypervisor領域，大家很可能會傾向於認為ESXi的效能優於KVM，但事實上，在SPECvirt效能測試結果排行榜上，基於KVM的系統常有高居第一的時候。究其原因，除了硬體效能的因素之外，KVM有大量的配置引數可以調整，而調得好與不好會極其明顯地影響系統效能。

又比如常用的開源大資料工具軟體Hadoop。同一個Hadoop叢集用同樣的應用程式處理同樣的資料集，在配置引數不同的情況下，其最終執行時間長度可能相差數倍。

正是因為引數配置、硬體規格、軟體版本、應用場景等因素都可能對效能產生明顯影響，因此，對於Ceph這樣一個部署方案多變、配置引數不少的系統，如何評測其系統效能，是需要審慎思考的

反過來講，這倒也是開源軟體引出的一個生財之道。雖然軟體本身是開源的，大家都可以免費下載免費安裝，但能不能用好就要依靠精深的專業技能了。類似的公司國外屢見不鮮，而國內也已經開始出現。

2. Ceph的架構與硬體平臺之間的適應性

Ceph自2006年正式釋出以來，其基礎架構（RADOS）部分並沒有發生大的變化。本質上，這還是因為RADOS的設計確實優秀，有其前瞻性，因此沒有必要大動筋骨。但這並不意味著沒有必要對其進行適當反思。

如前所述，2006年的時候，商用處理器的主流仍為單核，單條記憶體和單塊硬碟的容量也都遠小於現在的主流水平。但是，OSD的基本硬體資源要求並沒有發生變化。這也就意味著，在目前的典型部署方案中，一臺物理伺服器上很可能有數十個處理器硬體執行緒、數十塊硬碟，於是也就承載著數十個OSD同時執行。然而，RADOS結構的基本假定是，叢集是由大量的、相互獨立執行的OSD組成的，則目前的典型硬體方案有可能影響這種假定的有效性。例如，如果一臺伺服器出現故障，必須關機進行維修，則意味著數十個OSD一起突然下線。由此受到影響的PG則可能多達成千上萬個。這種突發性的事件對系統的自動化維護機制可能會造成一定的壓力。

由此，筆者想到，Sage設計Ceph時面對的硬體平臺，事實上應該是處理能力不需要過強、硬體規格比較簡單的系統。而這種系統可能與目前的ARM架構或者Intel Atom架構的micro-server更為相似。或許，基於micro-server部署Ceph叢集，會是一種值得嘗試的方向。

此外，華為和希捷合作推出了IP硬碟產品。雖然還缺乏更進一步的瞭解，但直觀上推測，這種全新的、輕量級、智慧化的儲存裝置，可能也是一種非常近似於Sage當年設想中的OSD的硬體平臺。

3. Ceph與軟體定義儲存

“軟體定義”這四個字可謂是目前最炙手可熱、也最讓人糊塗的概念之一。軟體定義計算、軟體定義網路、軟體定義儲存、軟體定義資料中心，以上幾個可能是目前最為常見的相關名詞了。

到底什麼是“軟體定義”，現在還沒有形成完全一致的見解。並且，參考技術發展史上的若干先例，以後也未必能形成所謂的一致見解。在這種情況下，以一個具體例項入手，可能更容易獲得直觀認識，並由此建立起更系統的觀點。

筆者認為，對於任何一個系統而言，“軟體定義”的概念，更多體現在這裡：這個系統的哪些特性，比如功能或者效能，以前是固定的，或者只能進行有限的配置，而現在則可以進行方便靈活地定義和改變。

例如，對於一臺物理伺服器，一旦其硬體配置，如CPU、記憶體、硬碟等連線好，則這臺伺服器的規格和效能就確定了，能夠通過BIOS配置等方式調整的效能和功能範圍是很有限的。但是，對於一臺虛擬機器而言，即便在虛擬機器已經建立並安裝了作業系統之後，其CPU核數及處理能力、邏輯實體記憶體大小及真實實體記憶體大小、硬碟數量容量及讀寫效能、網路卡型號數量及網路頻寬等等特性都是可以方便靈活地通過軟體方式進行控制和改變的（其中部分配置操作需要對虛擬機器進行重啟才能生效），且這種配置可以由應用層軟體進行控制。兩相對比，則虛擬機器的這種可定義性就是軟體定義計算的一個直觀例項。

下面再具體到儲存領域加以討論。一般而言，一個儲存系統的主要特性大致包括：儲存型別（檔案系統？塊儲存？物件儲存？），儲存容量，儲存效能（訪問頻寬、訪問延遲等等），儲存策略（備份策略、訪問安全性策略、對資料的高階處理功能等等）。參考上面所舉出的軟體定義計算的例子，可以想見，對於一個軟體定義儲存系統而言，這些特性（至少是其中的大多數）都應該是可以通過軟體方式加以定義的。

具體到Ceph而言，其最為符合軟體定義儲存的特性無疑是，Ceph的儲存型別是可以通過軟體方式定義的。同樣的一個RADOS叢集，可以通過安裝不同的上層軟體和對應的客戶端程式，實現塊儲存、物件儲存和檔案系統儲存功能，這一特性對於傳統的儲存系統難以想象。除此之外，Ceph的儲存策略，如備份策略、後臺資料處理功能等，也都可以方便地通過軟體方式加以定義或擴充套件。因此，從這個角度出發，Ceph也可以被認為是軟體定義儲存的真實案例之一。

4. Ceph與資料中心計算

傳統意義上，計算系統的設計是以計算為中心的。資料從儲存、網路或其他裝置流入處理器，經過處理後再流向儲存、網路或其他裝置。然而，隨著待處理的資料量以爆炸式的速度增大，也隨著計算能力提高的速度超過儲存和傳輸能力，這一處理方式可能變得不再經濟，因為針對大量的資料進行頻繁硬碟存取和網路傳輸的代價都是非常可觀的。

資料中心計算這一概念，也就是在這種背景下被提出的。其核心思想，也就是讓計算在資料所在的地方發生。資料在哪裡，就把計算任務傳送到哪裡去執行，而不要再為了使用“強大”的計算能力把資料搬來搬去，傳來傳去。事實上，Hadoop的出現，就是這種資料中心計算思想的現實反映。

資料中心計算的另一例項，是目前OpenStack社群中出現的一種叫做ZeroVM的輕量級虛擬化技術。ZeroVM的思想就是讓計算髮生在資料所在的地方。基於其官方提供的資訊，目前已經實現了ZeroVM和Swift的整合，可以讓處理任務直接執行在Swift的伺服器端。

事實上，Ceph也提供了同樣的能力。Ceph的整個設計，都是基於Sage的一個基本思想：充分發揮儲存器件自身的計算能力。這種思想不僅使得OSD可以相互配合完成資料訪問操作和叢集維護功能，更允許OSD將富餘的計算能力提供出來，用於執行資料處理任務。

目前，RADOS提供的機制允許在OSD上直接執行可動態載入的資料處理程式外掛，以便在伺服器端進行資料處理工作，例如，對圖片儲存系統中的圖片進行自動加水印、尺寸和格式自動轉換等後臺操作。事實上，基於這種能力，也完全可以實現類似於Hadoop的大資料處理系統。

對於大資料而言，儲存和處理是其兩個關鍵的技術領域。由於Ceph自身就是優秀的儲存系統，又具備直接承載計算任務的能力，因此，面向大資料的資料中心計算很可能是Ceph的潛在應用方向之一。

5. Ceph在實際應用中可能存在的問題

到目前位置，本系列文章基本上都是在介紹Ceph的各種優勢與特長。但是，任何系統都不可能是十全十美的，本著雞蛋裡挑骨頭、吹毛求疵的精神，還是要在這裡吐槽幾句。

從非技術角度出發，Ceph的最大問題是火起來的時間不夠長，因此可以參考的文件還不是很多，中文的尤其如此。但這個沒有辦法，只能眾人拾柴火焰高，一點一滴作貢獻。

此外，對Ceph詬病最多的可能還是不夠成熟云云。但一個開源專案總是用得人多了才會成熟的，而Ceph目前正在這個過程中，所以需要的還是時間和參與。

另外，以筆者的感覺，Ceph的高度自動化可能也是個雙刃劍。好處固然是很多的，但弊端就是系統的執行狀態不完全在管理員控制之下，系統中會有若干自動觸發而不是管理員觸發的操作。這個特點可能會給系統狀態的監測和控制帶來一些複雜度，需要管理員去適應。

6. 基於Ceph的產業需求和可能的商業機會

特此宣告：這一節的內容純屬crazy idea，不構成投資建議:-)

首先，Ceph的安裝部署和效能優化必然成為突出的需求。因此，將Ceph和商用伺服器整合成易於部署、效能出色的各類儲存解決方案，應該是可以考慮的方向之一。

同時，由於Ceph自身對於OSD硬體平臺的特殊假設，以及由此導致的優化空間，則在成本合理的前提下，開發更加適用於Ceph OSD的定製硬體平臺（類似於micro-server或者IP硬碟等），並突出儲存的高密度、低功耗、高可維護性等特點，也可能成為一種選擇。

此外，針對Ceph叢集的專用叢集監控、效能分析等工具軟體也可能會有一定的需求。

最後，基於Ceph的後臺資料處理軟體工具包也值得考慮。

總結

之 所以花這麼多時間在這些文章上，歸根結底還是因為Ceph是個有意思的東西，多看一看，多想一想，總能有些新收穫，很有趣。即便Ceph最終不能大紅大 紫，憑著其精彩的設計思想和巧妙的技術實現，應該還是會在儲存技術領域留下一筆的。如果Ceph能夠藉著OpenStack的東風，逐漸走向成熟，並受到 更為廣泛的接受和應用，則更是研究、工程、應用相互貫通的一個經典案例，值得認真研究。因此，無論從哪個角度出發，關注Ceph都是值得的。