Cinder 组件详解 - 天天5分钟玩转 OpenStack（47）

本节咱们将详细讲解 Cinder 的各个子服务。

cinder-api

cinder-api 是整个 Cinder 组件的门户，全部 cinder 的请求都首先由 nova-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 上看到。

打开 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 如何与它们配合呢？

这就是咱们以前讨论过的 Driver 架构。 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 如何筛选 cinder-volume。