OpenStack组件--Cinder

本文介绍了OpenStack Cinder组件,它是从Nova中分离出来的持久性块存储服务。Cinder提供了统一的接口来管理不同后端存储设备上的卷、卷的类型、快照及备份等功能。文章详细阐述了Cinder的逻辑架构及其各个组成部分。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Cinder简介

OpenStack 在Folsom 版本开始,将之前在 Nova 中的部分持久性块存储功能(Nova-Volume)分离了出来,独立为新的组件 Cinder。
cinder的核心功能是对卷的管理,允许对卷、卷的类型、卷的快照、卷备份进行处理。它为后端不同的存储设备提供了统一的接口,不同的块设备服务厂商在 cinder 中实现其驱动支持以与 OpenStack 进行整合。

Cinder逻辑架构

在这里插入图片描述

Cinder组件

1.Cinder Client封装Cinder提供的rest接口,以CLI形式供用户使用。
2.Cinder API对外提供rest API,对操作需求进行解析,对API进行路由寻找相应的处理方法。包含卷的增删改查(包括从源卷、镜像、快照创建)、快照增删改查、备份、volume type管理、挂载/卸载(Nova调用)等。
3.Cinder schuduler负责收集backend上报的容量、能力信息,根据设定的算法完成卷到指定cinder-volume的调度。
4.Cinder volume多节点部署,使用不同的配置文件、接入不同的backend设备,由各存储厂商插入driver代码与设备交互完成设备容量和能力信息收集、卷操作。
5.Cinder backup实现将卷的数据备份到其他存储介质(目前SWIFT/Ceph/TSM提供了驱动)。
6.SQL DB提供存储卷、快照、备份、service等数据,支持Mysql、PG、MSSQL等SQL数据库。

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
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值