「Ceph淺析」系列之七——關於Ceph的若干想法

本篇文章的內容，主要是筆者在調研分析Ceph過程當中產生的一些思考。由於其中的內容比較自由發散，且大可能是筆者的我的看法，故此另啓一文進行討論。

關於Ceph的性能

目前爲止，本系列的文章中沒有涉及到Ceph性能的詳細討論，也沒有給出任何的Ceph性能數據。緣由很簡單：筆者本人沒有機會進行詳盡的Ceph性能分析研究，也沒有見到比較全面的相關數據。所以，爲了不以片面的數據誤導讀者，便沒有提供任何信息。

以筆者我的的經驗而言，探討一個系統領域的開源項目的性能，事實上並不容易。其緣由在於，影響一個實際部署中系統的性能好壞的因素太多、太複雜。硬件配置、 軟件版本、參數調整、應用負載及場景設置，各個方面的因素變化都會致使性能測試結果的不一樣。所以，很難一言蔽之，認爲某個項目的性能是好仍是很差。

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

又好比經常使用的開源大數據工具軟件Hadoop。同一個Hadoop集羣用一樣的應用程序處理一樣的數據集，在配置參數不一樣的狀況下，其最終運行時間長度可能相差數倍。

正是由於參數配置、硬件規格、軟件版本、應用場景等因素均可能對性能產生明顯影響，所以，對於Ceph這樣一個部署方案多變、配置參數很多的系統，如何評測其系統性能，是須要審慎思考的。

反過來說，這倒也是開源軟件引出的一個生財之道。雖然軟件自己是開源的，你們均可以避免費下載免費安裝，但能不能用好就要依靠精深的專業技能了。相似的公司國外家常便飯，而國內也已經開始出現。

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的硬件平臺。

Ceph與軟件定義存儲

「軟件定義」這四個字可謂是目前最煊赫一時、也最讓人糊塗的概念之一。軟件定義計算、軟件定義網絡、軟件定義存儲、軟件定義數據中心，以上幾個多是目前最爲常見的相關名詞了。

到底什麼是「軟件定義」，如今尚未造成徹底一致的看法。而且，參考技術發展史上的若干先例，之後也未必能造成所謂的一致看法。在這種狀況下，以一個具體實例入手，可能更容易得到直觀認識，並由此創建起更系統的觀點。

筆者認爲，對於任何一個系統而言，「軟件定義」的概念，更多體如今這裏：這個系統的哪些特性，好比功能或者性能，之前是固定的，或者只能進行有限的配置，而如今則能夠進行方便靈活地定義和改變。

例如，對於一臺物理服務器，一旦其硬件配置，如CPU、內存、硬盤等鏈接好，則這臺服務器的規格和性能就肯定了，可以經過BIOS配置等方式調整的性能和功 能範圍是頗有限的。可是，對於一臺虛擬機而言，即使在虛擬機已經建立並安裝了操做系統以後，其CPU核數及處理能力、邏輯物理內存大小及真實物理內存大 小、硬盤數量容量及讀寫性能、網卡型號數量及網絡帶寬等等特性都是能夠方便靈活地經過軟件方式進行控制和改變的（其中部分配置操做須要對虛擬機進行重啓才 能生效），且這種配置能夠由應用層軟件進行控制。兩相對比，則虛擬機的這種可定義性就是軟件定義計算的一個直觀實例。

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

具體到Ceph而言，其最爲符合軟件定義存儲的特性無疑是，Ceph的存儲類型是能夠經過軟件方式定義的。一樣的一個RADOS集羣，能夠經過安裝不一樣的上 層軟件和對應的客戶端程序，實現塊存儲、對象存儲和文件系統存儲功能，這一特性對於傳統的存儲系統不可思議。除此以外，Ceph的存儲策略，如備份策略、 後臺數據處理功能等，也均可以方便地經過軟件方式加以定義或擴展。所以，從這個角度出發，Ceph也能夠被認爲是軟件定義存儲的真實案例之一。

Ceph與數據中心計算

傳統意義上，計算系統的設計是以計算爲中心的。數據從存儲、網絡或其餘設備流入處理器，通過處理後再流向存儲、網絡或其餘設備。然而，隨着待處理的數據量以 爆炸式的速度增大，也隨着計算能力提升的速度超過存儲和傳輸能力，這一處理方式可能變得再也不經濟，由於針對大量的數據進行頻繁硬盤存取和網絡傳輸的代價都 是很是可觀的。

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

數據中心計算的另外一實例，是目前OpenStack社區中出現的一種叫作ZeroVM的輕量級虛擬化技術[1]。ZeroVM的思想就是讓計算髮生在數據所在的地方。基於其官方提供的信息，目前已經實現了ZeroVM和Swift的整合，可讓處理任務直接運行在Swift的服務器端。

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

目前，RADOS提供的機制容許在OSD上直接運行可動態加載的數據處理程序插件，以便在服務器端進行數據處理工做，例如，對圖片存儲系統中的圖片進行自動 加水印、尺寸和格式自動轉換等後臺操做。事實上，基於這種能力，也徹底能夠實現相似於Hadoop的大數據處理系統。

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

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

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

從非技術角度出發，Ceph的最大問題是火起來的時間不夠長，所以能夠參考的文檔還不是不少，中文的尤爲如此。但這個沒有辦法，只能衆人拾柴火焰高，一點一滴做貢獻。

此外，對Ceph詬病最多的可能仍是不夠成熟云云。但一個開源項目老是用得人多了纔會成熟的，而Ceph目前正在這個過程當中，因此須要的仍是時間和參與。

另外，以筆者的感受，Ceph的高度自動化可能也是個雙刃劍。好處當然是不少的，但弊端就是系統的運行狀態不徹底在管理員控制之下，系統中會有若干自動觸發而不是管理員觸發的操做。這個特色可能會給系統狀態的監測和控制帶來一些複雜度，須要管理員去適應。

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

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

首先，Ceph的安裝部署和性能優化必然成爲突出的需求。所以，將Ceph和商用服務器整合成易於部署、性能出色的各種存儲解決方案，應該是能夠考慮的方向之一。

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

此外，針對Ceph集羣的專用集羣監控、性能分析等工具軟件也可能會有必定的需求。

最後，基於Ceph的後臺數據處理軟件工具包也值得考慮。