OpenStack入門之核心組件梳理（4）——Cinder篇
前言
在講述Nova項目的文章中，筆者提到過Nova-Volume這一個子項目，這就是目前OpenStack中Cinder項目的前身。
本文緊接之前各個組件的講解，繼續介紹OpenStack中核心組件之一的Cinder項目（塊存儲）相關理論知識。分別從這進行介紹：
一、簡述Cinder概念與作用
1.1塊存儲的概念
Cinder項目是OpenStack中爲Nova項目所實現的虛擬機實例提供數據可持久性的塊存儲服務，其前身爲Nova項目中的子項目Nova-Volume。不清楚存儲的相關基本知識可能不明白這個"塊"是什麼意思。簡單舉個例子來說，塊存儲可以理解爲我們筆記本中的硬盤，可以是機械硬盤或者是固態硬盤，這個大家應該耳熟能詳了哈。
那麼，再來說一下存儲。存儲，顧名思義，就是存放數據信息的，就比如實際生活中的庫房、儲物櫃、收納箱等等；存儲也正如這些實際例子一樣，也有自己的類型以及方式，本文旨在講述OpenStack中的塊存儲理論，存儲的分類以及方式就不做具體介紹了。
1.2cinder項目的作用
在OpenStack中，存儲是其管理和提供的三大核心資源之一，因此，對於存儲的作用需要有所瞭解。
-
爲Nova項目所實現的虛擬機實例提供數據持久化存儲服務；
-
塊存儲提供了Volumes的管理基礎架構去，並且負責其快照和類型管理；
- cinder通過插件形式爲存儲後端提供了訪問的API接口；
塊存儲服務通常以存儲卷的形式掛載到虛擬機上來使用，通過統一的API接口，存儲客戶端可以訪問不同的存儲資源，無需擔心底層的存儲驅動。
二、淺談塊存儲、對象存儲以及文件系統存儲
OpenStack集羣中的存儲通常分爲塊存儲、對象存儲和文件系統存儲。下面簡述一下這三者的概念。
2.1塊存儲
塊存儲就是通過SAN或iSCSI等存儲協議將存儲設備端的卷（Volume）掛載到虛擬機上並進行分區和格式化，然後掛載到本地文件系統使用的存儲實現方式。
2.2 文件系統存儲
文件系統存儲就則是通過NFS或CIFS（Samba）等網絡文件系統協議將遠程文件系統掛載到本地系統使用的存儲實現方式。
2.3對象存儲
相對而言，對象存儲在實現和使用方式上與塊存儲和文件系統存儲都不同，對象存儲是一種以REST API方式提供數據訪問的存儲實現方式。
通常在OpenStack中，塊存儲是使用最多的數據存儲實現方式。接下來介紹一下Cinder項目的主要組件構成。
三、塊存儲主要組件
本小節將介紹Cinder項目中主要的組件。
3.1Cinder-api
Cinder-api是一種WSIG類型的應用服務，其主要負責接收來自Horizon或命令行客戶端的塊存儲API請求，同時負責請求客戶端的身份信息驗證（通過Keystone項目實現）。
Cinder-api接收到客戶端請求後，根據Cinder-scheduler的存儲後端調度結果，將請求API路由到運行Cinder-volume服務的對應後端存儲上。
3.2Cinder-scheduler
Cinder-scheduler，與Nova-scheduler的功能類似，Cinder-scheduler是Cinder項目的後端Volumes的服務調度器。當Cinder-api接收到客戶端請求後，將由Cinder-scheduler服務來負責API的路由。
根據用戶配置的計劃策略，Cinder-api請求可以採用形如RR的輪詢方式路由到運行Volume服務的各個存儲節點，也可以採用FilterScheduler來實現更爲複雜和智能的後端存儲節點過濾策略。在Cinder的配置中，FilterScheduler是默認設置，通過FilterScheduler的配置可以實現基於Capacity、Availability Zone、Volume Types、Capabilities或者用戶自定義過濾策略的後端存儲節點調度。
3.3Cinder-volume
Cinder-volume是Cinder項目中真正提供塊存儲和不同存儲驅動插件管理的服務。OpenStack對Volume的操作，最後都是交給cinder-volume來完成的。
Cinder-volume服務通過AMQP與Cinder-scheduler進行交互，將其所管理的各個存儲驅動後端的運行、性能和容量等參數實時傳遞到Cinder-scheduler，以便Cinder-scheduler根據這些參數進行存儲節點的調度。此外，Cinder-volume通過驅動架構實現與不同存儲驅動後端的交互。
3.4Cinder-backup
Cinder-backup爲塊存儲卷（Volumes）提供了備份服務，要實現Volumes的備份，需要提供備份存儲驅動的實現，目前比較常見的備份存儲後端由Swift提供。與Cinder-volume類似，Cinder-backup也通過Driver（驅動）插件架構的形式與不同的存儲備份後端交互。
3.5MESSAGE QUEUE
Cinder項目的不同內部服務組件之間通過Queue進行消息交互。Cinder中各個服務之間通過消息隊列進行通信可以參考下圖：
3.6 Database
Cinder有一些數據需要存放到數據庫中，一般使用的數據庫爲MySQL。
四、塊存儲基本架構
接下來來理解一下Cinder的基本架構，如下圖所示：
通過該架構圖我們可以將Cinder項目的服務與其他的服務聯繫起來理解。用戶提供Horizon項目提供的Web可視化界面客戶端或命令行客戶端與Cinder-api進行交互，Cinder-api通過Keystone通過的認證服務驗證用戶身份，接着使用MQ消息隊列與Cinder-volume通信，Cinder-volume憑藉驅動插件管理由volume provider提供的各種存儲後端，並且將相關信息寫入數據庫中保存。
以上就是Cinder項目架構中對應的服務與其他項目服務之間的交互說明，下面一小節將通過一個例子來解釋cinder內部各個的交互原理及過程。
五、塊存儲內部組件工作原理
假設，用戶需要創建一塊磁盤空間，或者說一個存儲卷。那麼cinder內部的工作流程是這樣的：
1、用戶發送一個創建新卷的請求給Cinder-api；
2、Cinder對該請求進行必要處理（如響應及驗證等），於是往Message Queue中放入一條創建卷的信息給Cinder-scheduler；
3、Cinder-scheduler接收到該信息後執行相應的算法，在一羣存儲節點上選擇一個相對較合適的節點；
4、於是Cinder-scheduler又往消息隊列中存放了一條讓被選出的存儲節點來創建這個卷的信息；
5、被選出的存儲節點的Cinder-volume接收到該信息，便通過驅動及對應的volume provider上創建該卷。
該過程可以通過下面的流程圖來演示：
六、Cinder項目總結
對於Cinder項目，首先明白其在OpenStack中的作用作用，提供的是什麼樣的服務。另外明白其基本架構以及對應的工作流程。本文對Cinder的介紹大致這些，當然，Cinder項目中有關其具體的使用以及插件的介紹在這裏就不繼續深入了，有興趣的朋友可以查一下相關資料。
謝謝您的閱讀！