当前位置:数据网络行业动态 → 正文

网络研究人士:OpenFlow控制器的设计正在杀死SDN

责任编辑:editor005 |来源:企业网D1Net  2016-08-30 16:05:26 本文摘自:SDNLAB

OpenFlow的架构是低效的,且限制了性能的改善,甚至还会造成不必要的功率损耗。

这是一串对比出来的结论,是来自澳大利亚brain box Data61和悉尼大学(Sydney University)的科研人员研究的结果,他们评估了四个主要的OpenFlow控制器NOX、Maestro、Floodlight、Beacon。论文发表在Arxiv平台。

旧版本的OpenDaylight也进行了测试,但是并没有形成任何报告:“旧版本的OpenDaylight性能太低,不能提供任何有见地的比较。”

参与测试的控制器没有一个能够接近线速,无论是在网络处理器上运行(基于Tilera芯片),或基于Xeon E5-2450服务器(后期将在更高版本上测试)。

就CBench SDN控制器性能指标而言,最佳Tilera设置仅仅勉强达到了每秒500万个请求,与每秒2900万请求的最高线速比不相去甚远。

由此可见Intel长期以来在数据包处理方面的工作卓有成效:在x86的设置下,Beacon能达到每秒2000万请求;其他控制器最大值是每秒700万请求。

Line rate? Forget it: the CSIRO/Data61/Sydney Uni benchmark results

由于SDN控制器必须处理流量,这意味着他们必须记住MAC地址以便跟踪通信,跟以太网交换机只需要知道转发流量到哪个端口相比,其网络的可扩展性也是一个大问题。

在性能指标里,没有控制器能处理接近峰值的1000万唯一MAC地址,基于Java语言的控制器(Beacon和Floodlight)在这方面的几乎没有创新。

该论文指出的问题是,OpenFlow本身的架构效率极其低下。作者提到了序列化:I/O现成;学习交换机应用的关键数据结构:哈希表。

序列化是迄今为止最大的支出:即使是最有效的控制器在处理数据包的序列化问题上也要花费总时间的五分之一,这个限制是面向对象的控制器设计原则固定的。他们都将每个单独的数据包作为一个独立的对象,这导致了每个数据包的开销变得不可负担。

作者的建议是谋求一个新的SDN控制器的设计方式,他们写道:“将新到达的数据包设置预分配的缓冲区进行处理,而不是作为新的对象来处理。”控制器应该“在多核平台中硬件特性的限制,或利用多核平台的网络级芯片。”

原文链接:http://www.theregister.co.uk/2016/08/22/sdncontrollerdesignsucksclaimnetworkboffins/

关键字:SDNOpenFlow

本文摘自:SDNLAB

x 网络研究人士:OpenFlow控制器的设计正在杀死SDN 扫一扫
分享本文到朋友圈
当前位置:数据网络行业动态 → 正文

网络研究人士:OpenFlow控制器的设计正在杀死SDN

责任编辑:editor005 |来源:企业网D1Net  2016-08-30 16:05:26 本文摘自:SDNLAB

OpenFlow的架构是低效的,且限制了性能的改善,甚至还会造成不必要的功率损耗。

这是一串对比出来的结论,是来自澳大利亚brain box Data61和悉尼大学(Sydney University)的科研人员研究的结果,他们评估了四个主要的OpenFlow控制器NOX、Maestro、Floodlight、Beacon。论文发表在Arxiv平台。

旧版本的OpenDaylight也进行了测试,但是并没有形成任何报告:“旧版本的OpenDaylight性能太低,不能提供任何有见地的比较。”

参与测试的控制器没有一个能够接近线速,无论是在网络处理器上运行(基于Tilera芯片),或基于Xeon E5-2450服务器(后期将在更高版本上测试)。

就CBench SDN控制器性能指标而言,最佳Tilera设置仅仅勉强达到了每秒500万个请求,与每秒2900万请求的最高线速比不相去甚远。

由此可见Intel长期以来在数据包处理方面的工作卓有成效:在x86的设置下,Beacon能达到每秒2000万请求;其他控制器最大值是每秒700万请求。

Line rate? Forget it: the CSIRO/Data61/Sydney Uni benchmark results

由于SDN控制器必须处理流量,这意味着他们必须记住MAC地址以便跟踪通信,跟以太网交换机只需要知道转发流量到哪个端口相比,其网络的可扩展性也是一个大问题。

在性能指标里,没有控制器能处理接近峰值的1000万唯一MAC地址,基于Java语言的控制器(Beacon和Floodlight)在这方面的几乎没有创新。

该论文指出的问题是,OpenFlow本身的架构效率极其低下。作者提到了序列化:I/O现成;学习交换机应用的关键数据结构:哈希表。

序列化是迄今为止最大的支出:即使是最有效的控制器在处理数据包的序列化问题上也要花费总时间的五分之一,这个限制是面向对象的控制器设计原则固定的。他们都将每个单独的数据包作为一个独立的对象,这导致了每个数据包的开销变得不可负担。

作者的建议是谋求一个新的SDN控制器的设计方式,他们写道:“将新到达的数据包设置预分配的缓冲区进行处理,而不是作为新的对象来处理。”控制器应该“在多核平台中硬件特性的限制,或利用多核平台的网络级芯片。”

原文链接:http://www.theregister.co.uk/2016/08/22/sdncontrollerdesignsucksclaimnetworkboffins/

关键字:SDNOpenFlow

本文摘自:SDNLAB

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^