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 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目前处于一个很尴尬的地位。从技术角度来看,理由有如下两点:

l、DragonFlow设计之初是主要为了解决DVR给各个计算节点带来的开销问题,但是经过架构的演化之后,Controller却同样被分布到了各个计算节点中。确实,把三层的路由放到了数据平面去做而不再经过内核,是一个性能上的提升,但是即使再轻量级的控制器的开销也不可完全忽视,何况跑着那么复杂的数据库。OVN的DB开销可能要好一些,不过这只是因为它目前只支持用OVSDB做数据库。

2、如果把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的生态圈可是早就已经打造起来了,另起炉灶人家能愿意吗。

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2016-04-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微信公众号:Java团长

Java就业指导

想要成为合格的Java程序员或工程师到底需要具备哪些专业技能,面试者在面试之前到底需要准备哪些东西呢?本文陈列的这些内容既可以作为个人简历中的内容,也可以作为面...

1882
来自专栏SDNLAB

SDNLAB技术分享(七):开源SDN控制器DCFabric及云计算高效网络

1.DCFabric控制器的由来 1.1 SDN是云计算数据中心网络技术发展的必然要求 随着以虚拟化为基础的云数据中心的发展和成熟, 应用数据猛增,虚拟服...

3856
来自专栏高性能服务器开发

libevent源码深度剖析一 序

(1)libevent源码深度剖析一 序 (2)libevent源码深度剖析二 Reactor模式 (3)libevent源码深度剖析三 libevent基本使...

4063
来自专栏ATYUN订阅号

像素墨镜,大烟卷—Thug Life风格自动生成项目

AiTechYun 编辑:nanan ? 暴徒生活(Thug Life)是一款非常火热的P图特效,通过加上此特效会让用户的视频或者照片变的非常有趣好玩。其拥有大...

3905
来自专栏杨熹的专栏

面试官怎么看你的Github profile

Udacity的Machine Learning纳米学位课程中,关于Github的笔记。 听课范围: Github Profile Git 和 Github...

3508
来自专栏杨建荣的学习笔记

通过addm分析io问题(r2笔记64天)

昨晚在做测试环境数据迁移的时候,遇到了io的问题,本来预计2,3个小时完成的数据导入工作最后竟然耗了7个多小时。在数据的导入中,使用了10个并行的sessio...

2696
来自专栏Youngxj

iPhone7手机信号显示成数字如何设置?

5934
来自专栏Java架构

跳槽必看!一位程序猿面试蚂蚁金服后端的经验总结!前言自我介绍最近的项目经历总结

3085
来自专栏Java后端技术栈

为什么要有Spring?

我们学习技术的时代赶上了最好的时代,跳过了很多前人经常踩的坑,前人在踩坑的过程中总结了很多经验和教训,而新时代的我们只是继承了前人的经验和教训,而忽略了这些采坑...

1213
来自专栏Java社区

【五一福利】Java程序员编程学习之路资源合集

2493

扫码关注云+社区

领取腾讯云代金券