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