OpenStack裏的三種存儲

OpenStack裏的三種存儲
[轉]http://www.openstack.cn/?p=446 http://cloud.51cto.com/art/201304/387374.htm
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的架構和部署討論，除了官方網站，網上也有不少文章，這裏就不重複.從開發上看，最近也沒有太大的結構性調整，因此我想主要說說比較適用的應用領域好了。

從我所瞭解的實際案例來看，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做爲一個 開放的系統，最主要是解決軟硬件供應商鎖定的問題，能夠隨時選擇新的硬件供應商，將新的硬件和已有的硬件組成混合的集羣，統一管理，固然也能夠替換軟件技 術服務的提供商，不用動應用。這是開源自己的優點!