open stack--cinder

cinder— 存儲服務

 

1、cinder 介紹：

 

理解 Block Storage

操做系統得到存儲空間的方式通常有兩種：

1. 經過某種協議（SAS,SCSI,SAN,iSCSI 等）掛接裸硬盤，而後分區、格式化、建立文件系統；或者直接使用裸硬盤存儲數據（數據庫）
2. 經過 NFS、CIFS 等 協議，mount 遠程的文件系統

    

第一種裸硬盤的方式叫作 Block Storage（塊存儲），每一個裸硬盤一般也稱做 Volume（卷） 第二種叫作文件系統存儲。NAS 和 NFS 服務器，以及各類分佈式文件系統提供的都是這種存儲。

 

理解 Block Storage Service

Block Storage Servicet 提供對 volume 從建立到刪除整個生命週期的管理。從 instance 的角度看，掛載的每個 Volume 都是一塊硬盤。OpenStack 提供 Block Storage Service 的是 Cinder，其具體功能是：

1. 提供 REST API 使用戶可以查詢和管理 volume、volume snapshot 以及 volume type
2. 提供 scheduler 調度 volume 建立請求，合理優化存儲資源的分配
3. 經過 driver 架構支持多種 back-end（後端）存儲方式，包括 LVM，NFS，Ceph 和其餘諸如 EMC、IBM 等商業存儲產品和方案

    

Cinder 架構

下圖是 cinder 的邏輯架構圖

 

 

Cinder 包含以下幾個組件：

 

cinder-api

接收 API 請求， 調用 cinder-volume 。是整個 Cinder 組件的門戶，全部 cinder 的請求都首先由 cinder-api 處理。cinder-api 向外界暴露若干 HTTP REST API 接口。在 keystone 中咱們能夠查詢 cinder-api 的 endponits。

客戶端能夠將請求發送到 endponits 指定的地址，向 cinder-api 請求操做。 固然，做爲最終用戶的咱們不會直接發送 Rest API 請求。OpenStack CLI，Dashboard 和其餘須要跟 Cinder 交換的組件會使用這些 API。

cinder-api 對接收到的 HTTP API 請求會作以下處理：

一、檢查客戶端傳人的參數是否合法有效

二、調用 cinder 其餘子服務的處理客戶端請求

三、將 cinder 其餘子服務返回的結果序列號並返回給客戶端

cinder-api 接受哪些請求呢？簡單的說，只要是 Volume 生命週期相關的操做，cinder-api 均可以響應。大部分操做均可以在 Dashboard 上看到。

 

 

cinder-volume

管理 volume 的服務，與 volume provider 協調工做，管理 volume 的生命週期。運行 cinder-volume 服務的節點被稱做爲存儲節點。

 

cinder-volume 在存儲節點上運行，OpenStack 對 Volume 的操做，最後都是交給 cinder-volume 來完成的。cinder-volume 自身並無論理真正的存儲設備，存儲設備是由  volume provider 管理的。cinder-volume 與 volume provider 一塊兒實現 volume 生命週期的管理。

 

經過 Driver 架構支持多種 Volume Provider

接着的問題是：如今市面上有這麼多塊存儲產品和方案（volume provider），cinder-volume 如何與它們配合呢？

 

經過的 Driver 架構。 cinder-volume 爲這些 volume provider 定義了統一的接口，volume provider 只須要實現這些接口，就能夠 Driver 的形式即插即用到 OpenStack 系統中。

 

按期向 OpenStack 報告計算節點的狀態

cinder-volume 會按期向 Cinder 報告存儲節點的空閒容量來作篩選啓動volume

 

實現 volume 生命週期管理

Cinder 對 volume 的生命週期的管理最終都是經過 cinder-volume 完成的，包括 volume 的 create、extend、attach、snapshot、delete 等。

 

cinder-scheduler

scheduler 經過調度算法選擇最合適的存儲節點建立 volume。 建立 Volume 時，cinder-scheduler 會基於容量、Volume Type 等條件選擇出最合適的存儲節點，而後讓其建立 Volume

 

volume provider

數據的存儲設備，爲 volume 提供物理存儲空間。 cinder-volume 支持多種 volume provider，每種 volume provider 經過本身的 driver 與cinder-volume 協調工做。

 

Message Queue

Cinder 各個子服務經過消息隊列實現進程間通訊和相互協做。由於有了消息隊列，子服務之間實現瞭解耦，這種鬆散的結構也是分佈式系統的重要特徵。

 

Database Cinder 

有一些數據須要存放到數據庫中，通常使用 MySQL。數據庫是安裝在控制節點上的，好比在咱們的實驗環境中，能夠訪問名稱爲「cinder」的數據庫。

 

 

物理部署方案

Cinder 的服務會部署在兩類節點上，控制節點和存儲節點。咱們來看看控制節點 controller 上都運行了哪些 cinder-* 子服務。

 

 

cinder-api 和 cinder-scheduler 部署在控制節點上，這個很合理。

 

至於 cinder-volume 也在控制節點上可能有些同窗就會迷糊了：cinder-volume 不是應該部署在存儲節點上嗎？

 

要回答這個問題，首先要搞清楚一個事實： OpenStack 是分佈式系統，其每一個子服務均可以部署在任何地方，只要網絡可以連通。不管是哪一個節點，只要上面運行了 cinder-volume，它就是一個存儲節點，固然，該節點上也能夠運行其餘 OpenStack服務。

 

cinder-volume 是一頂存儲節點帽子，cinder-api 是一頂控制節點帽子。在咱們的環境中，devstack-controller 同時戴上了這兩頂帽子，因此它既是控制節點，又是存儲節點。固然，咱們也能夠用一個專門的節點來運行 cinder-volume。

 

這再一次展現了 OpenStack 分佈式架構部署上的靈活性： 能夠將全部服務都放在一臺物理機上，用做一個 All-in-One 的測試環境；而在生產環境中能夠將服務部署在多臺物理機上，得到更好的性能和高可用。

 

RabbitMQ 和 MySQL 一般放在控制節點上。另外，也能夠用 cinder service list 查看 cinder-* 子服務都分佈在哪些節點上

 

還有一個問題：volume provider 放在那裏？

通常來說，volume provider 是獨立的。cinder-volume 使用 driver 與 volume provider 通訊並協調工做。因此只須要將 driver 與 cinder-volume 放到一塊兒就能夠了。在 cinder-volume 的源代碼目錄下有不少 driver，支持不一樣的 volume provider。

 

後面咱們會以 LVM 和 NFS 這兩種 volume provider 爲例討論 cinder-volume 的使用，其餘 volume provider 能夠查看 OpenStack 的 configuration 文檔。

 

 

2、 Cinder 的設計思想：

 

從 volume 建立流程看 cinder-* 子服務如何協同工做

 

對於 Cinder 學習來講，Volume 建立是一個很是好的場景，涉及各個 cinder-* 子服務，下面是流程圖：

• 客戶（能夠是 OpenStack 最終用戶，也能夠是其餘程序）向 API（cinder-api）發送請求：「幫我建立一個 volume」
   
• API 對請求作一些必要處理後，向 Messaging（RabbitMQ）發送了一條消息：「讓 Scheduler 建立一個 volume」
   
• Scheduler（cinder-scheduler）從 Messaging 獲取到 API 發給它的消息，而後執行調度算法，從若干計存儲點中選出節點 A
   
• Scheduler 向 Messaging 發送了一條消息：「讓存儲節點 A 建立這個 volume」
   
• 存儲節點 A 的 Volume（cinder-volume）從 Messaging 中獲取到 Scheduler 發給它的消息，而後經過 driver 在 volume provider 上建立 volume。

 

Cinder 的設計思想

 

Cinder 延續了 Nova 的以及其餘組件的設計思想。

API 前端服務

cinder-api 做爲 Cinder 組件對外的惟一窗口，向客戶暴露 Cinder 可以提供的功能，當客戶須要執行 volume 相關的操做，能且只能向 cinder-api 發送 REST 請求。這裏的客戶包括終端用戶、命令行和 OpenStack 其餘組件。

設計 API 前端服務的好處在於：

1. 對外提供統一接口，隱藏實現細節
2. API 提供 REST 標準調用服務，便於與第三方系統集成
3. 能夠經過運行多個 API 服務實例輕鬆實現 API 的高可用，好比運行多個 cinder-api 進程

Scheduler 調度服務

Cinder 能夠有多個存儲節點，當須要建立 volume 時，cinder-scheduler 會根據 存儲節點的屬性和資源使用狀況選擇一個最合適的節點來建立 volume。

調度服務就比如是一個開發團隊中的項目經理，當接到新的開發任務時，項目經理會根據任務的難度，每一個團隊成員目前的工做負荷和技能水平，將任務分配給最合適的開發人員。

Worker 工做服務

調度服務只管分配任務，真正執行任務的是 Worker 工做服務。

在 Cinder 中，這個 Worker 就是 cinder-volume 了。這種 Scheduler 和 Worker 之間職能上的劃分使得 OpenStack 很是容易擴展：當存儲資源不夠時能夠增長存儲節點（增長 Worker）。 當客戶的請求量太大調度不過來時，能夠增長 Scheduler。

Driver 框架

OpenStack 做爲開放的 Infrastracture as a Service 雲操做系統，支持業界各類優秀的技術，這些技術多是開源免費的，也多是商業收費的。

這種開放的架構使得 OpenStack 保持技術上的先進性，具備很強的競爭力，同時又不會形成廠商鎖定（Lock-in）。 那 OpenStack 的這種開放性體如今哪裏呢？一個重要的方面就是採用基於 Driver 的框架。

以 Cinder 爲例，存儲節點支持多種 volume provider，包括 LVM, NFS, Ceph, GlusterFS，以及 EMC, IBM 等商業存儲系統。 cinder-volume 爲這些 volume provider 定義了統一的 driver 接口，volume provider 只須要實現這些接口，就能夠 driver 的形式即插即用到 OpenStack 中。下面是 cinder driver 的架構示意圖：

在 cinder-volume 的配置文件 /etc/cinder/cinder.conf 中 volume_driver 配置項設置該存儲節點使用哪一種 volume provider 的 driver，下面的示例表示使用的是 LVM。

 

3、 Cinder 的配置文件：

vim /etc/cinder/cinder.conf

[DEFAULT]

my_ip = 172.16.254.63

glance_api_servers =  http://controller:9292

auth_strategy = keystone

enabled_backends = lvm

transport_url =  rabbit://openstack:admin@controller

 

[backend]

 

[barbican]

 

[brcd_fabric_example]

 

[cisco_fabric_example]

 

[coordination]

 

[cors]

 

[cors.subdomain]

 

[database]

connection = mysql+ pymysql://cinder:CINDER_DBPASS@controller/cinder

 

[fc-zone-manager]

 

[healthcheck]

 

[key_manager]

 

[keystone_authtoken]

auth_uri =  http://controller:5000

auth_url =  http://controller:35357

memcached_servers = controller:11211

auth_type = password

project_domain_name = default

user_domain_name = default

project_name = service

username = cinder

password = cinder

 

[matchmaker_redis]

 

[oslo_concurrency]

lock_path = /var/lib/cinder/tmp

 

[oslo_messaging_amqp]

 

[oslo_messaging_kafka]

 

[oslo_messaging_notifications]

 

[oslo_messaging_rabbit]

 

[oslo_messaging_zmq]

 

[oslo_middleware]

 

[oslo_policy]

 

[oslo_reports]

 

[oslo_versionedobjects]

 

[profiler]

 

[ssl]

 

[lvm]

volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver

volume_group = cinder-vg

volumes_dir = $state_path/volumes

iscsi_protocol = iscsi

iscsi_helper = lioadm

iscsi_ip_address = 172.16.254.63