cinder 服务启动与请求流程源码分析

文章以ocata版本进行分析

cinder   api 的创建和启动,和 nova   api 类似,都是通过在 api-paste.ini 中定义 app ,然后将 app 加载之后,启动 wsgi 服务

cinder 服务启动与请求流程源码分析

走 keystone 验证的 cinder 服务,最后走 apiv3

cinder 服务启动与请求流程源码分析

由此, cinder   api 的入口就找到了。

api 请求的 router ,指定了 cinder/api/v3/volumes.py:VolumeController   作为实现 volume 增删改查的控制器。其中包括了 create /delete/get 等方法。

以 create 方法举例,先取出 request 的 body 数据,然后对 body 中的数据进行验证,重组,然后调用 volume_api

cinder 服务启动与请求流程源码分析

这里的 volume_api 指的是 cinder/volume/api.py:create   方法还是针对数据进行进一步格式化,然后使用 taskflow ,完成复杂的 volume 的创建。这个taskflow工具的大致工作方式是,创建一个 flow ,然后再 flow 中添加task ,每一个 task 要实现一个 execute 方法,作为执行函数,然后按步骤执行 task ,每一个 task 必须在前一个 task 成功执行的前提下才能执行,并支持回滚,需要继承指定类,重写 execute 执行方法和 revert 回滚方法。

这里的 api_flow 使用了 linear_flow ,也就是线形顺序依次执行,回滚也是按照倒叙依次回滚, revert 回滚方法会接收到 execute 方法执行的结果作为参数,以便进行相应的回滚操作。

cinder 服务启动与请求流程源码分析

首先第一个 task 是: ExtractVolumeRequestTask

这个 task 主要是完成对数据的检查,权限的验证等等,最后返回的还是创建参数 dict :

cinder 服务启动与请求流程源码分析

然后进入下一个 task : QuotareserveTask 。

这个 task 主要是对 quota (配额)进行预展,保证创建的资源不会超过 quota 配额。

查看这个 task 下的 execute 方法:

cinder 服务启动与请求流程源码分析

先调用 QUOTAS 模块( cinder/quotas.py )的 limit_check   检查 values 参数中的 quota 是否满足条件,这里可以看到检查的是 per_volume_gigabytes 。这个 quota 的含义是每一个 volume 的最大容量上限。其他的 quota 项可以通过 cinder 命令查看:

cinder 服务启动与请求流程源码分析

通过 quota 验证之后,再进行预占资源:

cinder 服务启动与请求流程源码分析

还是调用 QUOTAS 模块中的方法,这里预占的资源是, volume : 1 指占用 volume 一个, gigabytes : size 指占用资源 size 。

QUOTAS.reserve 方法将要预占的资源项目写入到数据库中,对应的相关数据可以查看 mysql cinder 库中的 reservations 表:

cinder 服务启动与请求流程源码分析

这里的数据表示了每一次的资源预占情况,之后 满足条件的情况下 ,则预占资源会更新到实际的 quota_usages 表中(下图),然后将 reservations 中的数据逻辑删除(上图: deleted=1 )

cinder 服务启动与请求流程源码分析

回到 task 中。

预占资源成功之后会返回对应的数据结果 :

cinder 服务启动与请求流程源码分析

如果失败,会调用 revert 方法:

cinder 服务启动与请求流程源码分析

可以看到这里会获取 reservations ,然后做 quota 的 rollback 。其他的 task 也是类似,不再赘述。

进入下一个 task:EntryCreateTask:

这个 task 的任务是生成 volume 对象,然后写入数据库:

cinder 服务启动与请求流程源码分析

再下一个 task 是: QuotaCommitTask :这个 task 将占用的 quota ( reservations )   更新到   正式的 quota 表中:

cinder 服务启动与请求流程源码分析

这时,数据验证和数据库方面的工作就完成了,接下来的工作就是下发创建 volume 的实际任务给 cinder   volume :

cinder 服务启动与请求流程源码分析

可以看到后续的 VolumeCastTask 包括 scheduler 和 volume ,一个是调度,一个是创建。

这个 task 的 execute 方法:

cinder 服务启动与请求流程源码分析

继续调用 cast_create_volume 方法:

cinder 服务启动与请求流程源码分析

这块根据传参决定是由 cinder   scheduler 调度选择节点创建 volume   还是   指定 host 创建。

这里按照普通的步骤,从 scheduler 调度开始往下跟踪,因为最终还是会调用 volume_rpcapi.create_volume 的。

进入 cinder/scheduler/rpcapi.py : create_volume :

cinder 服务启动与请求流程源码分析

这里先创建一个 worker ,用来记录工作的开始。

然后向 scheduler 发送消息: create_volume

接收这个消息的是 cinder/scheduler/manager.py:create_volume:

cinder 服务启动与请求流程源码分析

这里有个装饰器,对应上面的 worker 。

方法调用了 create_volume.get_flow 方法,这个方法也是一个 taskflow 实现的工作流:

这个方法是 cinder   scheduler 的工作流实现:

cinder 服务启动与请求流程源码分析

这个 flow 也是一个线性 flow : linear   flow ,里面添加了两个 task:ExtractSchedulerSpecTask   和 SchedulerCreateVolumeTask

ExtractSchedulerSpecTask :   整合 volume 的数据

具体细看下面的 task

SchedulerCreateVolumeTask :调用对应 driver ,进行创建 volume 的动作。

cinder 服务启动与请求流程源码分析

execute 方法,直接调用了 driver 的 scheduler_create_volume 方法:

这里的 self.driver_api 是在 schedulerManager 的 init 方法中初始化的

cinder 服务启动与请求流程源码分析

默认配置使用的是: cinder.scheduler.filter_scheduler.FilterScheduler

cinder 服务启动与请求流程源码分析

先调用 scheduler 方法,选择一个调度创建的存储后端 backend ,然后将这个后端信息更新到 volume 的数据库对象中,

这里有一步 post   select   populate   filter   properties ,好像是将此次调度到的存储节点保存,以确保当此次失败之后,重试操作不会再一次调度到这个节点上。

最后使用 rpc 发送创建消息,这里的 volume_rpcapi 是 cinder   volume 的 rpc   client ,这个 client 负责向 cinder   volume 服务发送 create_volume 的消息,接受并处理此消息

的是 cinder/volume/manager.py : create_volume 。跟踪此方法,还是使用了 taskflow 实现的

cinder 服务启动与请求流程源码分析

这个 flow 里添加的 task 包括

cinder 服务启动与请求流程源码分析

ExtractVolumeRefTask :刷新数据库 volume 的数据

OnFailureRescheduleTask:   主要是 task 失败 revert 的相关处理

ExtractVolumeSpecTask: 针对创建的参数进行数据重组,例如从 snapshot 创建, clone 等

NotifyVolumeActionTask: 想对应的 host 发送 create.start   的 notifier

CreateVolumeFromSpecTask: 根据对应的 create_type ,调用对应的方法,比如:创建 raw 类型的 volume ,会调用对应 driver 的创建方法:

cinder 服务启动与请求流程源码分析

CreateVolumeOnFinishTask: 这一步根据上一步的创建结果,更新数据库的 volume 状态

cinder 服务启动与请求流程源码分析

接下来深入到 driver 的创建方法中:

以 lvm 为例, lvm 的 driver 为例。

在 cinder/volume/manager.py   : VolumeManager   中,初始化了

cinder 服务启动与请求流程源码分析

跟踪代码到 LVMVolumeDriver 下的 create_volume 中:

cinder 服务启动与请求流程源码分析

这里使用了 self.vg, 这个 vg 是在哪里初始化的呢?

回到最初的 cinder   service 的启动代码里: cinder/service.py

cinder 服务启动与请求流程源码分析

这里有个 self.manager.init_host 调用,这个 manager 也就是上面的 VolumeManager ,这里调用了 init_host 方法,那 VolumeManager 的 init_host 有哪些内容?

cinder 服务启动与请求流程源码分析

可以看到调用了 driver 的 check_for_setup_error()

这个方法的实现,在对应的 lvm   driver 中:

cinder 服务启动与请求流程源码分析

在这里初始化了 self.vg 。

所以这个 self.vg 就跟踪到了 cinder/brick/local_dev/lvm.py 。

也就是说 cinder/volume/drivers/lvm.py 中的方法最终调用到 cinder/brick/local_dev/lvm.py

当前分析的 create_volume 如下:

cinder 服务启动与请求流程源码分析

可以看到调用了 lvcreate 命令,进行了最终的 volume 的创建

上一篇:struts2请求过程源码分析(转)


下一篇:CBV请求流程源码分析