Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说Cinder详解_infor软件使用介绍,希望能够帮助你!!!。

理解cinder

操作系统得到存储空间一般有两种方式：

• 块存储：挂接裸硬盘，分区，格式化，创建文件系统；或者直接使用裸硬盘存储数据
• 文件系统存储：通过nfs等方式挂载远程的文件系统

在块存储中，裸硬盘通常被称为volume（卷）。

理解了块存储，就能很容易的理解cinder。cinder是OpenStack平台中负责提供块存储服务的组件，它的任务就是管理volume从创建到删除的整个生命周期。cinder的前身是nova中的nova-volume组件，后来被从nova中剥离出来成为一个独立的OpenStack组件。

cinder架构

cinder架构大致可以分为4部分：

• cinder-api
• cinder-scheduler
• cinder-volume
• cinder-backup

它们的关系大致为：

cinder-api

cinder-api对外提供REST API、响应请求、调用cinder-volume，是整个cinder组件的门户。具体来说cinder-api的任务就是：

• 检查客户端传入的参数是否有效
• 调用cinder其他子组件处理客户端请求
• 将其他子组件处理的结果返回客户端

cinder-volume

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-scheduler

当用户向cinder-api发出请求创建一个volume时，如果用户已经指定存储节点，则cinder-api会直接调用cinder-volume去创建volume；当用户没有指定节点时，cinder-api会将请求发送给cinder-scheduler，然后cinder-scheduler会根据调度算法选择最合适的存储节点创建volume。

volume provider

volume provider是数据存储设备，为volume提供物理存储空间。cinder-volume支持多种volume provider，每种volume provider通过自己的驱动与cinder-volume协同工作。

cinder DB

与OpenStack的其他服务一样，cinder在部署前也需要在数据库中创建一个名为cinder的database。

cinder设计思想

前面说到cinder的前身是nova中的nova-volume组件，后来才被单独提出来成为一个OpenStack组件，因此cinder的设计架构和nova十分相像，具体体现在它们各个子组件的功能基本都能对应。

细心的童鞋可能注意到了，nova架构中还有一个nova-conductor充当nova-compute连接数据库的中间件，而cinder却没有，这是为什么呢？
其实nova-compute之所以不能直接连接数据库，是因为它与租户的实例连接紧密，如果它可以连接数据库，那么租户也可以通过nova-compute组件来连接数据库，这样就造成了安全隐患。但对于cinder-volume来说，它部署在存储节点，与租户并无直接联系，也就不用担心租户会通过它连接数据库，因此，cinder并无与nova-conductor类似的组件。

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。