A, cinder description:

Understanding Block Storage

Operating system to obtain storage space, there are two general ways:

Attached via a protocol (SAS, SCSI, SAN, iSCSI, etc.) bare hard disk, and then partition, format, creating a file system; or directly using raw data stored in a hard disk (database)
By NFS, CIFS and other protocols, mount remote file systems

The first method is called bare hard Block Storage (memory block), also commonly referred to each of the bare hard Volume (volume) is called the second file system storage. NAS and NFS server, and a variety of distributed file storage system provides all this.

理解 Block Storage Service

Block Storage Servicet provides management of volume from creation to delete the entire life cycle. From the point of view instance, mount each Volume is a hard drive. OpenStack Block Storage Service is provided Cinder, whose specific function is:

Provide REST API enables users to query and manage volume, volume snapshot and volume type
Provide scheduler scheduling request to create a volume, optimize allocation of storage resources
By driver architecture supports a variety of back-end (back-end) storage, including LVM, NFS, Ceph and others, such as EMC, IBM and other commercial storage products and solutions

Cinder architecture

The figure is a logic chart cinder

http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20160610-1465514561994059446.png

Cinder contains the following components:

Cinder-fire

Receiving an API request call cinder-volume. Cinder entire assembly is portal, all requests are first processed by the cinder cinder-api. cinder-api exposed to a number of HTTP REST API interfaces to the outside world. In the keystone we can query the cinder-api of endponits.

The client can send the request to the specified address endponits, the request operation cinder-api. Of course, as an end user, we will not send Rest API requests directly. OpenStack CLI, Dashboard and other components need to exchange with Cinder will use these API.

cinder-api received HTTP API requests will be processed as follows:

1, check the client-human transmission parameters are valid

2, handle client calls cinder other sub-service request

3, the cinder other sub-service results returned by the serial number and returned to the client

cinder-api which requests to accept it? Simply put, as long as the relevant Volume lifecycle operations, cinder-api can respond. Most operations can be seen on the Dashboard.

cinder-volume

Management of service volume, and volume provider coordination, volume management lifecycle. Nodes running cinder-volume service is referred to as a storage node.

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-* 子服务。

http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20160610-1465514562079057922.png

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 前端服务的好处在于：

对外提供统一接口，隐藏实现细节
API 提供 REST 标准调用服务，便于与第三方系统集成
可以通过运行多个 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部署

controller节点

点击Block Storage service——Install and configure controller

1）创建cinder数据库并授权

MariaDB [(none)]> CREATE DATABASE cinder;
MariaDB [(none)]> GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' \
  IDENTIFIED BY 'CINDER_DBPASS';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'%' \
  IDENTIFIED BY 'CINDER_DBPASS';

2）创建用户cinder

openstack user create --domain default --password-prompt cinder

3)给cinder用户授予管理员权限

openstack role add --project service --user cinder admin

4）创建cinderv2和cinderv3服务

openstack service create --name cinderv2 \
  --description "OpenStack Block Storage" volumev2

openstack service create --name cinderv3 \
  --description "OpenStack Block Storage" volumev3

5）再分别创建cinderv2和cinderv3的服务端点

openstack endpoint create --region RegionOne \
  volumev2 public http://controller:8776/v2/%\(project_id\)s

 openstack endpoint create --region RegionOne \
  volumev2 internal http://controller:8776/v2/%\(project_id\)s

openstack endpoint create --region RegionOne \
  volumev2 admin http://controller:8776/v2/%\(project_id\)s

openstack endpoint create --region RegionOne \
  volumev3 public http://controller:8776/v3/%\(project_id\)s

openstack endpoint create --region RegionOne \
  volumev3 internal http://controller:8776/v3/%\(project_id\)s

openstack endpoint create --region RegionOne \
  volumev3 admin http://controller:8776/v3/%\(project_id\)s

6）下载openstack-cinder安装

yum install openstack-cinder

7）编辑cinder配置文件

[lvm]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
#volumes_dir = $state_path/volumes
iscsi_protocol = iscsi
iscsi_helper = lioadm
#iscsi_ip_address = 192.168.253.135　　　　　　#本机ip

8）同步数据库

su -s /bin/sh -c "cinder-manage db sync" cinder

9）编辑nova数据库,取消下面注释
[cinder]
os_region_name = RegionOne

10）重启相关服务

systemctl restart openstack-nova-api.service

# systemctl enable openstack-cinder-api.service openstack-cinder-scheduler.service
# systemctl start openstack-cinder-api.service openstack-cinder-scheduler.service

11）查看是否部署成功

openstack volume service list

| Binary           | Host        | Zone | Status  | State | Updated At                 |
+------------------+-------------+------+---------+-------+----------------------------+
| cinder-scheduler | controller  | nova | enabled | up    | 2019-06-06T08:59:35.000000 |
+------------------+-------------+------+---------+-------+----------------------------

storage节点

点进Install and configure a storage node

1）安装lvm安装包

openstack-cinder targetcli python-keystone lvm2

2）创建物理卷/卷组和逻辑卷

pvcreate /dev/sdb

vgcreate cinder-volumes /dev/sdb

3）编辑配置文件/etc/lvm/lvm.conf（315行后面添加，注意不要超出大括号）

devices {
...
filter = [ "a/sdb/", "r/.*/"]

4) Configuration cinder configuration file, the following is required to modify the place

vim /etc/lvm/lvm.conf

[lvm]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
iscsi_protocol = iscsi
iscsi_helper = lioadm

5) Restart lvm and cinder services

# systemctl enable openstack-cinder-volume.service target.service
# systemctl start openstack-cinder-volume.service target.service

6) control nodes to see if the successful deployment
openstack volume service list

openstack - cinder Service article