DragonFlow与OVN

DragonFlow和OVN是比较前沿的Neutron子项目了,这一节我们就来看看Neutron的这两个后起之秀。

======================= DragonFlow ========================

(一)架构演变

DragonFlow是华为以色列技术团队2014年提出的,2015年开始提交代码,目前已经成为OpenStack的孵化项目。DragonFlow最初的目标是通过可插拔、无状态、轻量级的SDN控制器来实现分布式路由,它的提出是为了解决DVR中存在的一些问题,主要是DVR会造成计算节点上资源和性能的一些损耗。

早期,DragonFlow的设计架构以及控制流如下所示(http://blog.csdn.net/quqi99/article/details/42773417)。可以看到早期的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会比较容易一点。

而目前,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能够支持分布式集群。

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)(这个目前还不能够很好的理解)
  • 错误检测

(二)流水线设计

目前版本的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流表将本地流量直接转发,到远程节点的流量通过相应的隧道端口送出。

=========================== OVN ===========================

(一)架构

OVN(Open Virtual Network)是OVS项目组孵化的,项目组对OVN原汁原味的定位如下所示。一言以蔽之,就是更好地对OVS的pipeline进行规划以适应虚拟化的需求。

下图是OVN的整体框架,可以看到和DragonFlow是比较像的,都是把Controller放在计算节点或者网络节点上,向下指挥本地的pipeline,向上接受全局数据库的统一指挥。相比于DragonFlow的DB设计,由于OVN目前只支持OVSDB,所以暂时还没有分布式集群。OVN的DB本身又细分为了Northbound DB和Southbound DB,两者之间是通过守护进程OVN-Northd来联系起来的。Northbound DB收集业务数据,而Southbound DB收集底层网络的实时数据,这和ODL MD-SAL中DB的设计是类似的,尽管OVN中的Northbound DB和Southbound DB目前好像是用一个ovsdb-server实例实现的。

具体点说,Northbound DB负责把Neutron中的数据结构(如network、subnet、port、securitygroup等等)转换为OVN的数据结构(如logical switches、logical ports、ACL等等)
OVN的,OVN-Northd根据OVN的数据结构产生logical flows(租户网络视图中的转发逻辑,与底层OVS中的流表不同)存入Southbound DB。Southbound DB再把logical flows和port bindings(VIF的信息,如MAC地址,接入位置等)同步给各个Local OVN Controller。最后Local OVN Controller将logical flows映射为physical flows,通过OpenFlow+OVSDB部署本地的OVS。可以参照下面的实例理解上一段的内容。


OVN希望支持的特性如下,目前控制平面上logical switch、logical router、ACL基本上已经实现了,数据平面上随着OVS 2.5.0的发布也有了很大的进展。

控制平面 数据平面
  • Logical switch/logical router
  • Security Group
  • L2/L3/L3 ACL
  • Logical L3 GW/TOR-based L3 GW
  • Multiple Tunnels(VxLAN、STT、Geneve)
  • KVM/Xen
  • Container
  • DPDK
  • Hyper-V

(二)流水线

由于logical device和logical flow的存在,OVN的流水线设计是比较有意思的。什么是logical device呢?看了下图应该就能够明白了,老外画图的功夫还真是了得。

总之logical device就是通过ovs-bridge虚拟出来的东西,一个ovs-bridge在OVN中可以虚拟出来多个logical switch和logical router,OVN还可以虚拟出来这些设备间的连接。Logical flows就是这些logical device上的流表,OVN-Northd将Neutron的业务逻辑转化为logical flows下发给Local Controller,Local Controller再将logical flows转化为实际OVS pipeline中的physical flows。

这里插一句,听起来logical flows到physical flows做映射,好像在Neutron里是比较新鲜的,不过这对于SDN控制器来说其实都是老套路了——Nicira早在NVP里就这么干了,OVN说穿了只不过是OVS项目组把两三年前自己搞的商用产品的原型,开放出来整合进了Neutron而已。

继续。我们用一个实际的例子来进行理解,下图中的两个logical switch和1个logical router都是OVN用一个OVS-bridge虚出来的。端口方面,Tap 24和Tap25外接两个网段的虚拟机VM1、VM2,Patch19/20和Patch22/25是两对ovs patch-peer,另外还有port 21/22作为两个网段dhcp namespace的连接端口。从不同logical device进来数据包会被标记为不同的metadata(例如从Tap 24和Patch 19端口进入的数据包,可能被标记metadata=1,从Patch 20、Patch 23端口进入的数据包,可能被标记metadata=2,从Patch 22和Tap 25端口进入的数据包,可能被标记metadata=1),根据metadata的不同会决定后续是交给L2 流表处理还是L3流表来处理。L2 流表的处理主要就是根据目的MAC进行本地转发(可能是Tap也可能是Patch)或者送入隧道,L3流表的处理主要就是根据目的IP进行路由改MAC地址,并减TTL。

上述只是流水线的主体逻辑,实际上OVN具体的pipeline设计与DragonFlow并没有大的区别。对比DragonFlow的pipeline,目前OVN设计中还是有一些小区别的,比如DHCP仍然是由namespace实现而不是通过Controller来回复,L3的表项都是Proactive的,还没有实现NAT,增加了一些新的动作(如ICMP Reply)等等。

======================== 个人随想 ========================

虽然DragonFlow和OVN都把自己的控制叫做Controller,不过实际上都只是OVS-Neutron-Agent的翻版,并没有脱离Neutron的老思路——业务数据库作为super controller,指挥本地的Local Controller调配流水线,分布式和HA由数据库层面来实现。

但实际上个人认为,恰恰是这样的演化使得DragonFlow和OVN目前处于一个很尴尬的地位。从技术角度来看,理由有如下两点:
DragonFlow设计之初是主要为了解决DVR给各个计算节点带来的开销问题,但是经过架构的演化之后,Controller却同样被分布到了各个计算节点中。确实,把三层的路由放到了数据平面去做而不再经过内核,是一个性能上的提升,但是即使再轻量级的控制器的开销也不可完全忽视,何况跑着那么复杂的数据库。OVN的DB开销可能要好一些,不过这只是因为它目前只支持用OVSDB做数据库。
如果把DragonFlow/OVN看做面向云的SDN控制器的话,其实它在功能上相比于ODL、ONOS这些开源SDN控制器并无特别优势。而且如果是完全自顶向下的业务触发式设计,其实浪费了南向协议的很多天赋,现在大家拼云的业务能力时可能看不出来,以后开始拼云网络中的运维就能看出差距了。

因此,相比于ODL和ONOS这类SDN科班出身的产品,从技术演进角度个人并不看好DragonFlow和OVN。实际上,DragonFlow和OVN似乎也没有要与ODL、ONOS相抗衡的打算,倒是DragonFlow和OVN彼此一直在叫着劲儿。

如果要比较DragonFlow和OVN的话,个人比较看好OVN。其实技术上大家的思路都差不多,只是时间点有区别而已。倒是从非技术角度来看,个人认为OVN的优势要大一些,毕竟是OVS项目组亲自孵化的,身份上要正统一些。另外OVN从最开始就对接了ML2,但是DragonFlow现在还是独立的Plugin,觉悟上似乎OVN也是更胜一筹。ML2的生态圈可是早就已经打造起来了,另起炉灶人家能愿意吗。

作者简介:
张晨,2014/09-至今,北京邮电大学信息与通信工程学院未来网络理论与应用实验室(FNL实验室)攻读硕士研究生。主要研究方向:SDN、虚拟化、数据中心
个人博客:sdnv.xyz
个人邮箱:zhangchen9211@126.com


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/16573.html
分享到:
相关文章
条评论

登录后才可以评论

张晨 发表于16-04-18
5