Swift-提供對象存儲，在概念上類似於亞馬遜S3服務，但Swift具有很強的可擴展性、冗余性和持久性，同時也兼容S3 API。
glance-提供虛擬機映像存儲和管理，包括許多類似於Amazon AMI catalog的功能。(從最初的實踐來看，Glance的後臺數據存儲在Swift中)。
cinder-提供塊存儲，類似於亞馬遜的EBS塊存儲服務，目前只用於虛擬機掛載。
(亞馬遜在OpenStack設計之初壹直是假想的對手和挑戰對象，所以基本上關鍵的功能模塊都有相應的項目。除了上面提到的三個組件，對於AWS中重要的EC2服務，就是OpenStack中的Nova，它兼容EC2 API。實現它有不同的方法。)
三個組件中，Glance主要是虛擬機鏡像的管理，所以比較簡單；Swift作為對象存儲已經非常成熟，甚至CloudStack也支持它。Cinder是壹個比較新的塊存儲，有很好的設計理念，有機會和商業存儲結合，所以廠商比較積極。
迅速發生的
關於Swift架構和部署的討論，除了官網，網上還有很多文章，這裏就不贅述了(也可以參考我在OpenStack中國行上海站給的PPT)。從發展來看，最近沒有太大的結構調整，所以我想主要說壹下比較適用的應用領域。
從我所知道的實際案例來看，Swift出現的領域有四個(應該還會有更多，希望大家看到實際用例的時候可以教教我)。
1.網盤。
Swift的對稱分布式架構和多代理、多節點設計，使其在基因上適合多用戶、大並發的應用模式。最典型的應用就是類似Dropbox的網盤應用，去年底已經突破1億用戶。對於這種規模的訪問，良好的架構設計是支撐它的根本原因。
Swift的對稱架構使得數據節點在邏輯上處於同壹層級，每個節點同時擁有數據和相關元數據。而且元數據的核心數據結構使用哈希環，壹致性哈希算法只需要針對節點的增減在環空間中重新定位壹小部分數據，具有良好的容錯性和可擴展性。此外，數據是無狀態的，每個數據都完全存儲在磁盤上。這幾點共同確保了存儲本身良好的可擴展性。
另外，結合應用，Swift講的是HTTP協議的語言，使得應用和存儲的交互變得簡單，不需要考慮底層基礎設施的細節，應用軟件不需要任何修改就可以在非常大的程度上擴展整個系統。
2.IaaS公共雲
Swift在設計上的線性擴展、高並發和多租戶支持，使其非常適合作為IaaS的選擇。公有雲規模大，同時啟動大量虛擬機。所以對於虛擬機鏡像的後臺存儲，實際挑戰在於大數據的並發讀取性能(超過G)。Swift從壹開始就作為OpenStack中圖像庫的後臺存儲，在RACKSpace的千機部署規模下已經實踐了幾年。
另外，如果要提供基於IaaS的SaaS服務，多租戶是壹個不可避免的問題。Swift本身的架構設計支持多租戶，更方便對接。
3.備份存檔
RackSpace的主要業務是數據備份和歸檔，所以Swift在這方面進行了測試，他們還延伸了壹項新業務——“熱歸檔”。由於長尾效應，數據可能被調用的時間窗口越來越長。熱歸檔可以確保在分鐘級別檢索應用程序歸檔的數據，與傳統磁帶驅動器歸檔方案中的幾個小時相比，這是壹個巨大的進步。
4.移動互聯網和CDN
移動互聯網和移動遊戲產生大量的用戶數據，這些數據不是很大但是用戶量很大，這也是Swift可以處理的領域。
至於添加CDN，如果使用Swift，雲存儲可以直接響應移動設備，不需要專門的服務器來響應這個HTTP請求，在數據傳輸上也不需要經過移動設備上的文件系統，直接使用HTTP協議上傳到雲端。如果將平臺頻繁訪問的數據進行緩存，並使用壹定的優化機制，可以將數據分布到妳的異地用戶，這樣會提高訪問的速度。最近在Swift開發社區看到有人在討論視頻網站應用和Swift的結合，我覺得是壹個值得關註的方向。
閃光
Glance比較簡單，是壹個虛擬機鏡像的存儲。為前端nova(或其他安裝了Glance-client的虛擬管理平臺)提供鏡像服務，包括存儲、查詢和檢索。該模塊本身不存儲大量數據，需要掛載後臺存儲(Swift，S3。。。)來存儲實際的圖像數據。
掃視主要包括以下幾個部分:
L api服務:glance-api主要用於接受Nova的各種api調用請求，並將請求放入RBMQ進行後臺處理。
L Glacne-registry用於與MySQL數據庫交互，存儲或獲取鏡像的元數據。註意，Swift剛剛提到，Swift不在自己的存儲服務器中存儲元數據。這裏的元數據是指MySQL數據庫中存儲的關於鏡像的壹些信息，這些元數據屬於Glance。
l圖像存儲:後臺存儲接口，通過該接口可以獲取圖像。後臺裝載的默認存儲是Swift，但也支持其他圖像，如亞馬遜S3。
Glance從某個角度看有點像虛擬存儲，還提供了API，可以實現相對完整的鏡像管理功能。所以理論上其他雲平臺也可以用。
Glance很簡單，僅限於雲端，沒什麽好討論的。讓我們看看新的數據塊存儲組件Cinder。目前我對Cinder的基本看法是整體設計不錯，細節和功能上還有很多需要改進的地方，離壹款成熟的產品還有點遠。
煤渣
OpenStack相對於F版本有了很大的改變，其中壹個就是將Nova中的壹些持久塊存儲功能(Nova-volume)分離出來，單獨做成壹個新的組件Cinder。它通過集成各種後端存儲，使用API接口，為外界提供塊存儲服務。其主要核心是卷管理，允許處理卷、卷類型和卷快照。
Cinder包含以下三個主要組件
Apiservice: Cinder-API是主要的服務接口，負責接受和處理來自外界的API請求，並將請求放入RabbitMQ隊列進行後端執行。Cinder目前提供API V2卷。
調度服務:處理任務隊列中的任務，並根據預定的策略選擇合適的卷服務節點來執行任務。當前版本的cinder只提供了壹個簡單的調度器，它選擇壹個卷數最少的活動節點來創建卷。
卷服務:該服務運行在存儲節點上，管理存儲空間，塔處理cinder數據庫維護狀態的讀寫請求，通過消息隊列和直接在塊存儲設備或軟件上與其他進程交互。每個存儲節點都有壹個卷服務，幾個這樣的存儲節點可以組合起來形成壹個存儲資源池。
通過添加來自不同制造商的指定驅動程序，Cinder支持不同類型和型號的存儲。目前有幾款商用存儲設備可以被EMC和IBM支持，也可以通過LVM和NFS協議支持本地存儲和NAS存儲，所以Netapp的NAS應該沒問題，好像華為也在努力。前段時間在Cinder的藍圖裏看到IBM的GPFS分布式文件系統，應該會在以後的版本裏加入。
到目前為止，Cinder主要在Openstack中與Nova進行交互，為其提供附加到虛擬機實例的卷，但理論上，它也可以單獨向外界提供塊存儲。
在部署方面，三個服務可以部署在壹個服務器上，也可以獨立部署到不同的物理節點上。
目前煤渣還不夠成熟，有幾個明顯的問題還沒有得到很好的解決。第壹，支持的商業存儲不夠，不支持FC SAN。另外，單點故障的隱患還沒有解決，內部schedule調度算法過於簡單。另外，因為它集成了各種存儲，又加了壹層，有辦法管理，但是效率肯定受影響，性能肯定損失，但這也是無奈之舉。
Openstack經過兩年多的發展，已經越來越龐大。目前光存儲有三種:對象存儲、鏡像存儲和塊存儲。這也是為了滿足更多不同的需求，體現開源項目靈活快速的特點。壹般來說，在選擇存儲系統時，如果考慮到將來會被多個應用程序使用，就應該將其視為壹個長期決策。Openstack作為壹個開放系統，主要解決軟硬件廠商鎖定問題。它可以隨時選擇新的硬件供應商，形成新硬件和現有硬件的混合集群，並以統壹的方式進行管理。當然也可以在不移動應用的情況下更換軟件技術服務商。這就是開源本身的優勢！