从 volume 创建流程看 cinder-* 子服务如何协同工作
对于 Cinder 学习来说，Volume 创建是一个非常好的场景，涉及各个 cinder-* 子服务，下面是流程图
.png)
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
上面是创建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作为开发的 Infrastructure 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 的架构示意图：
.png)
在 cinder-volume 的配置文件 /etc/cinder/cinder.conf 中，volume_driver 配置项设置该存储节点使用哪种 volume provider的driver。下面的示例表示使用的是LVM。
[stack@DevStack-Rocky-Controller-31 ~]$ cat /etc/cinder/cinder.conf | grep '_dri'
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver