openstack中cinder與swift、glance的區別

問題導讀
1.你認爲cinder與swift區別是什麼？
2.cinder是否存在單點故障？
3.cinder是如何發展而來的？








在openstack中，咱們常常遇到這麼個問題，cinder與swift的區別是什麼？

cinder與swift各自的用途是什麼？
cinder是塊存儲，用來給虛擬機掛擴展硬盤，就是將cinder建立出來的卷，掛到虛擬機裏。cinder是OpenStack到F版，將以前在Nova中的部分持久性塊存儲功能（Nova-Volume）分離了出來，獨立爲新的組件Cinder

swift是一個系統，能夠上傳和下載，裏面通常存儲的是不常常修改的內容，好比用於存儲 VM 鏡像、備份和歸檔以及較小的文件，例如照片和電子郵件消息。更傾向於系統的管理


塊存儲具備安全可靠、高併發大吞吐量、低時延、規格豐富、簡單易用的特色，適用於文件系統、數據庫或者其餘須要原始塊設備的系統軟件或應用。



上面其實不少感受不是太直觀，我的認爲cinder能夠理解爲我的電腦的移動硬盤，它能夠隨意格式化，隨時存取。
對於swift能夠做爲網盤，相信對於雲技術的同窗來講，網盤應該是不陌生的，若是把一些常常用的內容，放到網盤中是很是不方便的。

Swift 仍是 Cinder？什麼時候使用以及使用哪種？
那麼，應該使用哪種對象存儲：Swift 仍是 Cinder？答案取決於您的應用程序。若是須要運行商用或遺留應用程序，那麼不多須要進行這種選擇。這些應用程序不可能被編碼來利用 Swift API，但您能夠輕鬆掛載一個 Cinder 磁盤，它表現得就像是直接將存儲附加到大多數應用程序。
固然，您還能夠對新應用程序使用 Cinder，可是不會從 Swift 自動附帶的彈性和冗餘中獲益。若是編程人員面對這樣的挑戰，那麼 Swift 的分佈式可擴展架構是一個值得考慮的特性。


單點故障
Swift 架構是分佈式的，可防止全部單點故障和進行水平擴展。
cinder存在單點故障還未解決




更多內容，如下來自ibm資料庫：


塊存儲 (Cinder)
Cinder 是 OpenStack Block Storage 的項目名稱；它爲來賓虛擬機 (VM) 提供了持久塊存儲。對於可擴展的文件系統、最大性能、與企業存儲服務的集成以及須要訪問原生塊級存儲的應用程序而言，塊存儲一般是必需的。
系統能夠暴露並鏈接設備，隨後管理服務器的建立、附加到服務器和從服務器分離。應用程序編程接口 (API) 也有助於增強快照管理，這種管理能夠備份大量塊存儲。




對象存儲 (Swift)

Swift 是兩種產品中較爲成熟的一個：自 OpenStack 成立以來一直是一個核心項目。Swift 的功能相似於一個分佈式、可訪問 API 的存儲平臺，可直接將它集成到應用程序中，或者用於存儲 VM 鏡像、備份和歸檔以及較小的文件，例如照片和電子郵件消息。

Object Store 有兩個主要的概念：對象和容器。

對象就是主要存儲實體。對象中包括與 OpenStack Object Storage 系統中存儲的文件相關的內容和全部可選元數據。數據保存爲未壓縮、未加密的格式，包含對象名稱、對象的容器以及鍵值對形式的全部元數據。對象分佈在整個數據中心的多個磁盤中，Swift 能夠藉此確保數據的複製和完整性。分佈式操做能夠利用低成本的商用硬件，同時加強可擴展性、冗餘性和持久性。

容器相似於 Windows® 文件夾，容器是用於存儲一組文件的一個存儲室。容器沒法被嵌套，但一個租戶能夠供建立無限數量的容器。對象必須存儲在容器中，因此您必須至少擁有一個容器來使用對象存儲。

與傳統的文件服務器不一樣，Swift 是橫跨多個系統進行分佈的。它會自動存儲每一個對象的冗餘副本，從而最大程度地提升可用性和可擴展性。對象版本控制提供了防止數據意外丟失或覆蓋的額外保護。


Swift 架構

Swift 架構包含三個組件：服務器、流程和環。

服務器

Swift 架構是分佈式的，可防止全部單點故障和進行水平擴展。它包括如下四種服務器：

• 代理服務器
• 對象服務器
• 容器服務器
• 賬戶服務器
  

代理服務器爲 OpenStack Object Storage 架構的其他部分提供一個統一的界面。它接收建立容器、上傳文件或修改元數據的請求，還能夠提供容器清單或展現存儲的文件。當收到請求時，代理服務器會肯定賬戶、容器或對象在環中的位置，並將請求轉發至相關的服務器。

對象服務器是一種簡單的服務器，能夠上傳、修改和檢索存儲在它所管理的設備上的對象（一般爲文件）。對象被存儲在本地文件系統中，使用了擴展的屬性保存全部的元數據。路徑基於對象名稱的散列和時間戳。

容器服務器實質上是對象的一個目錄。它處理特定容器的對象的分配，並根據請求來提供容器清單。能夠跨集羣複製該清單，以提供冗餘。

賬戶服務器經過使用對象存儲服務來管理賬戶。它的操做相似於在內部提供了清單的容器服務器，在這種狀況下，將會枚舉分配到給定賬戶的容器。

流程

有幾種預約的內部管理流程能夠管理數據存儲，包括複製服務、審計程序（auditor）和更新程序（updater）。

複製服務是相當重要的流程：確保整個集羣的一致性和可用性。因爲對象存儲的一個主要吸引點是其分佈式存儲，因此 OpenStack 必須在瞬態錯誤條件下確保得到一致的狀態，例如斷電或組件故障。複製服務經過按期對比本地數據與遠程副本並確保全部副本都包含最新版原本作到這一點。

爲了最大程度地減小進行對比所需的網絡流量的數量，該服務建立了每一個分區分段的一個散列（hash），並比較這些列表。容器和賬戶複製也可使用散列，但經過高水位標記（high-water mark）對這些散列進行了補充。實際的更新被推送，一般使用  rsync 來複制對象、容器和賬戶。

在刪除對象、容器或賬戶時，複製器（replicator）還會執行垃圾收集來實施一致的數據刪除。在刪除時，系統會使用一個墓碑圖片來標記最新版本，這是一個告訴複製器能夠從全部重複的節點中刪除對象、容器或賬戶的信號。

即便是最好的複製設計，也只在擁有實現該複製的組件時有效，不過，不管是硬件故障仍是軟件故障，抑或只是由於產品能力不足，生產環境都必須可以重現這些故障。在 Swift 中，該操做是由更新程序和審計程序來完成的。

更新程序負責在系統面臨故障時確保系統的完整性。當複製服務遇到一個問題，而且沒法更新容器或賬戶時，就會出現一段時間的不一致，在此其間，對象雖然存在於存儲中，但並未列出在全部容器或賬戶服務器上。在這種狀況下，系統會在本地文件系統上對更新進行排隊，並有一個更新程序會按期重試更新。

審計程序對這種不一致提供額外級別的保護。它們按期掃描本地存儲庫，驗證賬戶、容器和對象的完整性。在確認任何損壞時，審計程序會隔離該元素，並使用來自另外一個複製物的副本替換它。若是發現了沒法協調的不一致性（例如，對象不屬於任何容器），審計程序就會將該錯誤記錄在一個日誌文件中。

環

用戶和其餘 OpenStack 項目會根據邏輯名稱來引用存儲實體，但最終，全部請求，不管是用於讀取仍是用於寫入，都必須映射到某個物理位置。爲了完成這一操做，代理服務器和後臺流程（包括複製服務）都必須可以將邏輯名稱映射到物理位置。這種映射就稱爲一個環（ring）。賬戶、容器和對象都配有單獨的環。環根據設備、分區、副本和專區來描述這一映射。

在此上下文中，術語分區 指的是環中所存儲內容的邏輯子集。建議爲每一個參與設備分配 100 個分區。分區均勻地分佈在分配給 OpenStack Object Storage 的全部設備上。若是集羣使用了不一樣規格的驅動，那麼有可能會分配權重，以便平衡各個設備上的分區的分佈。

默認狀況下，每一個分區可被複制三次。有可能會使用一個較大的數字來優化可用性，但這顯然會增長存儲消耗。環還會指定在故障場景中使用哪些設備來接管工做負載，以及在向集羣添加設備或從中刪除設備時如何從新分配分區。

環映射的最後一個元素是專區，用於啓用數據親和性和反親和性，一個專區能夠表示一個存儲設備、一個物理服務器或者一個位置，例如機架、通道或數據中心，專區是用戶可用來知足其需求的一個邏輯概念，但一般反映的是物理元素，例如位置、電源和網絡鏈接。

Cinder 架構

Cinder 比 Swift 簡單得多，由於它不提供自動對象分佈和複製。圖 1 顯示了 Cinder 架構。

圖 1. Cinder architecture

 

與其餘 OpenStack 項目相似，Cinder 的功能經過 API 暴露給儀表板和命令行。它可以經過具備具象狀態傳輸 (Representational State Transfer, REST) 的 HTTP API 來訪問對象存儲，並使用一個名爲  Auth Manager 的 Python 類將身份驗證歸入 OpenStack Keystone。

API 解析全部傳入的請求並將它們轉發給消息隊列，調度程序和卷服務器在該隊列中執行實際的工做。在建立新的卷時，調度程序將會決定哪臺主機應對該卷負責。默認狀況下，它會選擇擁有最多可用空間的節點。

卷管理程序管理着可動態附加的塊存儲設備，這些設備也被稱爲卷。它們可用做虛擬實例的啓動設備，或做爲輔助存儲進行添加。Cinder 還爲快照（卷的只讀副本）提供了一種設備。而後可使用這些快照來建立新的卷，以供讀寫使用。

卷一般經過 iSCSI 附加到計算節點。塊存儲也須要某種形式的後端存儲，在默認狀況下，該後端存儲是本地卷組上的邏輯卷管理，但能夠經過驅動程序將它擴展到外部存儲陣列或設備。

設置

實際的安裝指令在發行版和 OpenStack 版本之間極爲不一樣。一般，它們可做爲發行版的一部分。可是，必須完成相同的基本任務。本節將會介紹其中涉及的概念。

系統要求

OpenStack 依賴於一種 64 位 x86 架構；另外，它是爲商用硬件而設計的，因此具備極低的系統要求。它能夠在配有包含 8GB RAM 的單個系統上運行整套 OpenStack 項目。可是，對於大型的工做負載，它對於使用專用系統來實現存儲相當重要。由於咱們的重點在商用設備上，因此不須要獨立磁盤冗餘陣列 (redundant array of independent disks, RAID) 功能，但使用至少兩個四核 CPU、8-12GB 的 RAM 和 1GB 的網絡適配器是一種明智之舉。顯然，硬盤或固態磁盤的大小取決於要存儲的數據量和但願的冗餘級別。

安裝

安裝指令取決於發行版，更具體地講，取決於您所選擇的包管理實用程序。在許多狀況下，必須聲明存儲庫。因此，舉例而言，若是您使用的是 Zypper，那麼您要用 zypper ar 向 libzypp 公開：

點擊查看代碼清單

而後，安裝所需的 Swift 和/或 Cinder 包。包管理實用程序應自動安裝全部依賴關係。整個安裝程序取決於您所指望的配置和 OpenStack 的準確版本。請務必查看安裝指南中的權威說明，爲了演示之目的，下面提供了適用於 Debian（例如 Ubuntu）、Red Hat（例如，Red Hat Enterprise Linux®、CentOS、Fedora）和 openSUSE 的一些主要命令。

Debian ：在全部主機上安裝基礎 Swift 包：

1. sudo apt-get install python-swift
   
2. sudo apt-get install swift
   
3. and the server-specific packages on the hosts that will be running them:
   
4. sudo apt-get install swift-auth
   
5. sudo apt-get install swift-proxy
   
6. sudo apt-get install swift-account
   
7. sudo apt-get install swift-container
   
8. sudo apt-get install swift-object

複製代碼

Cinder 包包含 API、調度程序和卷管理程序：

1. sudo apt-get install cinder-api
   
2. sudo apt-get install cinder-scheduler
   
3. sudo apt-get install cinder-volume

複製代碼

Red Hat ：在 Red Hat 系統上，使用的命令是：

1. sudo yum install openstack-swift
   
2. sudo yum install openstack-swift-proxy
   
3. sudo yum install openstack-swift-account
   
4. sudo yum install openstack-swift-container
   
5. sudo yum install openstack-swift-object
   
6. sudo yum install openstack-swift-doc
   
7. sudo yum install openstack-cinder
   
8. sudo yum install openstack-cinder-doc

複製代碼

openSUSE ：使用如下命令：

1. sudo zypper install  openstack-swift
   
2. sudo zypper install  openstack-swift-auth 
   
3. sudo zypper install  openstack-swift-account 
   
4. sudo zypper install  openstack-swift-container 
   
5. sudo zypper install  openstack-swift-object 
   
6. sudo zypper install  openstack-swift-proxy
   
7. sudo zypper install openstack-cinder-api
   
8. sudo zypper install openstack-cinder-scheduler
   
9. sudo zypper install openstack-cinder-volume

複製代碼

配置

配置 OpenStack Object Storage 安裝涉及到爲四個包的每個包量身定製配置文件：

• account-server.conf
• container-server.conf
• object-server.conf
• proxy-server.conf
  

配置文件安裝在 /etc/swift/ 中。默認的一組選項在標準安裝中運做良好，但在有特殊需求時，有必要編輯該配置。

使用場景

如欲瞭解如何使用 OpenStack 存儲，能夠想象這樣一個場景：在該場景中，有一項服務使用一個文件系統和新代碼運行了遺留軟件，您想在該文件系統和新代碼中使用分佈式對象存儲。適用於此項目的環境應該包括 Swift 和 Cinder。

首先來看一看 Cinder。

以具備 Member 角色的用戶身份登陸到 OpenStack Dashboard。


在導航面板中的 Manage Computer 下，單擊 Volumes > Create Volume。



圖 2. 建立一個卷
 



卷應出如今項目的列表中。
圖 3. 項目中的卷
 




編輯附件，以便將卷鏈接到其中一個計算實例。
圖 4. 管理卷附件
 


OpenStack 建立一個唯一的 iSCSI 合格名稱，並將其顯示給目前具備活動 iSCSI 會話的計算節點。若是實例是邏輯存儲（一般是一個 /dev/sdX 磁盤），那麼可使用 Cinder 卷。

要想對您的項目使用 Swift，首先必須建立一個容器。

做爲具備 Member 角色的用戶身份登陸到 OpenStack Dashboard，在導航面板的 Object Store 下，單擊 Containers > Create Container。 圖 5. 建立容器
 

這是一個簡單的操做，根本不會涉及提供任何數據。它只是一個名稱而已。

當擁有容器以後，一般由應用程序使用對象填充它，並根據須要使用一個編程接口來檢索這些對象。 圖 6. 已填充的容器
 


不過，您還能夠從儀表板上傳對象。在 Object Store 下，單擊 Containers > Upload Object 並提供一個包含存儲內容的文件。 圖 7. 上傳對象

 

7.jpg (130.7 KB, 下載次數: 23)

下載附件  保存到相冊

2014-11-17 10:50 上傳

您還可使用界面來下載、複製或刪除對象。

進一步補充：


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主要包括下面幾個部分：
1.API service： glance-api 主要是用來接受Nova的各類api調用請求，將請求放入RBMQ交由後臺處理，。

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

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

原文連接：http://www.aboutyun.com/thread-10060-1-1.html