OpenStack Cinder:块存储服务详解及工作流程

0 下载量 72 浏览量 更新于2024-06-17 收藏 4.17MB PDF 举报
OpenStack的块存储服务Cinder是云计算平台中不可或缺的一部分,专门负责虚拟机实例的块级存储管理。Cinder起源于Nova的“nova-volume”组件,在OpenStack发展过程中独立出来,提供了一套完整的块存储解决方案。 1. **基本概念**: - Cinder的核心职责是管理块存储,即虚拟化的磁盘,它可以为云主机提供类似于物理硬盘的接口。块存储的特点在于其极高的响应速度、高稳定性和可靠性,适用于对性能有较高要求的应用场景,但容量受限于硬件设备。 - 相比之下,文件存储使用文件系统,适合简单的文件共享,兼容性强但速度和容量一般;对象存储则以无结构的对象形式管理数据,适合大量非结构化数据,如图片和视频,具有巨大的存储容量但访问速度相对较慢。 2. **组件架构**: - Cinder包含几个关键模块:cinder-api负责接收和处理来自外部的请求,是管理Cinder的主入口;cinder-volume专注于卷(块)的创建、删除和管理;cinder-scheduler根据策略选择合适的存储节点;volume-provider调用特定的卷管理系统(如LVM、NFS、Ceph等)执行实际操作;volume-backup提供卷备份功能。 3. **工作流程**: - 当用户或应用请求创建一个新的卷时,这个请求首先会被发送到cinder-api。接着,cinder-scheduler会分析当前的存储资源并选择最合适的存储节点。然后,volume-provider会与选定的卷管理系统交互,实际创建或配置新的卷。最后,创建的卷会被挂载到云主机上供应用程序使用,并且可以通过volume-backup模块进行定期备份,确保数据安全。 Cinder作为OpenStack的基石之一,通过精细的组件设计和高效的工作流程,实现了灵活、可扩展的块存储管理,为云计算环境中的虚拟化资源提供了强大的支撑。对于云服务提供商和用户来说,理解并有效利用Cinder是构建高性能、高可用的云基础设施的关键。
2019-07-16 上传
Openstack 从 Folsom 开始使用 Cinder 替换原来的Nova-Volume服务,为 Openstack 云平台提供块存储服务。 Cinder架构                                                  /- ( LDAP )                              [ Auth Manager ] ---                                     |            \- ( DB )                                     |                                     |                    cinderclient     |                   /             \   | [ Web Dashboard ]-               -[ api ] --  -- [ scheduler ] -- [ volume ] -- ( iSCSI )                   \             /   |                    novaclient       |                                     |                                     |                                     |                                   Cinder服务 API service:负责接受和处理Rest请求,并将请求放入RabbitMQ队列。Cinder提供Volume API V2, 我没有找到格式很好的在线文档,大体可以参见Openstack block storage API V1 Scheduler service: 处理任务队列的任务,并根据预定策略选择合适的Volume Service节点来执行任务。目前版本的cinder仅仅提供了一个Simple Scheduler, 该调度器选择卷数量最少的一个活跃节点来创建卷。 Volume service: 该服务运行在存储节点上,管理存储空间。每个存储节点都有一个Volume Service,若干个这样的存储节点联合起来可以构成一个存储资源池。为了支持不同类型和型号的存储,当前版本的Cinder为Volume Service如下drivers。当然在Cinder的blueprints当中还有一些其它的drivers,以后的版本可能会添加进来。 本地存储:LVM, Sheepdog 网络存储: NFS, RBD (RADOS) IBM: XIV, Storwize V7000, SVC storage systems Netapp: NFS存储;ISCSI存储则需要OnCommand 5.0和Data ONTAP 7-mode storage systems with installed iSCSI licenses EMC: VNX, VMAX/VMAXe Solidfire: Solidfire cluster Cinder服务的部署 上述的Cinder服务都可以独立部署,cinder同时也提供了一些典型的部署命令: cinder-all: 用于部署all-in-one节点,即API, Scheduler, Volume服务部署在该节点上。 cinder-scheduler: 用于将scheduler服务部署在该节点上。 cinder-api: 用于将api服务部署在该节点上。 cinder-volume: 用于将volume服务部署在该节点上。 Cinder如何支持典型存储 从目前的实现来看,Cinder对本地存储和NAS的支持比较不错,可以提供完整的Cinder API V2支持,而对于其它类型的存储设备,Cinder的支持会或多或少的受到限制,下面是Rackspace对于Private Cloud存储给出的典型配置: 1. 本地存储 对于本地存储,cinder-volume可以使用lvm驱动,该驱动当前的实现需要在主机上事先用lvm命令创建一个cinder- volumes的vg, 当该主机接受到创建卷请求的时候,cinder-volume在该vg上创建一个LV, 并且用openiscsi将这个卷当作一个iscsi tgt给export. 当然还可以将若干主机的本地存储用sheepdog虚拟成一个共享存储,然后使用sheepdog驱动。 2. EMC 3. Netapp Cinder在IT环境中的主要问题 目前版本的Cinder在IT私有云场景中,从硬件兼容性,高性能,高可靠性,水平扩展能力,应用兼容性等维度来看,Cinder还存在不少问题需要解决。Cinder依然任重道远。 1. 对共享存储的支持有限 不支持FC SAN; 支持的存储设备有限,即使对于EMC, IBM这样的的主流存储厂商,也只能支持寥寥几款存储; 2. 对存储设备的使用不够高效 Cinder卷管理的基本原则是在共享存储上创建一个lun, 然后把这个lun作为一个block device给attach到一个虚拟机上。但是对于当前主流的存储,能够支持的最大lun数量非常有限,比如我们经常使用的Huawei S3900, 最多能支持288个lun,如果一个VM平均3个卷,不管这些VM是offline还是online, 这个存储最多只能支持90个VM。 3. 存储管理带来的性能损耗 比如Cinder Volume的LVM驱动使用iSCSI export一个逻辑卷,从管理的角度来看是解决了存储共享的问题,从而能够支持比如迁移这样的功能,但是这样的设计势必会导致较大的性能损耗,和直接访 问相比,通常iSCSI export会增加30%以上的IO延迟。 4. 数据如何迁移 企业IT环境中大量的数据,一般都是存放在SAN甚至是磁带设备上的,这些数据如何无损,安全的接入到Cloud呢?VMware因此提供了RDM, KVM和XEN也支持PVSCSI, 但是Cinder没有考虑这个。 5. Cinder的调度器不完善 Cinder提供的simple scheduler基本没有实用价值,  cinder-scheduler仅能在初始放置时保证系统负载均衡,但是如果是发生了运行时负载严重不平衡,cinder就没法处理了。 6. Cinder服务的可靠性问题 cinder-api和cinder-scheduler是系统的单点,cinder并没有提供这两个服务提供任何HA和load balance设计,所以整个系统可靠性还是扩展性会比较受限制。 cinder-db如果发生不可恢复的故障,能够保证用户数据能恢复吗? 介绍内容出处:http://blog.csdn.net/luo_brian/article/details/8592692 标签:OpenStack