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

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

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

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

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

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

Swift

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

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

1.網(wǎng)盤

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

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

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

2.IaaS公有云

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

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

3.備份歸檔

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

4. 移動互聯(lián)網(wǎng)和CDN

移動互聯(lián)網(wǎng)和手機游戲等產(chǎn)生大量的用戶數(shù)據(jù)，數(shù)據(jù)量不是很大但是用戶數(shù)很多，這也是Swift能夠處理的領(lǐng)域。

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

Glance

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

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

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

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

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

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

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

Cinder

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

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

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

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

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

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

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

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

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

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