Cinder组件

cinder-api

cinder-api 是整个 Cinder 组件的门户，所有 cinder 的请求都首先由 cinder-api 处理。

cinder-api 向外界暴露若干 HTTP REST API 接口。在 keystone 中我们可以查询 cinder-api 的 endponits。

客户端可以将请求发送到 endponits 指定的地址，向 cinder-api 请求操作。 当然，作为最终用户的我们不会直接发送 Rest API 请求。

cinder-api 对接收到的 HTTP API 请求会做如下处理：

1. 检查客户端传人的参数是否合法有效
2. 调用 cinder 其他子服务的处理客户端请求
3. 将 cinder 其他子服务返回的结果序列号并返回给客户端

cinder-api 接受哪些请求呢？简单的说，只要是 Volume 生命周期相关的操作，cinder-api 都可以响应。大部分操作都可以在 Dashboard 上看到。

打开 Volume 管理界面

点击下拉箭头，列表中就是 cinder-api 可执行的操作。

cinder-scheduler

创建 Volume 时，cinder-scheduler 会基于容量、Volume Type 等条件选择出最合适的存储节点，然后让其创建 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 如何与它们配合呢？

cinder-volume 为这些 volume provider 定义了统一的接口，volume provider 只需要实现这些接口，就可以 Driver 的形式即插即用到 OpenStack 系统中。

下面是 Cinder Driver 的架构示意图：

我们可以在 /opt/stack/cinder/cinder/volume/drivers/ 目录下查看到 OpenStack 源代码中已经自带了很多 volume provider 的 Driver：

存储节点在配置文件 /etc/cinder/cinder.conf 中用 volume_driver 选项配置使用的driver：

这里 LVM 是我们使用的 volume provider。

定期向 OpenStack 报告计算节点的状态

在前面 cinder-scheduler 会用到 CapacityFilter 和 CapacityWeigher，它们都是通过存储节点的空闲容量来做筛选。

那这里有个问题：Cinder 是如何得知每个存储节点的空闲容量信息的呢？

答案就是：cinder-volume 会定期向 Cinder 报告。

从 cinder-volume 的日志 /opt/stack/logs/c-vol.log 可以发现每隔一段时间，cinder-volume 就会报告当前存储节点的资源使用情况。

因为在我们的实验环境中存储节点使用的是 LVM，所以在上面的日志看到存储节点通过“vgs”和”lvs”这两个命令获取 LVM 的容量使用信息。

实现 volume 生命周期管理

Cinder 对 volume 的生命周期的管理最终都是通过 cinder-volume 完成的，包括 volume 的 create、extend、attach、snapshot、delete 等，后面我们会详细讨论。

 

 

下面介绍 cinder-scheduler 是如何实现这个调度工作的。

在 /etc/cinder/cinder.conf 中，cinder 通过 scheduler_driver， scheduler_default_filters 和 scheduler_default_weighers 这三个参数来配置 cinder-scheduler。

Filter scheduler

Filter scheduler 是 cinder-scheduler 默认的调度器。

scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler

与 Nova 一样，Cinder 也允许使用第三方 scheduler，配置 scheduler_driver 即可。

scheduler 调度过程如下：

1. 通过过滤器（filter）选择满足条件的存储节点（运行 cinder-volume）
2. 通过权重计算（weighting）选择最优（权重值最大）的存储节点。

可见，cinder-scheduler 的运行机制与 nova-scheduler 完全一样。

Filter

当 Filter scheduler 需要执行调度操作时，会让 filter 对计算节点进行判断，filter 返回 True 或者 False。

cinder.conf 中 scheduler_default_filters 选项指定 filter scheduler 使用的 filter，默认值如下：

scheduler_default_filters = AvailabilityZoneFilter, CapacityFilter, CapabilitiesFilter

Filter scheduler 将按照列表中的顺序依次过滤：

AvailabilityZoneFilter

为提高容灾性和提供隔离服务，可以将存储节点和计算节点划分到不同的 Availability Zone 中。例如把一个机架上的机器划分在一个 Availability Zone 中。

OpenStack 默认有一个命名为“Nova” Availability Zone 的，所有的节点初始都是放在“Nova”中。用户可以根据需要创建自己的 Availability Zone。

创建 Volume 时，需要指定 Volume 所属的 Availability Zone。

cinder-scheduler 在做 filtering 时，会使用 AvailabilityZoneFilter 将不属于指定 Availability Zone 的存储节点过滤掉。

CapacityFilter

创建 Volume 时，用户会指定 Volume 的大小。CapacityFilter 的作用是将存储空间不能满足 Volume 创建需求的存储节点过滤掉。

CapabilitiesFilter

不同的 Volume Provider 有自己的特性（Capabilities），比如是否支持 thin provision 等。Cinder 允许用户创建 Volume 时通过 Volume Type 指定需要的 Capabilities。

Volume Type 可以根据需要定义若干 Capabilities，详细描述 Volume 的属性。VolumeVolume Type 的作用与 Nova 的 flavor 类似。

Volume Type 在 Admin -> System -> Volume 菜单里管理

通过 Volume Type 的 Extra Specs 定义 Capabilities

Extra Specs 是用 Key-Value 的形式定义。 不同的 Volume Provider 支持的 Extra Specs 不同，需要参考 Volume Provider 的文档。

上图所示的 Volume Type 只有一个 Extra Specs “volume_backend_name”，这是最重要也是必须的 Extra Specs。

cinder-volume 会在自己的配置文件 /etc/cinder/cinder.conf 中设置“volume_backend_name”这个参数，其作用是为存储节点的 Volume Provider 命名。

这样，CapabilitiesFilter 就可以通过 Volume Type 的“volume_backend_name”筛选出指定的 Volume Provider。

不同的存储节点可以在各自的 cinder.conf 中配置相同的 volume_backend_name，这是允许的。因为虽然存储节点不同，但它们可能使用的是一种 Volume Provider。

如果在第一步 filtering 环节选出了多个存储节点，那么接下来的 weighting 环节会挑选出最合适的一个节点。

Weighter

Filter Scheduler 通过 scheduler_default_weighers 指定计算权重的 weigher，默认为 CapacityWeigher。

scheduler_default_weighers = CapacityWeigher    

如命名所示，CapacityWeigher 基于存储节点的空闲容量计算权重值，空闲容量最大的胜出。