SDN开源框架:蝇量级选手Dragonflow究竟解决了什么问题

  • 时间:
  • 浏览:0

dragonflow在计算节点用流表实现snat、dnat,dhcp后,网络节点不再需要,我门都都我门都都通过一张图对比一下neutron和dragonflow计算节点的网元图:

以分布式router下vxlan类型子网为例:

Dragonflow

本文作者:dragonfly

Dragonflow的pipeline:

我门都都我门都都先来简单了解一下neutron的网络方案及占据 的大大问题,再看下dragonflow是为啥么外理的。

东西向流量转发场景:下图中红色和蓝色虚线条分别是同子网跨主机和跨子网跨主机的数据包转发路径,相比集中式router跨子网的场景数据包不不经过网络节点的转发,后来在计算节点的qrouter直接进行转发。

以集中式router下vxlan类型的子网为例



在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 流表实现了传统虚拟网元设备所做的事情。越来越 做带来的价值是那些,不尽之处还请多加指点:





4.需要网络节点,节省设备资源

说了越来越 多的优势和带来的价值,也谈一下此人 的你你这一看法和疑虑吧,比如:dragonflow采用分布式控制器架构,越来越 各个控制器之间的数据同步在大规模状况下可靠性为啥么样?全流表化的实现办法,在数据庞大的数据中心,网络大大问题该怎样快速定位?同時 ,所有的网络功能实现都依托于ovs,越来越 ovs的稳定性还可不里能达到要求。另外还有个大大问题值得我门都都我门都都思考商榷,sdn在云数据中心领域实现云网一体化这可能是一一有有三个白明显的趋势,在此基础上此人 认为,下一步将是业务管理埋点、运维的层厚自动化,智能化,便捷化,你你你这一大大问题上,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以外的任何代理线程池池。



南北向流量转发场景:下图中黑色和绿色虚线条分别是浮动IP和snat南北流量数据包转发路径,浮动IP的南北流量不再需要经过网络节点,直接在计算节点经过qrouter到达fip namespace做nat转发,最终到达外网。snat南北流量和集中式是例如 的。

SDN从308年的openflow论文算起,发展到今天也否是门派众多,百花齐放。以重量级选手ODL,ONOS为代表的站在数据中心的层厚对物理网络和虚拟网络进行云网一体化管理的,都有以DragonFlow,OVN为代表的蝇量级选手专注于数据中心虚拟网络管理的。今天的主角dragonflow采用分布式控制器架构,以流表的办法实现了neutron的dhcp、router、Security Group、namespace等,减小了计算资源的开销,缩短了数据包的转发路径,将数据包的转发从内核态抽离出来提高了转发下行速率 。

前言



3.arp,dhcp本地控制器埋点流表直接响应,减小广播对物理链路的负载

1.链路缩短一定程度上提高了数据包的转发下行速率 (毕竟都有内核层面的改变),

 ●  南北流量场景:数据包的转发路径如图中红色虚线条所示,数据包同样需要N多虚拟设备,否则通过网络节点qrouer做nat映射后达到外网。

集中式router网络模型占据 的大大问题,经过的网元设备太满,数据包每经过一次Linux类型的网元设备都有重新走一遍Linux内核网络协议栈,降低转发下行速率 ,同時 跨子网的东西向流量和南北流量都需要汇聚到网络节点进行转发,网络节点必然成为网络下行速率 的瓶颈。同時 可能安全组规则必须应用于Linux设备,qvb显得多余而又不得不占据 。网络节点的瓶颈大大问题业界有有你这一外理方案是将vlan类型私有网络的网关置于实物物理硬件设备上,舍弃neutron的三层功能,达到vlan直通的效果,来规避你你你这一瓶颈,那网络虚拟化的意义又在哪呢。

2.不再需要namespace、iptables节省host的计算资源开销

本文来自云栖社区媒体合作伙伴“SDNLAB”,了解相关信息还可不里能关注“SDNLAB”。

DVR一定程度上缓解了网络节点下行速率 瓶颈的大大问题,东西/南北流量的转发也得到了提升,否则数据包经过的虚拟网元设备依然后来,同時 namespace占用血块的计算资源。另外一有有三个白广播流量大户dhcp和arp,dhcp可还可不里里能通过L2poplation实现vm在本计算节点得到arp响应,否则dhcp数据依然需求到网络节点相对应的dhcp namespace中获取响应,对链路的负载依然会造成影响。ok,dvr外理了你你这一大大问题,但依然都有最优的外理方案。另一一有有三个白们再看下dragonflow的外理方案。

通过上图还可不里能清晰的想看 ,dragonflow将neutron冗长的链路变的简单,缩短后的链路减少了数据包经过Linux device内核协议栈的转发次数。越来越 谁来实现那些网元设备的功能呢,请看下图。

原文发布时间为:2018-11-9

借用官方的一张图看一下dragonflow的架构:

Neutron

https://i.imgur.com/rMEoprK.png