由浅入深(源码)分析nova的资源刷新机制

本博客欢迎转发，但请保留原作者（@孔令贤HW）信息！内容系本人学习、研究和总结，如有雷同，实属荣幸！

1      python中的元类

今天偶尔得空学习openstack，就随便找来一个类看，nova/manager.py中的Manager类，类的第一行就看不懂了：

__metaclass__ = ManagerMeta

由于自己的编程语言是java，对于python中有些技巧还不熟悉，于是google之，顺便学习了python中的元类（Metaclasses），不懂的朋友可以看这个：http://www.cnblogs.com/coderzh/archive/2008/12/07/1349735.html。而在Manager的元类中除了初始化对象外，还做了如下操作：

 

即：如果对象中某个属性值中有’_periodic_task’属性为true，就把该属性名和属性本身加入_periodic_tasks变量。而_periodic_tasks是干啥的？

2      _periodic_tasks是什么？

带着疑问大致过了下Manager类，发现有如下方法引用了_periodic_tasks变量：

 

在该函数中，从_periodic_tasks中拿到task并运行。看来task应该是一个函数。

 

通过看manager.py文件可知，该文件除了Manager类外，还有一个继承自Manager类的SchedulerDependentManager类，以及一个装饰器periodic_task，巧的是，SchedulerDependentManager类的方法_publish_service_capabilities就用到了该装饰器。那么我们来看一下periodic_task。

3      装饰器periodic_task

 

这里看到了_periodic_task，熟悉吧，回头看一下第一节可知，如果函数被装饰器装饰，那么就被加入到_periodic_tasks中，即：SchedulerDependentManager类的方法_publish_service_capabilities被加入到了_periodic_tasks变量中并在某一时刻被执行。我们先来看这个函数干了什么吧。

4      _publish_service_capabilities干了什么？

 

众所周知，openstack各个组件之间是通过实现AMQP协议的消息队列通信，我们看到函数中向nova-scheduler发送了消息，调用nova-scheduler的对应函数处理，其中的参数看名称应该能猜到大致的意思，service_name服务名称，host表示主机，last_capabilities应该是某种信息。

 

对函数功能猜想：nova-scheduler是nova中负责调度的组件，用于在创建虚拟机或创建卷时根据策略选择主机，而选择的依据，对于创建虚拟机来讲不难猜出应该就是主机的资源（CPU、内存等），而资源数据从哪来？数据库？还是各个主机定时上报？从功能上来讲，_publish_service_capabilities的行为更符合第二种。但资源的上报不可能只运行一次，应该是个周期行为，从装饰器的名称上也能看出来。那么periodic_tasks这个函数是什么时候被循环调用的呢？我想应该是在Manager所属的服务（对于创建虚拟机来说，就是nova-compute）初始化时。

5      验证猜想

我们来到nova-compute初始化的地方（在我以前的文章中有对nova初始化的分析），在nova/service.py中Service类的start方法里看到了如下实现：

 

 

看到了！periodic_tasks方法果然是在循环中被调用。来看下Manager的继承关系：

 

6      上报了什么以及如何上报？

虽然猜想是对的，但目前我们仍然不知道，_publish_service_capabilities到底给nova-scheduler上报了什么内容。回头看_publish_service_capabilities方法的逻辑：当last_capabilities变量有内容时才上报。而对last_capabilities变量的修改动作发生在同一个类的另外一个方法：update_service_capabilities。那么，什么地方调用了update_service_capabilities了呢？

 

我想到了eclipse中万能的搜索功能，哈哈，找到了：

 

双击来到ComputeManager类：

 
  

有没有什么内容是非常熟悉的？

对了，_report_driver_status这个函数也是被periodic_task装饰器修饰，而这个函数又是Manager（父类）的方法，那么，该函数也是被循环调用的。

 

我们先来理一下思路：

首先，nova-compute服务启动时，启动了一个自定义的定时器，每隔固定的时间（可以通过配置文件配置）就运行一次。在每次的运行过程中，会调用一些方法。而_report_driver_status方法和update_service_capabilities方法是其中的两个，并且_report_driver_status方法可以触发update_service_capabilities方法真正执行动作，向nova-scheduler上报内容。

7      _report_driver_status

好了，大的流程清楚了，我们就来详细看看上报信息中的capabilities到底是什么东西？

 

由上面的代码截图可知，capabilities是由ComputeManager类的driver对象的get_host_stats方法得到。而driver即是虚拟化实现类，比如nova/virt/libvert/driver.py中的LibvertDriver类，找到方法实现：

 

接着跟进同一个文件中的HostState类：

 

呜呼~~真相大白！不用我说，上面的代码已经很清楚的说明了上报的内容。

8      总结

以前我一直以为openstack是两层架构，多个节点，松耦合，一个共享DB的系统。因为有共享DB的存在，不同节点的信息沟通（注意：这里我指的不是接口调用）只需访问数据库即可。对应到资源，我原本以为是计算节点定期将自己的信息写入DB，而scheduler在调度时从DB中读取资源数据即可。

 

然而通过以上的分析，发现是将对DB的压力转移到了nova-scheduler进程，通过消息队列来进行信息的传递。因为没有大规模集群，所以对于当节点数目上去之后，消息队列以及nova-scheduler进程能不能支撑如此频繁调用和如此大的数据量，我给不出结论，算是留一个问题吧。

 

而对于数据库的话，目前应该有很多减轻压力的解决方案来应对上面的情况，因为我对数据库是个白痴，因此不做分析。

 

另外，对于openstack使用的这种定时任务的机制，是非常值得我们学习、理解和使用的。

本博客欢迎转发，但请保留原作者（@孔令贤HW）信息！内容系本人学习、研究和总结，如有雷同，实属荣幸！

评论

4 楼 lynnkong 2013-01-23  

lzy.je 写道

Yep,
Design wiki doc: http://wiki.openstack.org/blueprint-nova-compute-cells
Chris Behrens PPT from design submmit: http://comstud.com/FolsomCells.pdf

Thanks a lot!

3 楼 lzy.je 2013-01-22  

lynnkong 写道

lzy.je 写道

1. Cells mechanism in grizzly release will take care hot messaging issue.
2. Some sounds from community want to separate periodic_task executing from green thread to sub-process, this could reduce task hang and allow  periodic_task mechanism suppot long-run task/script.

Thanks for your reply!
Could you please tell some links for description of 'Cells mechanism'?

Yep,
Design wiki doc: http://wiki.openstack.org/blueprint-nova-compute-cells
Chris Behrens PPT from design submmit: http://comstud.com/FolsomCells.pdf

2 楼 lynnkong 2013-01-19  

lzy.je 写道

1. Cells mechanism in grizzly release will take care hot messaging issue.
2. Some sounds from community want to separate periodic_task executing from green thread to sub-process, this could reduce task hang and allow  periodic_task mechanism suppot long-run task/script.

Thanks for your reply!
Could you please tell some links for description of 'Cells mechanism'?

1 楼 lzy.je 2013-01-16  

1. Cells mechanism in grizzly release will take care hot messaging issue.
2. Some sounds from community want to separate periodic_task executing from green thread to sub-process, this could reduce task hang and allow  periodic_task mechanism suppot long-run task/script.