惠伟：openstack neutron基础(一)-基本概念zhuanlan.zhihu.com
惠伟：openstack neutron基础(二)-组件通信zhuanlan.zhihu.com
惠伟：openstack neutron基础(三)-serverzhuanlan.zhihu.com
BasicDesignTenets - OpenStack
代码语言：javascript复制1.Scalability and elasticity are our main goals
2.Any feature that limits our main goals must be optional
3.Everything should be asynchronous
a) If you can't do something asynchronously, see #2
4.All required components must be horizontally scalable
5.Always use shared nothing architecture (SN) or sharding
a) If you can't Share nothing/shard, see #2
6.Distribute everything
a) Especially logic. Move logic to where state naturally exists.
7.Accept eventual consistency and use it where it is appropriate.
8.Test everything.
a) We require tests with submitted code. (We will help you if you need it)为什么需要agent？Tenets里说的很清楚，要salability，elasticity，asynchronously, distribute和consistency，没有agent就达不到这些目的。ovs-agent和l3-agent是neutron的agent，nova-compute可以理解成是nova的agent。能不能把agent的工作都放在server，例如server远程通过openflows控制openvswitch，通过ovsdb协议控制ovs db server，nova远程连接libvirt然后创建和删除虚拟机。server压力太大，长时间阻塞，分布式系统各节点是无状态的，单点故障影响范围太大。server一般是高可用的，多server模式，并且可以随时添加server，server无法和节点保持长连接这样的硬绑定，假如server要和节点保持长连接，那server和节点对应关系怎么分配，一个server crash了影响就大了，它所绑定的节点都出问题了。如果绑定就不能scale了，也不elastic。假如就一个server，那么server crash然后重启了，server要和每一个节点同步信息，server给所有ovs同步流表，但有agent就简单了，不需要同步流表，agent只给server报告一下有变化的东西，或者从server请求一下server down期间的要的数据，是不是大大简化了工作量和数据传输。而且分布式系统，各个节点的角色不一样，各个节点的配置不一样，需要一个agent收集节点信息，通过agent的配置来区分角色。如nova-compute收集numa/cpu/memory等，监视本地虚拟机状态变化。ovs-agent收集一下本地有几块网卡，什么型号等。
总之需要agent，agent周期向server报告自己的状态，监控本地运行状况，保持和本地其它组件状态一致。
ovs agent
ovs负责二层转发，securitygroup和qos等落地的功能，虚拟机被nova调度到哪个节点，哪个节点上的ovs-agent就负责这个虚拟机的这些工作。ovs-agent有neutron-ovs-cleanup和neutron-openvswitch-agent两个进程，前者给后者后者打扫场地，打扫干净后都上场。ovs-agent是控制ovs的，真正转发由ovs进行，通过native或者ovs_ofctl进行控制，前者通过openflow协议，封装在os_ken中，来自于Ryu library，后者通过ovs自带的命令。两者入口稍有不同，但都殊途同归到ovs_neutron_agent.py中的OVSNeutronAgent，它init时创建基本的bridge和添加基本的flow，设置rpc。agent调用ovsdb-client monitor ovs db server数据的变化，一旦nova-compute给ovs bridge添加上port，它就立马感知到，通知ovs-neutron-agent处理。ovs-neutron-agent处理的主要流程就是rpc_loop，给port分配vlan，添加流表等，通知server port up。还有一个最后流程就是ovs-agent和ovs重启，或者和ovs db server断开连接，需要重刷流表，删除不要的老旧流表，有点类似于交换机上的graceful restart。
ovs-agent还支持l2 pop/arp responder/firewall，无非就是多了几个RPC callback，多继承了几个PluginApi，具体实现由配置的firewall_drivers等driver负责，ovs agent还有extensions支持qos和sfc等，调用self.ext_manager.handle_port就OK了，extension在handle_port里进行自己的处理逻辑，OVSAgentExtensionAPI用于extension获取agent的数据。
l3 agent
l3 agent负责三层转发，高级firewall等的落地，分很多种角色,dvr/snat/legacy/no_external等，相比ovs-agent根据虚拟机的调度来处理port，l3-agent需要neutron-server把router调度给它。主要有三个进程neutron-netns-cleanup，neutron-keepalived-state-change和neutron-l3-agent，neutron-netns-cleanup是打扫战场的，neutron-l3-agent是主力干活的，neutron-keepalived-state-change monitor keepalived主备的切换，然后通知l3-agent，用于router ha。l3主要的类L3NATAgent和RouterInfo以及各种各样的Router(DVR/HA/EDGE)的继承组合，还有一个就是NameSpace。l3-agent整体逻辑就是sync_router或者接收rpc消息，然后把router加入queue，再调度从queue中取出router然后处理。l3-agent也有自己的extensions，setup.cfg都有入口，和ovs-agent道理类似，只是它的manager调用extension的这些方法add_router，update_router，delete_router和ha_state_change，也有L3AgentExtensionAPI用于extension获取agent的数据。
总结
三层转发依赖于二层，只有router的gw port up了，并且ovs-agent把flow下好了包才能到namespace，neutron又是如何处理这种依赖关系的，看一下这两个函数就明白了update_all_ha_network_port_statuses和_notify_l3_agent_ha_port_update。如果把三层转发和NAT用openflow实现了，ovs agent和l3 agent就统一到了ovn，ovn用的是SDN思想，neutron-server加载SDN plugin，就不存在二三层这样的复杂依赖关系。
根据设计agent是需要的，agent是和底层实现密切结合，底层越强大越统一，agent就越简单，底层分散agent就干活杂多。所以说因为底层实现的问题，agent可以改进的地方很多，例如ovs-agent可以报告网卡信息，几个网卡通外网，带宽是否一致，外网QOS/HA，加载内核模块等方面能做更多。agent有extension和加载各种driver已经在努力干更多的活了，但受限于硬件不同，hypervisor不同和转发机制不同，还是出现了各种各样的agent，维护起来非常吃力。个人想法就是底层需要标准化，硬件信息收集标准化，计算和网络之间的接口标准化，网络信息下发标准化，需要一个行业标准组织来推动，这样就能减少agent的数量。
最最后
到此openstack neutron基础系列就算写完了，发现自己对neutron的理解也上了一个台阶，希望对大家也有用。纯文字，重在理解，有图的并不代表就是好文章，有思想的才是好文章。看起来很复杂的东西蕴含的道理都是很简单的，能用通俗的语言讲清楚，就像牛逼的物理或者数学公式一样，总是很简单，如果讲不清楚那一定是设计的不够完美，不是我不画图的原因。
