cinder介紹

一、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 請求會做如下處理：

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

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

3、將 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 文檔。

 

 

二、 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。

 

刪除cinder不用的服務：

（1） 禁用服務

openstack volume service set --disable HOST_NAME BINARY_NAME

（2） 從數據庫中刪除節點

cinder-manage service remove BINARY_NAME HOST_NAME

（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/volumesa iscsi_protocol = iscsi iscsi_helper = lioadm iscsi_ip_address = 172.16.254.63