OpenStack其實有三個與存儲相關的組件，這三個組件被人熟知的程度和組件本身出現時間的早晚是相符的，按熟悉程度排列如下：

Swift——提供對象存儲 (Object Storage)，在概念上類似于Amazon S3服務，不過swift具有很強的擴展性、冗余和持久性，也兼容S3 API

Glance——提供虛機鏡像(Image)存儲和管理，包括了很多與Amazon AMI catalog相似的功能。(Glance的后臺數據從最初的實踐來看是存放在Swift的)。

Cinder——提供塊存儲(Block Storage)，類似于Amazon的EBS塊存儲服務，目前僅給虛機掛載使用。

(Amazon一直是OpenStack設計之初的假象對手和挑戰對象，所以基本上關鍵的功能模塊都有對應項目。除了上面提到的三個組件，對于AWS中的重要的EC2服務，OpenStack中是Nova來對應，并且保持和EC2 API的兼容性，有不同的方法可以實現)

三個組件中，Glance主要是虛機鏡像的管理，所以相對簡單;Swift作為對象存儲已經很成熟，連CloudStack也支持它。Cinder是比較新出現的塊存儲，設計理念不錯，并且和商業存儲有結合的機會，所以廠商比較積極。

Swift

關于Swift的架構和部署討論，除了官方網站，網上也有很多文章，這里就不重復.(也可以參考我之前在OpenStack中國行活動中上海站演講的PPT)。從開發上看，最近也沒有太大的結構性調整，所以我想主要說說比較適用的應用領域好了。

從我所了解的實際案例來看，Swift出現的領域有4個，(應該還有更多，希望大家看到實際用例能夠指教)

1.網盤

Swift的對稱分布式架構和多proxy多節點的設計導致它從基因里就適合于多用戶大并發的應用模式，最典型的應用莫過于類似Dropbox的網盤應用，Dropbox去年底已經突破一億用戶數，對于這種規模的訪問，良好的架構設計是能夠支撐的根本原因。

Swift的對稱架構使得數據節點從邏輯上看處于同級別，每臺節點上同時都具有數據和相關的元數據。并且元數據的核心數據結構使用的是哈希環，一致性哈希算法對于節點的增減都只需重定位環空間中的一小部分數據,具有較好的容錯性和可擴展性。另外數據是無狀態的，每個數據在磁盤上都是完整的存儲。這幾點綜合起來保證了存儲的本身的良好的擴展性。

另外和應用的結合上，Swift是說HTTP協議這種語言的，這使得應用和存儲的交互變得簡單，不需要考慮底層基礎構架的細節，應用軟件不需要進行任何的修改就可以讓系統整體擴展到非常大的程度。

2.IaaS公有云

Swift在設計中的線性擴展，高并發和多租戶支持等特性，使得它也非常適合做為IaaS的選擇，公有云規模較大，更多的遇到大量虛機并發啟動這種情況，所以對于虛機鏡像的后臺存儲具體來說，實際上的挑戰在于大數據(超過G)的并發讀性能，Swift在OpenStack中一開始就是作為鏡像庫的后臺存儲，經過RACKSpace上千臺機器的部署規模下的數年實踐，Swift已經被證明是一個成熟的選擇。

另外如果基于IaaS要提供上層的SaaS 服務，多租戶是一個不可避免的問題，Swift的架構設計本身就是支持多租戶的，這樣對接起來更方便。

3.備份歸檔

RackSpace的主營業務就是數據的備份歸檔，所以Swift在這個領域也是久經考驗，同時他們還延展出一種新業務--“熱歸檔”。由于長尾效應，數據可能被調用的時間窗越來越長，熱歸檔能夠保證應用歸檔數據能夠在分鐘級別重新獲取，和傳統磁帶機歸檔方案中的數小時而言，是一個很大的進步。

4. 移動互聯網和CDN

移動互聯網和手機游戲等產生大量的用戶數據，數據量不是很大但是用戶數很多，這也是Swift能夠處理的領域。

至于加上CDN，如果使用Swift，云存儲就可以直接響應移動設備，不需要專門的服務器去響應這個HTTP的請求，也不需要在數據傳輸中再經過移動設備上的文件系統，直接是用HTTP 協議上傳云端。如果把經常被平臺訪問的數據緩存起來，利用一定的優化機制，數據可以從不同的地點分發到你的用戶那里，這樣就能提高訪問的速度，我最近看到Swift的開發社區有人在討論視頻網站應用和Swift的結合，竊以為是值得關注的方向。

Glance

Glance比較簡單，是一個虛機鏡像的存儲。向前端nova(或者是安裝了Glance-client的其他虛擬管理平臺)提供鏡像服務，包括存儲，查詢和檢索。這個模塊本身不存儲大量的數據，需要掛載后臺存儲(Swift，S3。。。)來存放實際的鏡像數據。

Glance主要包括下面幾個部分：

l API service： glance-api 主要是用來接受Nova的各種api調用請求，將請求放入RBMQ交由后臺處理，。

l Glacne-registry 用來和MySQL數據庫進行交互，存儲或者獲取鏡像的元數據，注意，剛才在Swift中提到，Swift在自己的Storage Server中是不保存元數據的，這兒的元數據是指保存在MySQL數據庫中的關于鏡像的一些信息，這個元數據是屬于Glance的。

l Image store： 后臺存儲接口，通過它獲取鏡像，后臺掛載的默認存儲是Swift，但同時也支持Amazon S3等其他的鏡像。

Glance從某種角度上看起來有點像虛擬存儲，也提供API，可以實現比較完整的鏡像管理功能。所以理論上其他云平臺也可以使用它。

Glance比較簡單，又限于云內部，所以沒啥可以多展開討論的，不如看看新出來的塊存儲組件Cinder，目前我對Cinder基本的看法是總體的設計不錯，細節和功能還有很多需要完善的地方，離一個成熟的產品還有點距離。

Cinder

OpenStack到F版本有比較大的改變，其中之一就是將之前在Nova中的部分持久性塊存儲功能(Nova-Volume)分離了出來，獨立為新的組件Cinder。它通過整合后端多種存儲，用API接口為外界提供塊存儲服務，主要核心是對卷的管理，允許對卷，卷的類型，卷的快照進行處理。

Cinder包含以下三個主要組成部分

API service：Cinder-api 是主要服務接口, 負責接受和處理外界的API請求，并將請求放入RabbitMQ隊列，交由后端執行。 Cinder目前提供Volume API V2

Scheduler service: 處理任務隊列的任務，并根據預定策略選擇合適的Volume Service節點來執行任務。目前版本的cinder僅僅提供了一個Simple Scheduler, 該調度器選擇卷數量最少的一個活躍節點來創建卷。

Volume service: 該服務運行在存儲節點上，管理存儲空間，塔處理cinder數據庫的維護狀態的讀寫請求，通過消息隊列和直接在塊存儲設備或軟件上與其他進程交互。每個存儲節點都有一個Volume Service，若干個這樣的存儲節點聯合起來可以構成一個存儲資源池。

Cinder通過添加不同廠商的指定drivers來為了支持不同類型和型號的存儲。目前能支持的商業存儲設備有EMC 和IBM的幾款，也能通過LVM支持本地存儲和NFS協議支持NAS存儲，所以Netapp的NAS應該也沒問題，好像華為也在努力中。我前段時間還在Cinder的blueprints看到IBM的GPFS分布式文件系統，在以后的版本應該會添加進來

到目前為止，Cinder主要和Openstack的Nova內部交互，為之提供虛機實例所需要的卷Attach上去，但是理論上也可以單獨向外界提供塊存儲。

部署上，可以把三個服務部署在一臺服務器，也可以獨立部署到不同物理節點

現在Cinder還是不夠成熟，有幾個明顯的問題還沒很好解決，一是支持的商業存儲還不夠多，而且還不支持FC SAN，另外單點故障隱患沒解決，內部的schedule調度算法也太簡單。另外由于它把各種存儲整合進來又加了一層，管理倒是有辦法了，但是效率肯定是有影響，性能肯定有損耗，但這也是沒辦法的事了。

Openstack通過兩年多發展，變得越來越龐大。目前光存儲就出現了三種：對象存儲、鏡像存儲和塊存儲。這也是為了滿足更多不同的需求，體現出開源項目靈活快速的特性。總的說來，當選擇一套存儲系統的時候，如果考慮到將來會被多個應用所共同使用，應該視為長期的決策。Openstack作為一個開放的系統，最主要是解決軟硬件供應商鎖定的問題，可以隨時選擇新的硬件供應商，將新的硬件和已有的硬件組成混合的集群，統一管理，當然也可以替換軟件技術服務的提供商，不用動應用。這是開源本身的優勢!