【OpenStack】Quantum(Grizzly)中的agent

Quantum(Grizzly)中的agent

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

更新记录：
2013.5.2  创建network时的流程图与代码有些不太一致，澄清之

OpenStack的G版中agent机制的变化还是比较大的，昨天看到mirantis发表了一篇Blog简单分析了G版和F版中quantum agent。链接：Anew agent management approach for Quantum in OpenStack Grizzly。同时，国内的沙克大师也将其转载并谈了自己的简单分析，链接：陈沙克日志。这里，我从代码层面详细的介绍一下G版中的agent以及自己的一点理解，欢迎拍砖！

extension

G版中增加了两个关于agent的extension，alias分别是agent和agent_scheduler，相应的，增加了几个新的资源（resource），每一个资源的属性和操作用下图一目了然：


如上图，以前quantum中的quantum agent, dhcp agent, l3 agent现在都是Agent对象（注意Agent对象目前不能调用API创建），在节点上部署之后，通过消息队列将自己的信息通知plugin，plugin将agent信息管理起来，为后续的调度使用。

以dhcp agent为例（l3 agent同理）：
在Folsom版本，一个环境中只有一个dhcp agent，该负责整个环境中虚拟机的IP地址分配。在Grizzly版，可以部署多个dhcp agent，每一个agent负责为指定的network内的虚拟机分配IP地址，有两种方法绑定agent和network：
1. 手动模式：调用上图中的agent/{agent_id}/dhcp-network中的create方法，手动将某个network与agent绑定
2. 自动模式：创建network时，quantum会根据调度算法选择一个agent，将其与network绑定
目前Grizzly版本中，调度算法仅仅是一个随机选取，后续会做成与Nova，Cinder一样，会有提供很多调度算法供选择。
一旦agent与network绑定，后续该network上面的subnet，port操作，都只会通知该agent

引用mirantis Blog中的一张create_network流程图：

（2013.5.2号新增）在G版的代码中，创建network的流程与上图有些不一致的地方。创建网络时不会立即选择一个dhcp agent关联，管理员可以在network创建成功后调用接口关联agent（手动模式）。而在创建port时，会判断port所属的network是否关联有dhcp agent，如果没有，则此时会根据算法选择一个agent进行关联，同时向该agent发送创建network的通知，然后再发送创建port的通知。

agent服务

在Folsom版本中，agent仅仅是一个python进程，使用一个脚本管理，自生自灭。在Grizzly中，将agent作为服务启动，需要定时上报自身状态和一些信息，供plugin管理和调度。还是以dhcp agent为例，用图的方式讲解agent的启动步骤。

总结

Essex版本的multihost模式，是在每个计算节点都部署nova-network，Folsom版本也可以使用nova-network代替不太成熟的Quantum。但OpenStack的发展方向是Quantum，后续很多advanceservice都是基于Quantum，且已经停止了对nova-network的开发维护，所以G版以后主流的部署方式还是Quantum。

当使用nova-network时，碰到的一个典型问题就是单点故障（SPoF），因为一套环境中只有一个nova-network，负责分配IP和NAT，大规模部署情况下，该节点负载会很高，是整个网络的性能瓶颈。于是，主流的解决办法是采用multihost模式，即在每个计算节点都部署nova-network，只负责该节点上虚拟机的IP分配和NAT，这样把整个网络的流量平均分到了每个计算节点上，而且相互之间没有依赖关系，大大提高了可用性、可靠性。

最初的Quantum，是不支持multihost部署的，但有了agentschedule，可以以类似multihost的方式部署agent，但其实跟multihost还是有区别的。
首先，multihost模式中的nova-network是与计算节点绑定的，而agent不与计算节点绑定，只与network或router绑定。一个agent可以绑定多个network或router。
其次，multihost中一个nova-network挂了，只影响其所在计算节点的虚拟机网络；而某一个agent挂了，会影响它所绑定的network或router上的所有虚拟机
最后，multihost模式没有关于网络的调度；而agent是可以调度的，虽然现在只是简单的随机选取，但只要plugin有足够的信息（比如目前已经有：一个dhcpagent上有多少network，多少subnet，多少port这样的信息），可以完全支持很多负载的调度方式。

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