「CEPH淺析」系列之六——CEPH與OPENSTACK

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

 

說明：轉載請註明出處。謝謝。