在 《“Ceph淺析”系列之二——Ceph概況》中即已提到，關注Ceph的原因之一，就是OpenStack社區對於Ceph的重視。因此，本文將對Ceph在OpenStack中的價值進行簡要介紹，並且對Ceph和Swift進行對比。
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作爲一種統一存儲後端，則確實可以有效緩解這一問題。當然，這只是筆者的一家直言。任何技術選擇必然都有其複雜的背後原因，這裏的信息僅供參考。
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過程中的一些思考，供有興趣的讀者一同品評。