1. Dragonflow项目诞生背景
DragonFlow是华为以色列技术团队2014年提出的，2015年开始提交代码，目前已经成为OpenStack的孵化项目。DragonFlow最初的目标是通过可插拔、无状态、轻量级的SDN控制器来实现分布式路由，它的提出是为了解决DVR（Distributed Virtual Router，分布式虚拟路由技术）中存在的一些问题，主要是DVR会造成计算节点上资源和性能的一些损耗。
但在OpenStack Liberty版本开始，可能是受OVN项目的影响，Dragonflow转向全面的SDN项目，与OVN不同的是，Dragonflow目的是提供全功能的SDN解决方案。一直到刚刚结束的Ocata版本，Dragonflow社区一直处于活跃的开发和正向的演进中。
1.1 Neutron DVR网络方案问题
以集中式router下vxlan类型的子网为例：
- vm跨子网通信场景：数据包的转发路径如图中浅蓝色虚线条所示，数据包需要经过tap设备、Linux Bridge、ovs Bridge等设备，同时所有的跨子网东西向流量都要经过网络节点的qrouter转发。
- 南北流量场景：数据包的转发路径如图中红色虚线条所示，数据包同样需要N多虚拟设备，然后通过网络节点qrouer做nat映射后达到外网。
集中式router网络模型存在的问题，经过的网元设备太多，数据包每经过一次Linux类型的网元设备都要重新走一遍Linux内核网络协议栈，降低转发效率，同时跨子网的东西向流量和南北流量都需要汇聚到网络节点进行转发，网络节点必然成为网络带宽的瓶颈。同时由于安全组规则只能应用于Linux设备，qvb显得多余而又不得不存在。网络节点的瓶颈问题业界有一种解决方案是将vlan类型私有网络的网关置于外部物理硬件设备上，舍弃neutron的三层功能，达到vlan直通的效果，来规避这种瓶颈，那网络虚拟化的意义又在哪呢。
以分布式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的解决方案。
1.2 Dragonflow的解决思路
借用官方的一张图看一下dragonflow的架构：
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计算节点的网元图：
通过上图可以清晰的看到，dragonflow将neutron冗长的链路变的简单，缩短后的链路减少了数据包经过Linux device内核协议栈的转发次数。那么谁来实现这些网元设备的功能呢，请看下图Dragonflow的pipeline：
此图原链接：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 流表实现了传统虚拟网元设备所做的事情。这么做带来的价值是：
- 链路缩短一定程度上提高了数据包的转发效率（毕竟不是内核层面的改变），
- 不再需要namespace、iptables节省host的计算资源开销
- arp，dhcp本地控制器下发流表直接响应，减小广播对物理链路的负载
- 不需要网络节点，节省设备资源
2 Dragonflow架构
2.1 架构演进
早期，DragonFlow的设计架构以及控制流如下所示（OpenvSwitch OVN子项目提前看（by quqi99)_quqi99的博客-CSDN博客）。可以看到早期的DragonFlow需要在Neutron中新增3个东西，L3 Controller Plugin加在neutron-server中接收L3 Extension API，然后将路由信息同步给网络节点上的L3 Controller Agent。L3 Controller Agent根据全局信息向计算节点中的br-int发送路由流表，以及SNAT/DNAT流表。DragonFlow中ARP是分布在计算节点实现的，DHCP仍然放在了网络节点实现。
其实，早期的DragonFlow就是通过在网络节点引入OpenFlow控制器（RYU），通过下发流表在数据平面直接完成路由。这与ONOS、ODL等SDN控制器对Openstack中L3的实现本质上是一样的，只不过大家有的人仍然倾向于把L3流量导向网络节点的OVS而已，这样的话trouble shooting会比较容易一点。
2.2 当前架构
而目前，DragonFlow已经不再局限于L3的实现，整体架构上也有了很大的变化，如下所示。可以看到DragonFlow功能上已经集成了对L3 Extension API以及L2 Core API的支持，架构也由早期网络节点上的单Controller变为了计算节点上分布式的Controller。Controller通过本地的SB DB Driver操作OVS，通过本地的NB DB Driver与Distributed DB交互业务数据。Distributed DB是可插拔的数据库框架，一些Plugable DB能够支持分布式集群。
当前的定位是大规模环境下高性能SDN解决方案，其架构如下：
其组成部分主要有Neutron plugin，Message Driver，DB driver，Dragonflow controller。分别来看看这些组成部分：
2.1 Neutron plugin
由于Dragonflow就是OpenStack Neutron下面的的子项目，因此Dragonflow自己完成了与Neutron的集成，Neutron plugin就是Dragonflow中与Neutron的集成部分，这个与其他的SDN一样，实现了ML2 mech driver和各种Service plugins。与OVN类似的是，目前Dragonflow本身不提供独立的RESTful接口，Neutron plugin直接写Dragonflow Database，并触发相应的Message。
2.2 Message Driver
Dragonflow组件间通讯的方式，其他的SDN一般是定义好了组件间通讯的方式，要么是RPC，要么是其他协议，而Dragonflow将这部分做了一个抽象，可以支持多种Message机制，目前支持的有ZeroMQ和ReidsMQ。这样用户可以根据不同的使用场景，选用不同的Message机制。Message Driver用来连接Dragonflow Controller和Neutron server，并在之间传递数据。
2.3 DB driver
与Message driver类似，其他的SDN一般只支持一种DB，但是Dragonflow将这部分也做了抽象，可以支持多种NoSQL数据库，目前支持的有etcd，RAMCoud，Reids，Cassandra等。这样实现的目的也是为了用户可以根据不同的使用场景，选用不同的DB，以达到最好的性能效果。
2.4 Dragonflow Controller
这个是Dragonflow的核心部分。
所有的Dragonflow controller都监听Message driver，当Neutron plugin发布相应的Message，Dragonflow Controller能收到这个消息，并进行相应的计算，更新相应的OpenFlow规则和本地的配置，同时Dragonflow会通过Message driver上报本地的信息，例如端口上线事件。
刚刚结束的Dragonflow Northbound DB重构，将Dragonflow Controller中的数据和消息机制，按照Model来管理，这有点类似于ODL中的MD-SAL。
为了提高网络计算的速度，Dragonflow本地有一个数据的缓存，这样在进行网络计算的时候，直接可以从内存中读取数据进行运算，而不需要再读取远端DB数据。这样能减少网络计算的时间，降低网络延时。
2.5 selective topology
为了适应大规模部署，Dragonflow中还有一个selective topology的概念，这个有点类似OpenContrail里的的vRouter中的routing instance概念。
只有当前计算节点关注的Topology才会在当前Dragonflow Controller中存在缓存，并且相应消息才会被当前Dragonflow Controller接收。当前计算节点关注的Topology是指当前计算节点上相应租户（tenant）的虚拟机。这样的设计，使得在大规模部署环境下，每个Dragonflow Controller的只需要监听有限的信息，缓存有限的数据，不会因为规模的变大而导致单个Dragonflow Controller负荷变大。
2.6 Networking Abstraction Layer
这里是具体网络功能的实现，因为Dragonflow Controller是运行在各个计算节点的，因此，Dragonflow对于网络的运算，也是放到各个计算节点，这是一个真正的分布式可插拔的SDN方案。之前介绍的SDN要么是集中式的SDN，要么是部分运算在集中式节点，部分计算在分布式节点。
在NAL，每个网络功能都是一个独立的application。为了实现相应的网络功能，每个计算节点上都必须运行一套applications。目前实现的网络功能有DHCP，L3 routing，L2，Security Group，等等。
与ovn-controller类似的是，Dragonflow Controller底层连接的也是ovs-vswitchd和ovsdb-server。
2.7 部署框架
与OVN类似的是，Dragonflow也有一个专门的Database node，但是与OVN不一样的是Dragonflow的Database Node可以是任何DB backend，例如实际环境下可以部署一个Redis DB的HA集群，这在大规模环境下优势要明显强于OVN的ovsdb-server。另一方面不一样的是，Dragonflow的Database node不关心任何网络运算，所有的网络运算都交由分布在计算节点的Dragonflow controller完成。
3 流水线设计
目前版本的DragonFlow，设计了如下的OpenFlow流水线，其中浅灰色的是完全Proactive的，而天蓝色的是部分Reactive的。
Table 0是Ingress Classfication && Dispatch to Ports流表。它将本地VM产生的流量标记好租户ID，然后送入Ingress Port Security流表（主要完成对源ARP、IP的监测，防止VM伪造身份）；将由隧道传入流量发给目的VM；将Floating IP的南北向流量送入Ingress Processing流表（主要完成NAT和FloatingIP的ARP代答）。
通过Ingress Port Security流表的检查后，送入Service流表，它的作用是过滤出ARP和DHCP信令进行特殊处理，其余流量则送入L2 Lookup流表。ARP Request被送入ARP Table，ARP Table的设计采用了proactive模式，控制器事先预置好ARP Reply的流表项，在数据平面本地直接实现ARP代答；DHCP消息被送入DHCP Table，DHCP Table的设计采用了reactive模式，由控制器完成DHCP代答。
L2 Lookup流表处理L2流量。它根据目的MAC地址判断是否为L3流量，如果是则送入L3 Lookup Table；否则判断是否为L2的广播/组播，是则标记租户的网络ID，然后送入Egress Security流表；如果是L2单播，则标记目的虚拟机的ID，然后送入Egress Security流表。L3 Lookup流表处理L3流量。它根据目的子网判断流量是否为东西向流量，如果是则将首包送给控制器，控制器下发精确匹配目的的IP的流表，完成路由，然后送给Egress Security流表进行ACL处理。如果是是南北向流量则送入Egress Processing流表进行处理。Egress Processing流表判断源虚拟机是否申请了Floating IP，是则将其源IP、MAC地址转换为Floating IP、MAC地址并直接从相应端口送出完成转发，否则进行PNAT送入Egress Security流表进行ACL处理。Egress Security流表处理后，将合法流量送入Egress流表。Egress流表将本地流量直接转发，到远程节点的流量通过相应的隧道端口送出。
4 总述
Dragonflow是一个真正的分布式SDN解决方案，其底层依赖OVS。因此对于现有的Neutron OVS架构，迁移到Dragonflow也较为自然，实际上，Dragonflow目前也有相应的努力，提供Neutron OVS agent迁移到Dragonflow的方案（开发中）。
从社区开发来看，华为是目前的主要贡献者，不过从其目前的开源策略看，Dragonflow并没有想做成一个厂商控制的开源项目。
另一方面，Dragonflow现在还处于一个相对早期的阶段。并且分布式的SDN方案，虽然将网络运算分布到了各个计算节点，能够从理论上去除瓶颈，扩大集群规模，但是也增加了开发的难度和浪费了集群内整体的计算资源，因为同一个网络运算，需要在多个计算节点分别完成，从整体上看是有一定的浪费。
不过鉴于目前计算资源成本较低，这些副作用利大于弊，总体来说，Dragonflow还是一个很有前途的SDN项目。
DragonFlow目前已经支持的特性，号称有如下几点:
✔ 支持L2 Core API，支持IPv4、IPv6，支持GRE/VxLAN/Geneve隧道封装
✔ 分布式虚拟路由，支持proactive和reactive的混合模式
✔ 分布式DHCP
✔ 可插拔的分布式数据库
DragonFlow未来的roadmap如下所示：
✔ 对容器网络的支持
✔ 分布式SNAT/DNAT
✔ Reactive DB
✔ 服务链，外部应用流表注入
✔ 支持硬件NIC
✔ 在SDN TOR上实现Port Binding
✔ Inter Cloud Connectivity (Boarder Gateway / L2GW)（这个目前还不能够很好的理解）
✔ 错误检测
参考链接
SDN开源框架：蝇量级选手Dragonflow究竟解决了什么问题 | SDNLAB | 专注网络创新技术
OpenStack中SDN泛谈3 (OVN&Dragonflow) - 知乎
OpenStack中SDN泛谈4 (SDN发展与架构) - 简书
DragonFlow与OVN - 腾讯云开发者社区-腾讯云
Dragonflow的架构、功能及未来发展路线图详解 | SDNLAB | 专注网络创新技术
DragonFlow导读(by quqi99)_quqi99的博客-CSDN博客
