操作系统得到存储空间一般有两种方式：
在块存储中，裸硬盘通常被称为volume（卷）。
理解了块存储，就能很容易的理解cinder。cinder是OpenStack平台中负责提供块存储服务的组件，它的任务就是管理volume从创建到删除的整个生命周期。cinder的前身是nova中的nova-volume组件，后来被从nova中剥离出来成为一个独立的OpenStack组件。
cinder架构大致可以分为4部分：
它们的关系大致为：
cinder-api对外提供REST API、响应请求、调用cinder-volume，是整个cinder组件的门户。具体来说cinder-api的任务就是：
cinder-volume运行在存储节点上，负责管理具体存储设备的存储空间。每个存储节点都会运行cinder-volume服务，多个存储节点便组成了一个存储资源池。
cinder-volume运行在存储节点，通过OpenStack平台对volume的指令最后都会由cinder-volume完成。但是cinder-volume自身并不是真正的存储设备，真正的存储设备是volume provider，cinder-volume与volume provider一起实现了对volume全生命周期的管理。
但是cinder在这里遇见了和neutron同样的问题，市面上有这么多volume provider，是将cinder-volume设计成与volume provider一一对应的形式吗，但这样就要设计很多代码相似度很高的cinder-volume。在这个问题上，cinder也运用了和neutron同样的思路。
通过驱动架构，cinder-volume为volume provider定义了统一的接口，对于volume provider来说，只要实现这些接口就可以以驱动的形式像插件一样插入OpenStack系统中。
当用户向cinder-api发出请求创建一个volume时，如果用户已经指定存储节点，则cinder-api会直接调用cinder-volume去创建volume；当用户没有指定节点时，cinder-api会将请求发送给cinder-scheduler，然后cinder-scheduler会根据调度算法选择最合适的存储节点创建volume。
volume provider是数据存储设备，为volume提供物理存储空间。cinder-volume支持多种volume provider，每种volume provider通过自己的驱动与cinder-volume协同工作。
与OpenStack的其他服务一样，cinder在部署前也需要在数据库中创建一个名为cinder的database。
前面说到cinder的前身是nova中的nova-volume组件，后来才被单独提出来成为一个OpenStack组件，因此cinder的设计架构和nova十分相像，具体体现在它们各个子组件的功能基本都能对应。
| 前台 | nova-api | cinder-api |
| 经理 | nova-scheduler | cinder-scheduler |
| 外勤 | nova-compute | cinder-volume |
细心的童鞋可能注意到了，nova架构中还有一个nova-conductor充当nova-compute连接数据库的中间件，而cinder却没有，这是为什么呢？
其实nova-compute之所以不能直接连接数据库，是因为它与租户的实例连接紧密，如果它可以连接数据库，那么租户也可以通过nova-compute组件来连接数据库，这样就造成了安全隐患。但对于cinder-volume来说，它部署在存储节点，与租户并无直接联系，也就不用担心租户会通过它连接数据库，因此，cinder并无与nova-conductor类似的组件。
