SDN开源框架:蝇量级选手Dragonflow究竟解决了什么问题
前言
SDN从2008年的openflow论文算起,发展到今天也算是门派众多,百花齐放。以重量级选手ODL,ONOS为代表的站在数据中心的高度对物理网络和虚拟网络进行云网一体化管理的,也有以DragonFlow,OVN为代表的蝇量级选手专注于数据中心虚拟网络管理的。今天的主角dragonflow采用分布式控制器架构,以流表的方式实现了neutron的dhcp、router、Security Group、namespace等,减小了计算资源的开销,缩短了数据包的转发路径,将数据包的转发从内核态抽离出来提高了转发效率。我们先来简单了解一下neutron的网络方案及存在的问题,再看下dragonflow是怎么解决的。
Neutron
以集中式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的解决方案。
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 流表实现了传统虚拟网元设备所做的事情。这么做带来的价值是什么,不尽之处还请多加指点:
1.链路缩短一定程度上提高了数据包的转发效率(毕竟不是内核层面的改变),
2.不再需要namespace、iptables节省host的计算资源开销
3.arp,dhcp本地控制器下发流表直接响应,减小广播对物理链路的负载
4.不需要网络节点,节省设备资源
说了那么多的优势和带来的价值,也谈一下个人的一些看法和疑虑吧,比如:dragonflow采用分布式控制器架构,那么各个控制器之间的数据同步在大规模情况下可靠性怎么样?全流表化的实现方式,在数据庞大的数据中心,网络问题该如何快速定位?同时,所有的网络功能实现都依托于ovs,那么ovs的稳定性能不能达到要求。另外还有个问题值得我们思考商榷,sdn在云数据中心领域实现云网一体化这已经是一个明显的趋势,在此基础上个人认为,下一步将是业务管理分发、运维的高度自动化,智能化,便捷化,这个问题上,dragonflow目前或者是掉队了或者是有别的思路,不同的声音同时存在总是好的,谁又能说的准呢。最后,一句话结束此文:路漫漫其修远兮!
原文发布时间为:2018-11-9
本文作者:dragonfly
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
前端:后端,我要分手
前戏 前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务(多种客户端,例如:浏览器,车载终端,安卓,IOS等等)打下坚实的基础。这个步骤是系统架构从猿进化成人的必经之路。核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。在互联网架构中,名词解释:Web服务器:一般指像nginx,apache这类的服务器,他们一般只能解析静态资源。应用服务器:一般指像tomcat,jetty,resin这类的服务器可以解析动态资源也可以解析静态资源,但解析静态资源的能力没有web服务器好。一般都是只有web服务器才能被外网访问,应用服务器只能内网访问。 术业有专攻 (开发人员分离) 以前的JavaWeb项目大多数都是java程序员又当爹又当妈,又搞前端,又搞后端。随着时代的发展,渐渐的许多大中小公司开始把前后端的界限分的越来越明确,前端工程师只管前端的事情,后端工程师只管后端的事情。正所谓术业有...
- 下一篇
阿里云护航中国邮政、茅台等企业度过双11多个业务高峰
2018年天猫双11上演了商业奇迹,最终成交额锁定在2135亿元,首次突破2000亿大关。除了成交额,2018年天猫双11还刷新多项纪录:物流订单于23点18分突破10亿;通过指纹和刷脸方式完成的支付占比达到60.3%。这背后,中国邮政、茅台、银泰、居然之家、猫晚、众安在线、天猫、淘宝、支付宝、盒马鲜生、饿了么、菜鸟、高德等众多企业在阿里云护航保障下,平稳度过了多个业务高峰。 (图为天猫双11开场8分钟,青岛一名消费者收到天猫直送快递员送上门的天猫超市包裹) 双11开场仅30分钟,全国多地消费者就收到了刚刚下单购买的商品。今年“分钟级配送”渐成新物流常态。其实表面上归属于其他快递公司包裹,背后有很多链路是依赖中国邮政。 (图为中国邮政分拣中心) 中国邮政在每个城市有足球场大小的分拣中心。双11期间,成千上万的包裹飞一般地鱼贯而过。包裹会被
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 2048小游戏-低调大师作品
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS关闭SELinux安全模块
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Red5直播服务器,属于Java语言的直播服务器
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Linux系统CentOS6、CentOS7手动修改IP地址