OpenStack入門之核心組件梳理（4）——Cinder篇

OpenStack入門之核心組件梳理（4）——Cinder篇

前言

​ 在講述Nova項目的文章中，筆者提到過Nova-Volume這一個子項目，這就是目前OpenStack中Cinder項目的前身。

​ 本文緊接以前各個組件的講解，繼續介紹OpenStack中核心組件之一的Cinder項目（塊存儲）相關理論知識。分別從這進行介紹：

1、簡述Cinder概念與做用

1.1塊存儲的概念

​ Cinder項目是OpenStack中爲Nova項目所實現的虛擬機實例提供數據可持久性的塊存儲服務，其前身爲Nova項目中的子項目Nova-Volume。不清楚存儲的相關基本知識可能不明白這個"塊"是什麼意思。簡單舉個例子來講，塊存儲能夠理解爲咱們筆記本中的硬盤，能夠是機械硬盤或者是固態硬盤，這個你們應該耳熟能詳了哈。

​ 那麼，再來講一下存儲。存儲，顧名思義，就是存放數據信息的，就好比實際生活中的庫房、儲物櫃、收納箱等等；存儲也正如這些實際例子同樣，也有本身的類型以及方式，本文旨在講述OpenStack中的塊存儲理論，存儲的分類以及方式就不作具體介紹了。

1.2cinder項目的做用

​ 在OpenStack中，存儲是其管理和提供的三大核心資源之一，所以，對於存儲的做用須要有所瞭解。

1. 爲Nova項目所實現的虛擬機實例提供數據持久化存儲服務；

2. 塊存儲提供了Volumes的管理基礎架構去，而且負責其快照和類型管理；

3. cinder經過插件形式爲存儲後端提供了訪問的API接口；

​ 塊存儲服務一般以存儲卷的形式掛載到虛擬機上來使用，經過統一的API接口，存儲客戶端能夠訪問不一樣的存儲資源，無需擔憂底層的存儲驅動。

2、淺談塊存儲、對象存儲以及文件系統存儲

​ OpenStack集羣中的存儲一般分爲塊存儲、對象存儲和文件系統存儲。下面簡述一下這三者的概念。

2.1塊存儲

​ 塊存儲就是經過SAN或iSCSI等存儲協議將存儲設備端的卷（Volume）掛載到虛擬機上並進行分區和格式化，而後掛載到本地文件系統使用的存儲實現方式。

2.2 文件系統存儲

​ 文件系統存儲就則是經過NFS或CIFS（Samba）等網絡文件系統協議將遠程文件系統掛載到本地系統使用的存儲實現方式。

2.3對象存儲

​ 相對而言，對象存儲在實現和使用方式上與塊存儲和文件系統存儲都不一樣，對象存儲是一種以REST API方式提供數據訪問的存儲實現方式。

​ 一般在OpenStack中，塊存儲是使用最多的數據存儲實現方式。接下來介紹一下Cinder項目的主要組件構成。

3、塊存儲主要組件

​ 本小節將介紹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。

4、塊存儲基本架構

​ 接下來來理解一下Cinder的基本架構，以下圖所示：

​ 經過該架構圖咱們能夠將Cinder項目的服務與其餘的服務聯繫起來理解。用戶提供Horizon項目提供的Web可視化界面客戶端或命令行客戶端與Cinder-api進行交互，Cinder-api經過Keystone經過的認證服務驗證用戶身份，接着使用MQ消息隊列與Cinder-volume通訊，Cinder-volume憑藉驅動插件管理由volume provider提供的各類存儲後端，而且將相關信息寫入數據庫中保存。

​ 以上就是Cinder項目架構中對應的服務與其餘項目服務之間的交互說明，下面一小節將經過一個例子來解釋cinder內部各個的交互原理及過程。

5、塊存儲內部組件工做原理

​ 假設，用戶須要建立一塊磁盤空間，或者說一個存儲卷。那麼cinder內部的工做流程是這樣的：

一、用戶發送一個建立新卷的請求給Cinder-api；

二、Cinder對該請求進行必要處理（如響應及驗證等），因而往Message Queue中放入一條建立卷的信息給Cinder-scheduler；

三、Cinder-scheduler接收到該信息後執行相應的算法，在一羣存儲節點上選擇一個相對較合適的節點；

四、因而Cinder-scheduler又往消息隊列中存放了一條讓被選出的存儲節點來建立這個卷的信息；

五、被選出的存儲節點的Cinder-volume接收到該信息，便經過驅動及對應的volume provider上建立該卷。

該過程能夠經過下面的流程圖來演示：

6、Cinder項目總結

​ 對於Cinder項目，首先明白其在OpenStack中的做用做用，提供的是什麼樣的服務。另外明白其基本架構以及對應的工做流程。本文對Cinder的介紹大體這些，固然，Cinder項目中有關其具體的使用以及插件的介紹在這裏就不繼續深刻了，有興趣的朋友能夠查一下相關資料。

​ 謝謝您的閱讀！