問題導讀
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 包：
- sudo apt-get install python-swift
- sudo apt-get install swift
- and the server-specific packages on the hosts that will be running them:
- sudo apt-get install swift-auth
- sudo apt-get install swift-proxy
- sudo apt-get install swift-account
- sudo apt-get install swift-container
- sudo apt-get install swift-object
複制代碼
Cinder 包包含 API、排程程式和卷管理程式：
- sudo apt-get install cinder-api
- sudo apt-get install cinder-scheduler
- sudo apt-get install cinder-volume
複制代碼
Red Hat：在 Red Hat 系統上，使用的指令是：
- sudo yum install openstack-swift
- sudo yum install openstack-swift-proxy
- sudo yum install openstack-swift-account
- sudo yum install openstack-swift-container
- sudo yum install openstack-swift-object
- sudo yum install openstack-swift-doc
- sudo yum install openstack-cinder
- sudo yum install openstack-cinder-doc
複制代碼
openSUSE：使用以下指令：
- sudo zypper install openstack-swift
- sudo zypper install openstack-swift-auth
- sudo zypper install openstack-swift-account
- sudo zypper install openstack-swift-container
- sudo zypper install openstack-swift-object
- sudo zypper install openstack-swift-proxy
- sudo zypper install openstack-cinder-api
- sudo zypper install openstack-cinder-scheduler
- 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