掌握 Cinder 的设计思想 - 天天5分钟玩转 OpenStack（46）

上一节介绍了 Cinder 的架构，这节讨论 Cinder 个组件如何协同工做及其设计思想。

从 volume 建立流程看 cinder-* 子服务如何协同工做

对于 Cinder 学习来讲，Volume 建立是一个很是好的场景，涉及各个 cinder-* 子服务，下面是流程图。

1. 客户（能够是 OpenStack 最终用户，也能够是其余程序）向 API（cinder-api）发送请求：“帮我建立一个 volume”

2. API 对请求作一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 建立一个 volume”

3. Scheduler（cinder-scheduler）从 Messaging 获取到 API 发给它的消息，而后执行调度算法，从若干计存储点中选出节点 A

4. Scheduler 向 Messaging 发送了一条消息：“让存储节点 A 建立这个 volume”

5. 存储节点 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。

下一节咱们将详细讨论 Cinder 的每个组件。