Cinder组件
cinder-api
cinder-api 是整个 Cinder 组件的门户,所有 cinder 的请求都首先由 cinder-api 处理。
cinder-api 向外界暴露若干 HTTP REST API 接口。在 keystone 中我们可以查询 cinder-api 的 endponits。
![](https://app.yinxiang.com/shard/s4/res/07498020-04a8-4bdc-a79e-69fc148b4097.jpg)
客户端可以将请求发送到 endponits 指定的地址,向 cinder-api 请求操作。 当然,作为最终用户的我们不会直接发送 Rest API 请求。
cinder-api 对接收到的 HTTP API 请求会做如下处理:
-
检查客户端传人的参数是否合法有效
-
调用 cinder 其他子服务的处理客户端请求
-
将 cinder 其他子服务返回的结果序列号并返回给客户端
cinder-api 接受哪些请求呢?简单的说,只要是 Volume 生命周期相关的操作,cinder-api 都可以响应。大部分操作都可以在 Dashboard 上看到。
打开 Volume 管理界面
![](https://app.yinxiang.com/shard/s4/res/25750f16-9673-44ca-9593-eed0544528d7.jpg)
点击下拉箭头,列表中就是 cinder-api 可执行的操作。
![](https://app.yinxiang.com/shard/s4/res/662e6a97-3779-494f-9aab-76310aa8fe7e.jpg)
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 的架构示意图:
![](https://app.yinxiang.com/shard/s4/res/f881ef50-59e4-4492-904c-39c59e173e6a.jpg)
我们可以在 /opt/stack/cinder/cinder/volume/drivers/ 目录下查看到 OpenStack 源代码中已经自带了很多 volume provider 的 Driver:
![](https://app.yinxiang.com/shard/s4/res/0e292c32-dedc-48f3-93f9-081a75eb1db1.jpg)
存储节点在配置文件 /etc/cinder/cinder.conf 中用 volume_driver 选项配置使用的driver:
![](https://app.yinxiang.com/shard/s4/res/fd37d80d-1681-40f9-af9a-11e5f20d84aa.jpg)
这里 LVM 是我们使用的 volume provider。
定期向 OpenStack 报告计算节点的状态
在前面 cinder-scheduler 会用到 CapacityFilter 和 CapacityWeigher,它们都是通过存储节点的空闲容量来做筛选。
那这里有个问题:Cinder 是如何得知每个存储节点的空闲容量信息的呢?
答案就是:cinder-volume 会定期向 Cinder 报告。
从 cinder-volume 的日志 /opt/stack/logs/c-vol.log 可以发现每隔一段时间,cinder-volume 就会报告当前存储节点的资源使用情况。
![](https://app.yinxiang.com/shard/s4/res/a2c49357-03d5-41bb-a2f0-4538e0013897.jpg)
因为在我们的实验环境中存储节点使用的是 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 调度过程如下:
-
通过过滤器(filter)选择满足条件的存储节点(运行 cinder-volume)
-
通过权重计算(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。
![](https://app.yinxiang.com/shard/s4/res/5ea08866-069e-46f9-a209-1c8605109a2b.jpg)
创建 Volume 时,需要指定 Volume 所属的 Availability Zone。
![](https://app.yinxiang.com/shard/s4/res/d33ab335-c5dd-4318-9587-bd90788e78bd.jpg)
cinder-scheduler 在做 filtering 时,会使用 AvailabilityZoneFilter 将不属于指定 Availability Zone 的存储节点过滤掉。
CapacityFilter
创建 Volume 时,用户会指定 Volume 的大小。CapacityFilter 的作用是将存储空间不能满足 Volume 创建需求的存储节点过滤掉。
![](https://app.yinxiang.com/shard/s4/res/a2fd7f67-7fbe-4e88-99d9-8e4e16e638cc.jpg)
CapabilitiesFilter
不同的 Volume Provider 有自己的特性(Capabilities),比如是否支持 thin provision 等。Cinder 允许用户创建 Volume 时通过 Volume Type 指定需要的 Capabilities。
![](https://app.yinxiang.com/shard/s4/res/9d3358cd-6416-48f4-ae02-5859935a0eaa.jpg)
Volume Type 可以根据需要定义若干 Capabilities,详细描述 Volume 的属性。VolumeVolume Type 的作用与 Nova 的 flavor 类似。
Volume Type 在 Admin -> System -> Volume 菜单里管理
![](https://app.yinxiang.com/shard/s4/res/1de2a48c-677d-4ffb-8eb9-9b4ea5730ffd.jpg)
通过 Volume Type 的 Extra Specs 定义 Capabilities
![](https://app.yinxiang.com/shard/s4/res/3a120511-ee64-4fc1-8c27-5b931a21f0f2.jpg)
Extra Specs 是用 Key-Value 的形式定义。 不同的 Volume Provider 支持的 Extra Specs 不同,需要参考 Volume Provider 的文档。
![](https://app.yinxiang.com/shard/s4/res/66bc4311-add5-4d8e-8eb9-2079fb752427.jpg)
上图所示的 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 基于存储节点的空闲容量计算权重值,空闲容量最大的胜出。