云计算openstack核心组件——cinder存储服务(11)
一、cinder 介绍: 理解 Block Storage 操作系统获得存储空间的方式一般有两种:
Cinder 包含如下几个组件: cinder-api 接收 API 请求, 调用 cinder-volume 。是整个 Cinder 组件的门户,所有 cinder 的请求都首先由 cinder-api 处理。cinder-api 向外界暴露若干 HTTP REST API 接口。在 keystone 中我们可以查询 cinder-api 的 endponits。
物理部署方案 Cinder 的服务会部署在两类节点上,控制节点和存储节点。我们来看看控制节点 controller 上都运行了哪些 cinder-* 子服务。
cinder-api 和 cinder-scheduler 部署在控制节点上,这个很合理。 至于 cinder-volume 也在控制节点上可能有些同学就会迷糊了:cinder-volume 不是应该部署在存储节点上吗? 要回答这个问题,首先要搞清楚一个事实: OpenStack 是分布式系统,其每个子服务都可以部署在任何地方,只要网络能够连通。无论是哪个节点,只要上面运行了 cinder-volume,它就是一个存储节点,当然,该节点上也可以运行其他 OpenStack服务。 cinder-volume 是一顶存储节点帽子,cinder-api 是一顶控制节点帽子。在我们的环境中,devstack-controller 同时戴上了这两顶帽子,所以它既是控制节点,又是存储节点。当然,我们也可以用一个专门的节点来运行 cinder-volume。 这再一次展示了 OpenStack 分布式架构部署上的灵活性: 可以将所有服务都放在一台物理机上,用作一个 All-in-One 的测试环境;而在生产环境中可以将服务部署在多台物理机上,获得更好的性能和高可用。 RabbitMQ 和 MySQL 通常放在控制节点上。另外,也可以用 cinder service list 查看 cinder-* 子服务都分布在哪些节点上
还有一个问题:volume provider 放在那里? 一般来讲,volume provider 是独立的。cinder-volume 使用 driver 与 volume provider 通信并协调工作。所以只需要将 driver 与 cinder-volume 放到一起就可以了。在 cinder-volume 的源代码目录下有很多 driver,支持不同的 volume provider。
后面我们会以 LVM 和 NFS 这两种 volume provider 为例讨论 cinder-volume 的使用,其他 volume provider 可以查看 OpenStack 的 configuration 文档。
二、 Cinder 的设计思想:
从 volume 创建流程看 cinder-* 子服务如何协同工作
对于 Cinder 学习来说,Volume 创建是一个非常好的场景,涉及各个 cinder-* 子服务,下面是流程图:
在 cinder-volume 的配置文件 /etc/cinder/cinder.conf 中 volume_driver 配置项设置该存储节点使用哪种 volume provider 的 driver,下面的示例表示使用的是 LVM。
三、 Cinder 的配置文件: vim /etc/cinder/cinder.conf
[DEFAULT]
my_ip = 172.16.254.63
glance_api_servers =
http://controller:9292
auth_strategy = keystone
enabled_backends = lvm
transport_url = rabbit://openstack:admin@controller
[backend]
[barbican]
[brcd_fabric_example]
[cisco_fabric_example]
[coordination]
[cors]
[cors.subdomain]
[database]
connection = mysql+pymysql://cinder:CINDER_DBPASS@controller/cinder
[fc-zone-manager]
[healthcheck]
[key_manager]
[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = cinder
password = cinder
[matchmaker_redis]
[oslo_concurrency]
lock_path = /var/lib/cinder/tmp
[oslo_messaging_amqp]
[oslo_messaging_kafka]
[oslo_messaging_notifications]
[oslo_messaging_rabbit]
[oslo_messaging_zmq]
[oslo_middleware]
[oslo_policy]
[oslo_reports]
[oslo_versionedobjects]
[profiler]
[ssl]
[lvm]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-vg
volumes_dir = $state_path/volumes
iscsi_protocol = iscsi
iscsi_helper = lioadm
iscsi_ip_address = 172.16.254.63
扫码关注我们
微信号:SRE实战
拒绝背锅 运筹帷幄
- 通过某种协议(SAS,SCSI,SAN,iSCSI 等)挂接裸硬盘,然后分区、格式化、创建文件系统;或者直接使用裸硬盘存储数据(数据库)
- 通过 NFS、CIFS 等 协议,mount 远程的文件系统
- 提供 REST API 使用户能够查询和管理 volume、volume snapshot 以及 volume type
- 提供 scheduler 调度 volume 创建请求,合理优化存储资源的分配
- 通过 driver 架构支持多种 back-end(后端)存储方式,包括 LVM,NFS,Ceph 和其他诸如 EMC、IBM 等商业存储产品和方案

客户端可以将请求发送到 endponits 指定的地址,向 cinder-api 请求操作。 当然,作为最终用户的我们不会直接发送 Rest API 请求。OpenStack CLI,Dashboard 和其他需要跟 Cinder 交换的组件会使用这些 API。
SRE实战 互联网时代守护先锋,助力企业售后服务体系运筹帷幄!一键直达领取阿里云限量特价优惠。 cinder-api 对接收到的 HTTP API 请求会做如下处理: 1、检查客户端传人的参数是否合法有效 2、调用 cinder 其他子服务的处理客户端请求 3、将 cinder 其他子服务返回的结果序列号并返回给客户端cinder-api 接受哪些请求呢?简单的说,只要是 Volume 生命周期相关的操作,cinder-api 都可以响应。大部分操作都可以在 Dashboard 上看到。
cinder-volume 管理 volume 的服务,与 volume provider 协调工作,管理 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 系统中。
定期向 OpenStack 报告计算节点的状态
cinder-volume 会定期向 Cinder 报告存储节点的空闲容量来做筛选启动volume
实现 volume 生命周期管理
Cinder 对 volume 的生命周期的管理最终都是通过 cinder-volume 完成的,包括 volume 的 create、extend、attach、snapshot、delete 等。
cinder-scheduler scheduler 通过调度算法选择最合适的存储节点创建 volume。 创建 Volume 时,cinder-scheduler 会基于容量、Volume Type 等条件选择出最合适的存储节点,然后让其创建 Volume volume provider 数据的存储设备,为 volume 提供物理存储空间。 cinder-volume 支持多种 volume provider,每种 volume provider 通过自己的 driver 与cinder-volume 协调工作。 Message Queue Cinder 各个子服务通过消息队列实现进程间通信和相互协作。因为有了消息队列,子服务之间实现了解耦,这种松散的结构也是分布式系统的重要特征。 Database Cinder 有一些数据需要存放到数据库中,一般使用 MySQL。数据库是安装在控制节点上的,比如在我们的实验环境中,可以访问名称为“cinder”的数据库。





- 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(cinder-api)发送请求:“帮我创建一个 volume”
- API 对请求做一些必要处理后,向 Messaging(RabbitMQ)发送了一条消息:“让 Scheduler 创建一个 volume”
- Scheduler(cinder-scheduler)从 Messaging 获取到 API 发给它的消息,然后执行调度算法,从若干计存储点中选出节点 A
- Scheduler 向 Messaging 发送了一条消息:“让存储节点 A 创建这个 volume”
- 存储节点 A 的 Volume(cinder-volume)从 Messaging 中获取到 Scheduler 发给它的消息,然后通过 driver 在 volume provider 上创建 volume。
- 对外提供统一接口,隐藏实现细节
- API 提供 REST 标准调用服务,便于与第三方系统集成
- 可以通过运行多个 API 服务实例轻松实现 API 的高可用,比如运行多个 cinder-api 进程



更多精彩