前言
SDN从2008年的openflow论文算起，发展到今天也算是门派众多，百花齐放。以重量级选手ODL，ONOS为代表的站在数据中心的高度对物理网络和虚拟网络进行云网一体化管理的，也有以DragonFlow，OVN为代表的蝇量级选手专注于数据中心虚拟网络管理的。今天的主角dragonflow采用分布式控制器架构，以流表的方式实现了neutron的dhcp、router、Security Group、namespace等，减小了计算资源的开销，缩短了数据包的转发路径，将数据包的转发从内核态抽离出来提高了转发效率。
![30f0e76baadac893cc309835c9ad0dd4882ea63a]()
我们先来简单了解一下neutron的网络方案及存在的问题，再看下dragonflow是怎么解决的。
Neutron
以集中式router下vxlan类型的子网为例
● vm跨子网通信场景：数据包的转发路径如图中浅蓝色虚线条所示，数据包需要经过tap设备、Linux Bridge、ovs Bridge等设备，同时所有的跨子网东西向流量都要经过网络节点的qrouter转发。
● 南北流量场景：数据包的转发路径如图中红色虚线条所示，数据包同样需要N多虚拟设备，然后通过网络节点qrouer做nat映射后达到外网。
集中式router网络模型存在的问题，经过的网元设备太多，数据包每经过一次Linux类型的网元设备都要重新走一遍Linux内核网络协议栈，降低转发效率，同时跨子网的东西向流量和南北流量都需要汇聚到网络节点进行转发，网络节点必然成为网络带宽的瓶颈。同时由于安全组规则只能应用于Linux设备，qvb显得多余而又不得不存在。网络节点的瓶颈问题业界有一种解决方案是将vlan类型私有网络的网关置于外部物理硬件设备上，舍弃neutron的三层功能，达到vlan直通的效果，来规避这种瓶颈，那网络虚拟化的意义又在哪呢。
![91a14fe3ea0d3d6395a93314f814769fe1d4aab7]()
以分布式router下vxlan类型子网为例：
东西向流量转发场景：下图中红色和蓝色虚线条分别是同子网跨主机和跨子网跨主机的数据包转发路径，相比集中式router跨子网的场景数据包无需经过网络节点的转发，而是在计算节点的qrouter直接进行转发。
南北向流量转发场景：下图中黑色和绿色虚线条分别是浮动IP和snat南北流量数据包转发路径，浮动IP的南北流量不再需要经过网络节点，直接在计算节点经过qrouter到达fip namespace做nat转发，最终到达外网。snat南北流量和集中式是类似的。
DVR一定程度上缓解了网络节点带宽瓶颈的问题，东西/南北流量的转发也得到了提升，但是数据包经过的虚拟网元设备依然很多，同时namespace占用大量的计算资源。另外两个广播流量大户dhcp和arp，dhcp已经可以通过L2poplation实现vm在本计算节点得到arp响应，但是dhcp数据依然需求到网络节点相对应的dhcp namespace中获取响应，对链路的负载依然会造成影响。ok，dvr解决了一些问题，但依然不是最优的解决方案。那我们再看下dragonflow的解决方案。
![53242ad5fb0adb7eb27b6e5888ca4001a26d60a9]()
Dragonflow
借用官方的一张图看一下dragonflow的架构：
![aa643734681255f9e4176a3be72b00d848461fa5]()
Dragonflow通过plugin和neutron对接，将Neutron DB模型转化为Dragonflow DB模型，本地控制器和Distribute DB同步网络拓扑和规则，SB DB Drivers和ovsdb交互，将配置编译成openflow流下发给ovs网元设备。其中L2、L3、dhcp app管理生成对应的流表给ovs网桥，实现与之对应的传统L2、L3、dhcp网络功能。需要指出的是，Dragonflow不需要原生neutron的namespace，iptables的nat以及除了dragonflow以外的任何代理进程。
dragonflow在计算节点用流表实现snat、dnat，dhcp后，网络节点不再需要，我们通过一张图对比一下neutron和dragonflow计算节点的网元图：
![0fdbc01123f9ddacf5caffb67db9f20ced2b37c5]()
通过上图可以清晰的看到，dragonflow将neutron冗长的链路变的简单，缩短后的链路减少了数据包经过Linux device内核协议栈的转发次数。那么谁来实现这些网元设备的功能呢，请看下图。
Dragonflow的pipeline：
![1c1b2eec51dd33d7e4faeb71b237eeca37621b02]()
此图原链接：
https://i.imgur.com/rMEoprK.png
在dragonflow的pipeline中其实就是流量统一导入table0，table0相当于一个流量分类器，将vm port、extenal port、tunnel port的流量进行分类，导入不同的功能table，table5处理port_security、table25处理arp请求、table30处理dhcp，table65 75 105 110 115共同完成东西流量的转发其中也包括安全组的处理等。关于dragonflow pipeline的详细细节在此不做详细说明，需要重点指出的是neutron和dragonflow在数据转发层面的网络模型是基本一致的，而dragonflow的本质就是用ovs 流表实现了传统虚拟网元设备所做的事情。这么做带来的价值是什么，不尽之处还请多加指点：
1.链路缩短一定程度上提高了数据包的转发效率（毕竟不是内核层面的改变），
2.不再需要namespace、iptables节省host的计算资源开销
3.arp，dhcp本地控制器下发流表直接响应，减小广播对物理链路的负载
4.不需要网络节点，节省设备资源
说了那么多的优势和带来的价值，也谈一下个人的一些看法和疑虑吧，比如：dragonflow采用分布式控制器架构，那么各个控制器之间的数据同步在大规模情况下可靠性怎么样？全流表化的实现方式，在数据庞大的数据中心，网络问题该如何快速定位？同时，所有的网络功能实现都依托于ovs，那么ovs的稳定性能不能达到要求。另外还有个问题值得我们思考商榷，sdn在云数据中心领域实现云网一体化这已经是一个明显的趋势，在此基础上个人认为，下一步将是业务管理分发、运维的高度自动化，智能化，便捷化，这个问题上，dragonflow目前或者是掉队了或者是有别的思路，不同的声音同时存在总是好的，谁又能说的准呢。最后，一句话结束此文：路漫漫其修远兮！
原文发布时间为：2018-11-9
本文作者：dragonfly
本文来自云栖社区合作伙伴“SDNLAB”，了解相关信息可以关注“SDNLAB”。
