[轉]“Ceph淺析”系列之(五)——Ceph與OpenStack

轉載自：http://yizhaolingyan.net/?p=11

       在 《“Ceph淺析”系列之二——Ceph概況》中即已提到，關注Ceph的原因之一，就是OpenStack社群對于Ceph的重視。是以，本文将對Ceph在OpenStack中的價值進行簡要介紹，并且對Ceph和Swift進行對比。

6.1    Ceph在OpenStack中的地位

        對于一個IaaS系統，涉及到存儲的部分主要是塊存儲服務子產品、對象存儲服務子產品、鏡像管理子產品和計算服務子產品。具體針對OpenStack而言，則分别對應為其中的Cinder、Swift、Glance和Nova四個項目[1]。

        在塊存儲服務部分，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 作為一種統一存儲後端，則确實可以有效緩解這一問題。當然，這隻是筆者的一家直言。任何技術選擇必然都有其複雜的背後原因，這裡的資訊僅供參考。

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

        首先對Swift項目的來龍去脈進行簡單介紹，以便大家更好地了解這個項目的特性，及其背後隐藏的原因。此處關于Swift的資訊主要引自[2]。

        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過程中的一些思考，供有興趣的讀者一同品評。

轉載于:https://blog.51cto.com/liufu1103/1657147