nova分析(5)—— nova-conductor

nova-conductor是nova-compute之上的一个服务,这个服务比较简单,主要封装了DB访问和动态迁移相关的代码。转来一篇文章看看它是如何工作的。

更新记录:
1. 2013.4.19  增加对nova-conductor的优势和劣势分析

正文:
在Grizzly版的Nova中,取消了nova-compute的直接数据库访问。大概两个原因:
1. 安全考虑。
Benefit:因为compute节点通常会运行不可信的用户负载,一旦服务被攻击或用户虚拟机的流量溢出,则数据库会面临直接暴露的风险,增加nova-conductor更加安全。
Limitation:虽然nova-conductor限制了直接DB访问,但compute节点仍然可以通过nova-conductor获取所有节点的虚拟机数据,删除虚拟机等操作。特别是如果使用E版的multihost,nova-api-metadata和nova-network不能使用nova-conductor。这样计算节点仍然是不安全的。
2. 方便升级。
Benefit:将nova-compute与数据库解耦的同时,也会与模式(schema)解耦,因此就不会担心旧的代码访问新的数据库模式。
Limitation:目前rolling upgrade在G版并不ready
3. 性能
Benefit:当使用green thread时,所有的DB访问是阻塞的。而如果使用nova-conductor,可以多线程使用RPC访问。
Limitation:通过RPC访问nova-conductor会受网络时延的影响。同时,nova-conductor的DB访问也是阻塞的,如果nova-conductor实例较少,效果反而会更差

如果希望继续使用本地访问DB,需要配置:
[conductor]
use_local=true

目前,nova-conductor暴露的方法主要是数据库访问,但后续从nova-compute移植更多的功能,让nova-compute看起来更像一个没有大脑的干活者,而nova-conductor则会实现一些复杂而耗时的任务,比如migration(迁移)或者resize(修改虚拟机规格)

部署
nova-conductor是在nova-compute之上的新的服务层。应该避免nova-conductor与nova-compute部署在同一个计算节点,否则移除直接数据库访问就没有任何意义了。同其他nova服务(nova-api, nova-scheduler)一样,nova-conductor也可水平扩展,即可以在不同的物理机上运行多个nova-conductor实例。

经典的部署方式中(一个controller节点,多个compute节点),可以将nova-conductor运行在Controller节点
nova分析(5)—— nova-conductor
这也就意味着Controller节点将比以前运行更多的任务,负载变重,因此有必要对负载做监控,必要时需要扩展contorller服务。比如当在多个节点运行nova-api时,就需要在前端做负载均衡;多个节点运行nova-scheduler或nova-conductor时,负载均衡的任务就由消息队列服务器完成; 
nova分析(5)—— nova-conductor

监控
需要对nova-conductor进行性能监控以便决定是否对服务进行扩展。首先可以监控所在节点的CPU负载;其次可以监控消息队列中的消息个数及大小(对于Qpid: qpid-stat,对于RabbitMQ: rabbitmqctl list_queues)

本博客欢迎转发,但请保留原作者信息(@孔令贤HW  http://blog.csdn.net/lynn_kong)!内容系本人学习、研究和总结,如有雷同,实属荣幸!

本文转自http://blog.csdn.net/lynn_kong/article/details/8606640。

上一篇:AC日记——楼房 codevs 2995


下一篇:nova分析(6)—— nova service启动过程