華為章宇：如何學習開源項目及Ceph的淺析

【編者按】在 上一屆OpenStack Summit報道中，我們有提過，OpenStack已得到IBM、HP、RedHat等公司的鼎力支持，而截至2013年底， 在短短不到4年的時間，其社區已遍及全球132個國家，13504人參與，開發者人數更接近6000人，298家的支持廠商和機構，擁有8個白金會員、19個黃金會員、54個贊助公司、217個支持機構，北京更成為OpenStack開發者最多的城市。

毫無疑問，在得到了廣泛的支持后，OpenStack在飛快的成熟。然而，作為1個內容豐富、涉及眾多技術的開源IaaS平臺，就像【CSDN在線培訓】第三期中張小斌的分享：

開源并不意味著免費，豐富的插件并不一定最優。

OpenStack看似給我們提供了非常多的選項，但是如此多的選項往往讓企業眼花繚亂。

人人DIY固然可以集思廣益，但卻無法避免踩入陷阱。不深入了解，總會有意想不到的驚喜，如網絡不通，系統崩潰，性能低下，需求如何滿足等。

開源技術的學習和采用確實存在著一定門檻，然而坐擁寶山絕無空手而歸的道理，這里我們為大家分享 章宇的技術Blog，從開源項目學習到Ceph淺析。（ps：博客類型屬于個人博客，僅代表個人技術觀點，不代表任何公司或者實體）

博主資料：章宇于2002年及2007年分別于清華大學電子工程系獲得學士及博士學位，其后一直從事計算機系統領域的研究與開發工作，目前供職于華為技術有限公司云操作系統部門，從事OpenStack相關工作。出于工作原因和個人興趣，作者陸續關注了一些開源項目，主要包括：KVM/QEMU，libvirt，virt-mamager，OpenStack，Open vSwitch，Ceph，Zabbix等。

開源項目學習方法

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

需要說明的是，筆者本人接觸的開源項目大多屬于計算機系統領域，例如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，則對于這一部分知識還是應該有所涉獵，至少應該有概念上的了解。

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

ps：Ceph概況、設計思想、結構、工作原理及流程、與OpenStack關系等請訪問下一頁

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

作為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都是值得的。

原文連接：

“Ceph淺析”系列之六――Ceph與OpenStack

“Ceph淺析”系列之七――關于Ceph的若干想法

開源項目學習方法ABC（責編/仲浩）

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

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈