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

  • 时间:
  • 浏览:1
  • 来源:大发5分排列5_极速5分排列3

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





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

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



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南北流量和集中式是类似的。

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

在dragonflow的pipeline中实在什么都流量统一导入table0,table0最少一兩个流量分类器,将vm port、extenal port、tunnel port的流量进行分类,导入不同的功能table,table5避免port_security、table25避免arp请求、table100避免dhcp,table65 75 105 110 115同时完成东西流量的转发其中也包括安全组的避免等。关于dragonflow pipeline的删剪细节在此不做删剪说明,还要重点指出的是neutron和dragonflow在数据转发层面的网络模型是基本一致的,而dragonflow的本质什么都用ovs 流表实现了传统虚拟网元设备所做的事情。没法 做带来的价值是那先 ,不尽之处还请多加指点:

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

有些人儿先来简单了解一下neutron的网络方案及处在的问题报告 报告 ,再看下dragonflow是为什么我么我在么在避免的。

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

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

本文作者:dragonfly



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

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

前言

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

此图原链接:

Dragonflow的pipeline:

Neutron

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

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

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



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

Dragonflow

dragonflow在计算节点用流表实现snat、dnat,dhcp后,网络节点不再还要,有些人儿通过一张图对比一下neutron和dragonflow计算节点的网元图:

说了没法 多的优势和带来的价值,也谈一下自己的有些看法和疑虑吧,比如:dragonflow采用分布式控制器架构,没法 各个控制器之间的数据同步在大规模请况下可靠性为什么我么我在么在样?全流表化的实现土最好的办法,在数据庞大的数据中心,网络问题报告 报告 该怎样快速定位?同时,所有的网络功能实现都依托于ovs,没法 ovs的稳定性可不可不后能 达到要求。另外还有个问题报告 报告 值得有些人儿思考商榷,sdn在云数据中心领域实现云网一体化这有些是一兩个明显的趋势,在此基础上自己认为,下一步将是业务管理整理、运维的深度自动化,智能化,便捷化,某种 问题报告 报告 上,dragonflow目前有些是掉队了有些是有别的思路,不同的声音同时处在一直好的,谁又能说的准呢。最后,一句话如果开始此文:路漫漫其修远兮!

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

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