本篇文章的內容，主要是筆者在調研分析Ceph過程中產生的一些思考。因爲其中的內容比較自由發散，且大多是筆者的個人見解，故此另啓一文進行討論。
7.1 關於Ceph的性能
目前爲止，本系列的文章中沒有涉及到Ceph性能的詳細討論，也沒有給出任何的Ceph性能數據。原因很簡單：筆者本人沒有機會進行詳盡的Ceph性能分析研究，也沒有見到比較全面的相關數據。因此，爲了避免以片面的數據誤導讀者，便沒有提供任何信息。
以筆者個人的經驗而言，探討一個系統領域的開源項目的性能，事實上並不容易。其原因在於，影響一個實際部署中系統的性能好壞的因素太多、太複雜。硬件配置、軟件版本、參數調整、應用負載及場景設置，各個方面的因素變化都會導致性能測試結果的不同。因此，很難一言蔽之，認爲某個項目的性能是好還是不好。
舉一個不直接相關的例子。在hypervisor領域，大家很可能會傾向於認爲ESXi的性能優於KVM，但事實上，在SPECvirt性能測試結果排行榜上，基於KVM的系統常有高居第一的時候。究其原因，除了硬件性能的因素之外，KVM有大量的配置參數可以調整，而調得好與不好會極其明顯地影響系統性能。
又比如常用的開源大數據工具軟件Hadoop。同一個Hadoop集羣用同樣的應用程序處理同樣的數據集，在配置參數不同的情況下，其最終運行時間長度可能相差數倍。
正是因爲參數配置、硬件規格、軟件版本、應用場景等因素都可能對性能產生明顯影響，因此，對於Ceph這樣一個部署方案多變、配置參數不少的系統，如何評測其系統性能，是需要審慎思考的。
反過來講，這倒也是開源軟件引出的一個生財之道。雖然軟件本身是開源的，大家都可以免費下載免費安裝，但能不能用好就要依靠精深的專業技能了。類似的公司國外屢見不鮮，而國內也已經開始出現。
7.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的硬件平臺。
7.3 Ceph與軟件定義存儲
“軟件定義”這四個字可謂是目前最炙手可熱、也最讓人糊塗的概念之一。軟件定義計算、軟件定義網絡、軟件定義存儲、軟件定義數據中心，以上幾個可能是目前最爲常見的相關名詞了。
到底什麼是“軟件定義”，現在還沒有形成完全一致的見解。並且，參考技術發展史上的若干先例，以後也未必能形成所謂的一致見解。在這種情況下，以一個具體實例入手，可能更容易獲得直觀認識，並由此建立起更系統的觀點。
筆者認爲，對於任何一個系統而言，“軟件定義”的概念，更多體現在這裏：這個系統的哪些特性，比如功能或者性能，以前是固定的，或者只能進行有限的配置，而現在則可以進行方便靈活地定義和改變。
例如，對於一臺物理服務器，一旦其硬件配置，如CPU、內存、硬盤等連接好，則這臺服務器的規格和性能就確定了，能夠通過BIOS配置等方式調整的性能和功能範圍是很有限的。但是，對於一臺虛擬機而言，即便在虛擬機已經創建並安裝了操作系統之後，其CPU核數及處理能力、邏輯物理內存大小及真實物理內存大小、硬盤數量容量及讀寫性能、網卡型號數量及網絡帶寬等等特性都是可以方便靈活地通過軟件方式進行控制和改變的（其中部分配置操作需要對虛擬機進行重啓才能生效），且這種配置可以由應用層軟件進行控制。兩相對比，則虛擬機的這種可定義性就是軟件定義計算的一個直觀實例。
下面再具體到存儲領域加以討論。一般而言，一個存儲系統的主要特性大致包括：存儲類型（文件系統？塊存儲？對象存儲？），存儲容量，存儲性能（訪問帶寬、訪問延遲等等），存儲策略（備份策略、訪問安全性策略、對數據的高級處理功能等等）。參考上面所舉出的軟件定義計算的例子，可以想見，對於一個軟件定義存儲系統而言，這些特性（至少是其中的大多數）都應該是可以通過軟件方式加以定義的。
具體到Ceph而言，其最爲符合軟件定義存儲的特性無疑是，Ceph的存儲類型是可以通過軟件方式定義的。同樣的一個RADOS集羣，可以通過安裝不同的上層軟件和對應的客戶端程序，實現塊存儲、對象存儲和文件系統存儲功能，這一特性對於傳統的存儲系統難以想象。除此之外，Ceph的存儲策略，如備份策略、後臺數據處理功能等，也都可以方便地通過軟件方式加以定義或擴展。因此，從這個角度出發，Ceph也可以被認爲是軟件定義存儲的真實案例之一。
7.4 Ceph與數據中心計算
傳統意義上，計算系統的設計是以計算爲中心的。數據從存儲、網絡或其他設備流入處理器，經過處理後再流向存儲、網絡或其他設備。然而，隨着待處理的數據量以爆炸式的速度增大，也隨着計算能力提高的速度超過存儲和傳輸能力，這一處理方式可能變得不再經濟，因爲針對大量的數據進行頻繁硬盤存取和網絡傳輸的代價都是非常可觀的。
數據中心計算這一概念，也就是在這種背景下被提出的。其核心思想，也就是讓計算在數據所在的地方發生。數據在哪裏，就把計算任務發送到哪裏去執行，而不要再爲了使用“強大”的計算能力把數據搬來搬去，傳來傳去。事實上，Hadoop的出現，就是這種數據中心計算思想的現實反映。
數據中心計算的另一實例，是目前OpenStack社區中出現的一種叫做ZeroVM的輕量級虛擬化技術[1]。ZeroVM的思想就是讓計算髮生在數據所在的地方。基於其官方提供的信息，目前已經實現了ZeroVM和Swift的整合，可以讓處理任務直接運行在Swift的服務器端。
事實上，Ceph也提供了同樣的能力。Ceph的整個設計，都是基於Sage的一個基本思想：充分發揮存儲器件自身的計算能力。這種思想不僅使得OSD可以相互配合完成數據訪問操作和集羣維護功能，更允許OSD將富餘的計算能力提供出來，用於運行數據處理任務。
目前，RADOS提供的機制允許在OSD上直接運行可動態加載的數據處理程序插件，以便在服務器端進行數據處理工作，例如，對圖片存儲系統中的圖片進行自動加水印、尺寸和格式自動轉換等後臺操作。事實上，基於這種能力，也完全可以實現類似於Hadoop的大數據處理系統。
對於大數據而言，存儲和處理是其兩個關鍵的技術領域。由於Ceph自身就是優秀的存儲系統，又具備直接承載計算任務的能力，因此，面向大數據的數據中心計算很可能是Ceph的潛在應用方向之一。
7.5 Ceph在實際應用中可能存在的問題
到目前位置，本系列文章基本上都是在介紹Ceph的各種優勢與特長。但是，任何系統都不可能是十全十美的，本着雞蛋裏挑骨頭、吹毛求疵的精神，還是要在這裏吐槽幾句。
從非技術角度出發，Ceph的最大問題是火起來的時間不夠長，因此可以參考的文檔還不是很多，中文的尤其如此。但這個沒有辦法，只能衆人拾柴火焰高，一點一滴作貢獻。
此外，對Ceph詬病最多的可能還是不夠成熟云云。但一個開源項目總是用得人多了纔會成熟的，而Ceph目前正在這個過程中，所以需要的還是時間和參與。
另外，以筆者的感覺，Ceph的高度自動化可能也是個雙刃劍。好處固然是很多的，但弊端就是系統的運行狀態不完全在管理員控制之下，系統中會有若干自動觸發而不是管理員觸發的操作。這個特點可能會給系統狀態的監測和控制帶來一些複雜度，需要管理員去適應。
7.6 基於Ceph的產業需求和可能的商業機會
特此聲明：這一節的內容純屬crazy idea，不構成投資建議:-)
首先，Ceph的安裝部署和性能優化必然成爲突出的需求。因此，將Ceph和商用服務器整合成易於部署、性能出色的各類存儲解決方案，應該是可以考慮的方向之一。
同時，由於Ceph自身對於OSD硬件平臺的特殊假設，以及由此導致的優化空間，則在成本合理的前提下，開發更加適用於Ceph OSD的定製硬件平臺（類似於micro-server或者IP硬盤等），並突出存儲的高密度、低功耗、高可維護性等特點，也可能成爲一種選擇。
此外，針對Ceph集羣的專用集羣監控、性能分析等工具軟件也可能會有一定的需求。
最後，基於Ceph的後臺數據處理軟件工具包也值得考慮。