【OpenStack】 Grizzly中的nova-conductor

OpenStack Grizzly中的nova-conductor

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

原文链接：

在Grizzly版的Nova中，取消了nova-compute的直接数据库访问。大概两个原因：
1. 安全考虑。因为compute节点通常会运行不可信的用户负载，一旦服务被攻击或用户虚拟机的流量溢出，则数据库会面临直接暴露的风险
2. 方便升级。将nova-compute与数据库解耦的同时，也会与模式（schema）解耦，因此就不会担心旧的代码访问新的数据库模式。
目前，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）！内容系本人学习、研究和总结，如有雷同，实属荣幸！