為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

本篇文章的內(nèi)容，主要是筆者在調(diào)研分析Ceph過程中產(chǎn)生的一些思考。因為其中的內(nèi)容比較自由發(fā)散，且大多是筆者的個人見解，故此另啟一文進行討論。

?

7.1??? 關(guān)于Ceph的性能

????????目前為止，本系列的文章中沒有涉及到Ceph性能的詳細討論，也沒有給出任何的Ceph性能數(shù)據(jù)。原因很簡單：筆者本人沒有機會進行詳盡的Ceph性能分析研究，也沒有見到比較全面的相關(guān)數(shù)據(jù)。因此，為了避免以片面的數(shù)據(jù)誤導(dǎo)讀者，便沒有提供任何信息。

????????以筆者個人的經(jīng)驗而言，探討一個系統(tǒng)領(lǐng)域的開源項目的性能，事實上并不容易。其原因在于，影響一個實際部署中系統(tǒng)的性能好壞的因素太多、太復(fù)雜。硬件配置、軟件版本、參數(shù)調(diào)整、應(yīng)用負載及場景設(shè)置，各個方面的因素變化都會導(dǎo)致性能測試結(jié)果的不同。因此，很難一言蔽之，認為某個項目的性能是好還是不好。

????????舉一個不直接相關(guān)的例子。在hypervisor領(lǐng)域，大家很可能會傾向于認為ESXi的性能優(yōu)于KVM，但事實上，在SPECvirt性能測試結(jié)果排行榜上，基于KVM的系統(tǒng)常有高居第一的時候。究其原因，除了硬件性能的因素之外，KVM有大量的配置參數(shù)可以調(diào)整，而調(diào)得好與不好會極其明顯地影響系統(tǒng)性能。

????????又比如常用的開源大數(shù)據(jù)工具軟件Hadoop。同一個Hadoop集群用同樣的應(yīng)用程序處理同樣的數(shù)據(jù)集，在配置參數(shù)不同的情況下，其最終運行時間長度可能相差數(shù)倍。

????????正是因為參數(shù)配置、硬件規(guī)格、軟件版本、應(yīng)用場景等因素都可能對性能產(chǎn)生明顯影響，因此，對于Ceph這樣一個部署方案多變、配置參數(shù)不少的系統(tǒng)，如何評測其系統(tǒng)性能，是需要審慎思考的。

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

?

7.2??? Ceph的架構(gòu)與硬件平臺之間的適應(yīng)性

????????Ceph自2006年正式發(fā)布以來，其基礎(chǔ)架構(gòu)（RADOS）部分并沒有發(fā)生大的變化。本質(zhì)上，這還是因為RADOS的設(shè)計確實優(yōu)秀，有其前瞻性，因此沒有必要大動筋骨。但這并不意味著沒有必要對其進行適當(dāng)反思。

????????如前所述，2006年的時候，商用處理器的主流仍為單核，單條內(nèi)存和單塊硬盤的容量也都遠小于現(xiàn)在的主流水平。但是，OSD的基本硬件資源要求并沒有發(fā)生變化。這也就意味著，在目前的典型部署方案中，一臺物理服務(wù)器上很可能有數(shù)十個處理器硬件線程、數(shù)十塊硬盤，于是也就承載著數(shù)十個OSD同時運行。然而，RADOS結(jié)構(gòu)的基本假定是，集群是由大量的、相互獨立運行的OSD組成的，則目前的典型硬件方案有可能影響這種假定的有效性。例如，如果一臺服務(wù)器出現(xiàn)故障，必須關(guān)機進行維修，則意味著數(shù)十個OSD一起突然下線。由此受到影響的PG則可能多達成千上萬個。這種突發(fā)性的事件對系統(tǒng)的自動化維護機制可能會造成一定的壓力。

????????由此，筆者想到，Sage設(shè)計Ceph時面對的硬件平臺，事實上應(yīng)該是處理能力不需要過強、硬件規(guī)格比較簡單的系統(tǒng)。而這種系統(tǒng)可能與目前的ARM架構(gòu)或者Intel Atom架構(gòu)的micro-server更為相似。或許，基于micro-server部署Ceph集群，會是一種值得嘗試的方向。

????????此外，華為和希捷合作推出了IP硬盤產(chǎn)品。雖然還缺乏更進一步的了解，但直觀上推測，這種全新的、輕量級、智能化的存儲設(shè)備，可能也是一種非常近似于Sage當(dāng)年設(shè)想中的OSD的硬件平臺。

?

7.3??? Ceph與軟件定義存儲

????????“軟件定義”這四個字可謂是目前最炙手可熱、也最讓人糊涂的概念之一。軟件定義計算、軟件定義網(wǎng)絡(luò)、軟件定義存儲、軟件定義數(shù)據(jù)中心，以上幾個可能是目前最為常見的相關(guān)名詞了。

????????到底什么是“軟件定義”，現(xiàn)在還沒有形成完全一致的見解。并且，參考技術(shù)發(fā)展史上的若干先例，以后也未必能形成所謂的一致見解。在這種情況下，以一個具體實例入手，可能更容易獲得直觀認識，并由此建立起更系統(tǒng)的觀點。

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

????????例如，對于一臺物理服務(wù)器，一旦其硬件配置，如CPU、內(nèi)存、硬盤等連接好，則這臺服務(wù)器的規(guī)格和性能就確定了，能夠通過BIOS配置等方式調(diào)整的性能和功能范圍是很有限的。但是，對于一臺虛擬機而言，即便在虛擬機已經(jīng)創(chuàng)建并安裝了操作系統(tǒng)之后，其CPU核數(shù)及處理能力、邏輯物理內(nèi)存大小及真實物理內(nèi)存大小、硬盤數(shù)量容量及讀寫性能、網(wǎng)卡型號數(shù)量及網(wǎng)絡(luò)帶寬等等特性都是可以方便靈活地通過軟件方式進行控制和改變的（其中部分配置操作需要對虛擬機進行重啟才能生效），且這種配置可以由應(yīng)用層軟件進行控制。兩相對比，則虛擬機的這種可定義性就是軟件定義計算的一個直觀實例。

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

????????具體到Ceph而言，其最為符合軟件定義存儲的特性無疑是，Ceph的存儲類型是可以通過軟件方式定義的。同樣的一個RADOS集群，可以通過安裝不同的上層軟件和對應(yīng)的客戶端程序，實現(xiàn)塊存儲、對象存儲和文件系統(tǒng)存儲功能，這一特性對于傳統(tǒng)的存儲系統(tǒng)難以想象。除此之外，Ceph的存儲策略，如備份策略、后臺數(shù)據(jù)處理功能等，也都可以方便地通過軟件方式加以定義或擴展。因此，從這個角度出發(fā)，Ceph也可以被認為是軟件定義存儲的真實案例之一。

?

7.4? Ceph與數(shù)據(jù)中心計算

????????傳統(tǒng)意義上，計算系統(tǒng)的設(shè)計是以計算為中心的。數(shù)據(jù)從存儲、網(wǎng)絡(luò)或其他設(shè)備流入處理器，經(jīng)過處理后再流向存儲、網(wǎng)絡(luò)或其他設(shè)備。然而，隨著待處理的數(shù)據(jù)量以爆炸式的速度增大，也隨著計算能力提高的速度超過存儲和傳輸能力，這一處理方式可能變得不再經(jīng)濟，因為針對大量的數(shù)據(jù)進行頻繁硬盤存取和網(wǎng)絡(luò)傳輸?shù)拇鷥r都是非常可觀的。

????????數(shù)據(jù)中心計算這一概念，也就是在這種背景下被提出的。其核心思想，也就是讓計算在數(shù)據(jù)所在的地方發(fā)生。數(shù)據(jù)在哪里，就把計算任務(wù)發(fā)送到哪里去執(zhí)行，而不要再為了使用“強大”的計算能力把數(shù)據(jù)搬來搬去，傳來傳去。事實上，Hadoop的出現(xiàn)，就是這種數(shù)據(jù)中心計算思想的現(xiàn)實反映。

????????數(shù)據(jù)中心計算的另一實例，是目前OpenStack社區(qū)中出現(xiàn)的一種叫做ZeroVM的輕量級虛擬化技術(shù)[1]。ZeroVM的思想就是讓計算發(fā)生在數(shù)據(jù)所在的地方。基于其官方提供的信息，目前已經(jīng)實現(xiàn)了ZeroVM和Swift的整合，可以讓處理任務(wù)直接運行在Swift的服務(wù)器端。

????????事實上，Ceph也提供了同樣的能力。Ceph的整個設(shè)計，都是基于Sage的一個基本思想：充分發(fā)揮存儲器件自身的計算能力。這種思想不僅使得OSD可以相互配合完成數(shù)據(jù)訪問操作和集群維護功能，更允許OSD將富余的計算能力提供出來，用于運行數(shù)據(jù)處理任務(wù)。

????????目前，RADOS提供的機制允許在OSD上直接運行可動態(tài)加載的數(shù)據(jù)處理程序插件，以便在服務(wù)器端進行數(shù)據(jù)處理工作，例如，對圖片存儲系統(tǒng)中的圖片進行自動加水印、尺寸和格式自動轉(zhuǎn)換等后臺操作。事實上，基于這種能力，也完全可以實現(xiàn)類似于Hadoop的大數(shù)據(jù)處理系統(tǒng)。

????????對于大數(shù)據(jù)而言，存儲和處理是其兩個關(guān)鍵的技術(shù)領(lǐng)域。由于Ceph自身就是優(yōu)秀的存儲系統(tǒng)，又具備直接承載計算任務(wù)的能力，因此，面向大數(shù)據(jù)的數(shù)據(jù)中心計算很可能是Ceph的潛在應(yīng)用方向之一。

?

7.5? Ceph在實際應(yīng)用中可能存在的問題

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

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

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

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

?

7.6? 基于Ceph的產(chǎn)業(yè)需求和可能的商業(yè)機會

??????? 特此聲明：這一節(jié)的內(nèi)容純屬crazy idea，不構(gòu)成投資建議:-)

??????? 首先，Ceph的安裝部署和性能優(yōu)化必然成為突出的需求。因此，將Ceph和商用服務(wù)器整合成易于部署、性能出色的各類存儲解決方案，應(yīng)該是可以考慮的方向之一。

????????同時，由于Ceph自身對于OSD硬件平臺的特殊假設(shè)，以及由此導(dǎo)致的優(yōu)化空間，則在成本合理的前提下，開發(fā)更加適用于Ceph OSD的定制硬件平臺（類似于micro-server或者IP硬盤等），并突出存儲的高密度、低功耗、高可維護性等特點，也可能成為一種選擇。

????????此外，針對Ceph集群的專用集群監(jiān)控、性能分析等工具軟件也可能會有一定的需求。

????????最后，基于Ceph的后臺數(shù)據(jù)處理軟件工具包也值得考慮。

?

說明：轉(zhuǎn)載請注明出處。謝謝。

轉(zhuǎn)載于:https://my.oschina.net/oscfox/blog/215428

總結(jié)

以上是生活随笔為你收集整理的“CEPH浅析”系列之七——关于CEPH的若干想法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。