【OpenStack】 Grizzly中的nova-conductor

OpenStack Grizzly中的nova-conductor

声明：
本博客欢迎转发，但请保留原作者信息!
新浪微博：@孔令贤HW；
博客地址：http://blog.csdn.net/lynn_kong
内容系本人学习、研究和总结，如有雷同，实属荣幸！

原文链接：http://russellbryantnet.wordpress.com/2013/02/19/deployment-considerations-for-nova-conductor-service-in-openstack-grizzly/

更新记录：
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节点

这也就意味着Controller节点将比以前运行更多的任务，负载变重，因此有必要对负载做监控，必要时需要扩展contorller服务。比如当在多个节点运行nova-api时，就需要在前端做负载均衡；多个节点运行nova-scheduler或nova-conductor时，负载均衡的任务就由消息队列服务器完成； 


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

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