OpenStack入门之核心组件梳理(4)——Cinder篇

前言

​ 在讲述Nova项目的文章中,笔者提到过Nova-Volume这一个子项目,这就是目前OpenStack中Cinder项目的前身。

​ 本文紧接之前各个组件的讲解,继续介绍OpenStack中核心组件之一的Cinder项目(块存储)相关理论知识。分别从这进行介绍:

一、简述Cinder概念与作用

1.1块存储的概念

​ Cinder项目是OpenStack中为Nova项目所实现的虚拟机实例提供数据可持久性的块存储服务,其前身为Nova项目中的子项目Nova-Volume。不清楚存储的相关基本知识可能不明白这个"块"是什么意思。简单举个例子来说,块存储可以理解为我们笔记本中的硬盘,可以是机械硬盘或者是固态硬盘,这个大家应该耳熟能详了哈。

​ 那么,再来说一下存储。存储,顾名思义,就是存放数据信息的,就比如实际生活中的库房、储物柜、收纳箱等等;存储也正如这些实际例子一样,也有自己的类型以及方式,本文旨在讲述OpenStack中的块存储理论,存储的分类以及方式就不做具体介绍了。

1.2cinder项目的作用

​ 在OpenStack中,存储是其管理和提供的三大核心资源之一,因此,对于存储的作用需要有所了解。

  1. 为Nova项目所实现的虚拟机实例提供数据持久化存储服务;

  2. 块存储提供了Volumes的管理基础架构去,并且负责其快照和类型管理;

  3. cinder通过插件形式为存储后端提供了访问的API接口;

​ 块存储服务通常以存储卷的形式挂载到虚拟机上来使用,通过统一的API接口,存储客户端可以访问不同的存储资源,无需担心底层的存储驱动。

二、浅谈块存储、对象存储以及文件系统存储

​ OpenStack集群中的存储通常分为块存储、对象存储和文件系统存储。下面简述一下这三者的概念。

2.1块存储

​ 块存储就是通过SAN或iSCSI等存储协议将存储设备端的卷(Volume)挂载到虚拟机上并进行分区和格式化,然后挂载到本地文件系统使用的存储实现方式。

2.2 文件系统存储

​ 文件系统存储就则是通过NFS或CIFS(Samba)等网络文件系统协议将远程文件系统挂载到本地系统使用的存储实现方式。

2.3对象存储

​ 相对而言,对象存储在实现和使用方式上与块存储和文件系统存储都不同,对象存储是一种以REST API方式提供数据访问的存储实现方式。

​ 通常在OpenStack中,块存储是使用最多的数据存储实现方式。接下来介绍一下Cinder项目的主要组件构成。

三、块存储主要组件

​ 本小节将介绍Cinder项目中主要的组件。

3.1Cinder-api

​ Cinder-api是一种WSIG类型的应用服务,其主要负责接收来自Horizon或命令行客户端的块存储API请求,同时负责请求客户端的身份信息验证(通过Keystone项目实现)。

​ Cinder-api接收到客户端请求后,根据Cinder-scheduler的存储后端调度结果,将请求API路由到运行Cinder-volume服务的对应后端存储上。

3.2Cinder-scheduler

​ Cinder-scheduler,与Nova-scheduler的功能类似,Cinder-scheduler是Cinder项目的后端Volumes的服务调度器。当Cinder-api接收到客户端请求后,将由Cinder-scheduler服务来负责API的路由。

​ 根据用户配置的计划策略,Cinder-api请求可以采用形如RR的轮询方式路由到运行Volume服务的各个存储节点,也可以采用FilterScheduler来实现更为复杂和智能的后端存储节点过滤策略。在Cinder的配置中,FilterScheduler是默认设置,通过FilterScheduler的配置可以实现基于Capacity、Availability Zone、Volume Types、Capabilities或者用户自定义过滤策略的后端存储节点调度。

3.3Cinder-volume

​ Cinder-volume是Cinder项目中真正提供块存储和不同存储驱动插件管理的服务。OpenStack对Volume的操作,最后都是交给cinder-volume来完成的。

​ Cinder-volume服务通过AMQP与Cinder-scheduler进行交互,将其所管理的各个存储驱动后端的运行、性能和容量等参数实时传递到Cinder-scheduler,以便Cinder-scheduler根据这些参数进行存储节点的调度。此外,Cinder-volume通过驱动架构实现与不同存储驱动后端的交互。

3.4Cinder-backup

​ Cinder-backup为块存储卷(Volumes)提供了备份服务,要实现Volumes的备份,需要提供备份存储驱动的实现,目前比较常见的备份存储后端由Swift提供。与Cinder-volume类似,Cinder-backup也通过Driver(驱动)插件架构的形式与不同的存储备份后端交互。

3.5MESSAGE QUEUE

​ Cinder项目的不同内部服务组件之间通过Queue进行消息交互。Cinder中各个服务之间通过消息队列进行通信可以参考下图:

3.6 Database

​ Cinder有一些数据需要存放到数据库中,一般使用的数据库为MySQL。

四、块存储基本架构

​ 接下来来理解一下Cinder的基本架构,如下图所示:

​ 通过该架构图我们可以将Cinder项目的服务与其他的服务联系起来理解。用户提供Horizon项目提供的Web可视化界面客户端或命令行客户端与Cinder-api进行交互,Cinder-api通过Keystone通过的认证服务验证用户身份,接着使用MQ消息队列与Cinder-volume通信,Cinder-volume凭借驱动插件管理由volume provider提供的各种存储后端,并且将相关信息写入数据库中保存。

​ 以上就是Cinder项目架构中对应的服务与其他项目服务之间的交互说明,下面一小节将通过一个例子来解释cinder内部各个的交互原理及过程。

五、块存储内部组件工作原理

​ 假设,用户需要创建一块磁盘空间,或者说一个存储卷。那么cinder内部的工作流程是这样的:

1、用户发送一个创建新卷的请求给Cinder-api;

2、Cinder对该请求进行必要处理(如响应及验证等),于是往Message Queue中放入一条创建卷的信息给Cinder-scheduler;

3、Cinder-scheduler接收到该信息后执行相应的算法,在一群存储节点上选择一个相对较合适的节点;

4、于是Cinder-scheduler又往消息队列中存放了一条让被选出的存储节点来创建这个卷的信息;

5、被选出的存储节点的Cinder-volume接收到该信息,便通过驱动及对应的volume provider上创建该卷。

该过程可以通过下面的流程图来演示:

六、Cinder项目总结

​ 对于Cinder项目,首先明白其在OpenStack中的作用作用,提供的是什么样的服务。另外明白其基本架构以及对应的工作流程。本文对Cinder的介绍大致这些,当然,Cinder项目中有关其具体的使用以及插件的介绍在这里就不继续深入了,有兴趣的朋友可以查一下相关资料。

​ 谢谢您的阅读!