ONF测试工作张攀:OpenFlow控制器性能测试工具进展

  1. 云栖社区>
  2. 博客>
  3. 正文

ONF测试工作张攀:OpenFlow控制器性能测试工具进展

行者武松 2017-09-02 14:26:00 浏览1216
展开阅读全文

2016年6月2日,“2016全球SDNFV技术大会”进入了第二天。作为连续举办三届的SDN/NFV技术与产业盛会,本届大会着眼于SDN /NFV的实践应用与部署,从SDN/NFV在运营商网络、企业网、云数据中心、测试解决方案等多个场景的应用出发,深入解析产业部署现状及面临的挑战与发展趋势。

张攀

ONF测试工作组副主席 全球SDN测试认证中心高级工程师 张攀

在下午进行的大会中,客串主持人的,ONF测试工作组副主席,全球SDN测试认证中心高级工程师张攀也做了主题演讲。 张攀介绍到,作为第三方的测试认证实验室,ONF的测试囊括了SDN和NFV,但在本次大会上,ONF希望同与会嘉宾分享关于ONF控制器测试,分享自身的经验和想法,供大家交流指导。

ONF在不断的实践中发现,Cbench这款工具还是存在一些问题。其一,他的测试方法没有被标准化,同时,如果测试不在现实的场景中实施的话,就没有实际的意义。第二,他针对各个测试要求没有一个定制化的处理,他基本上是一个写死的软件,他既没有模块化的一些支持,也没有一些API的支持。另外Cbench架构基本上没有考虑软件架构设计这方面的东西。最后ONF甚至发现它的测试结果是不正确的。那么ONF的测试是如何避免出现这些问题,并进一步提升测试水平的呢?张攀为与会嘉宾做了详细的介绍。

以下为演讲实录:(以下内容根据现场速记整理,未经发言嘉宾确认,仅供参考,谢绝转载。)

张攀:下面由我本人来给大家介绍一下最新的关于SDN控制器的一个测试工具的进展。当然了,除了我除了客串主持人之外,同时也是全球SDN测试认证中心高级工程师。这次我是希望作为第三方的测试认证实验室,虽然我们也测SDN,也测NFV,但是我们还是希望在这次大会上,能够聚焦一下,聚焦到我们现在的关于控制器测试上面来,也让我们的讨论能够更有深度,同时也可以把我们的经验和我们的一些想法分享给大家,供大家批评。

大家看到这个题目可能会猜到我可能需要什么东西,你觉得我可能介绍新的测试技术,这个肯定我会介绍这些,同时你可能会觉得我会介绍新的测试规范,或者说测试标准在这方面的进展,没错,这方面,我也会介绍,您可能还会觉得我会介绍新的测试软件或者说一个新的测试工具,对,这个也是我要介绍的一个重点,但是我想说的是在这次分享里边,它都只是这次分享内容的一部分,并且我们是有一条主线来贯穿整个分享的,这条主线就是我们的开源软件。这里边我们会有一个在所有介绍开始之前会有一个关于开源软件的想法和思考。

我们现在就简单的来开始这方面的内容,那么大家都知道,如果您做控制器性能测试的话您肯定知道Cbench也是业界使用最广泛的的开源软件,我几乎所有见到的,用我们工具之前的所有测试报告都会提到这个Cbench。这个也是非常热的话题,所以我们最初想法能够基于Cbench可以做一款测试工具,这样的话既减少我们的开发的成本,但是也可以发挥价值。但是我们真正开始深入Cbench这款工具之后我们还是发现它存在一些问题。

第一个他的测试方法没有被标准化,这里并不是说你的测试方法一定要写入到某一个标准组织的规范里面去,并不是说这个意思,而是说你的测试方法并没有在现实的场景中,并没有实际的意义。现实场景中并不可能出现你模拟的测试方法,这个是我提到的第一个问题,当然也有些人说,既然有一个方法也可以测出一些结果,你可以先用这个先开始做,没问题,我们看第二点,我们打算基于这个方面来做,但是我们发现,它还是缺失很多特性,很多必须的特性。比如说你需要对它的包的长度做出调整,或者你对他包的内容做出修改或者说你需要规定一个,他上送的速率,这些东西他都没有,他基本上是一个写死的软件,他既没有模块化的一些支持,也没有一些API的支持。所以这让我们基本上属于一个束手无策的状态,对我们来说与其基于它开发,还不如我们自己写一个,这是我们发现的第二点问题。

也许有人会说,本来就是开源软件,你也不用花钱,当然也不会有人提供技术支持和服务,我们即便想对这款开源软件做出一些改造,我们深入它的架构之后,我们只能说它的架构基本上没有考虑软件架构设计这方面的东西,他的东西基本上都是写死,并没有更多的模块,没有可移植这方面的特性,所有的东西基本上就是一行按顺序执行的代码,没有任何灵活性或者可拓展性这方面的考虑,这个是我们发现的第三个问题。

第四个问题我们甚至发现它的测试结果是不正确的。当然这个不正确是加了引号,具体是什么原因我在这里就解释给大家。这个是我截取的Cbench的一部分代码,这方面的话,不管你懂不懂C语言,我都给大家做一个比较简单的解释,现在是这样,这部分的代码的意思是说,是Cbench接收消息包的一部分模块的内容,他的意思是说,所有packet out这部分的数据他都会进行统计,所有的(英)的消息,我也会进入到这个统计里面去,但是这个本身其实来说对测试工具来说他并没有什么错,但是我们所有看到的测试报告,基本上20多份,所有都把Cbench的测试结果当成了仅仅对于(英)的一个测试结果,这个就是我们发现的一个问题,当然你不能说测试工具是错的,你也不能说是这些写出报告的人,或者使用这个工具的人是错的。而是说我们在使用一款开源软件之前,我们想要基于它之前,我们要问问自己是不是非常了解这个软件,不然都会沦为人云亦云的境地。如果你没有仔细看的话,实际上,如果分析了一下的话其实这是两个结果的总和,您的测试结果如果您只是说他是一个flow(英)的结果的话,就会有错误。

这个是关于我们之前跟Cbench这款开源软件打交道的一些经验,在这里边我们大概总结了一些收获到的一些经验吧。第一个就是说,如果你想使用一款开源软件,不要为了拥抱开源而去拥抱开源,你首先要定义清楚自己的一些需求,你真正的要求是哪些,你选择的开源软件是不是真正可以满足你的需求,如果不可以的话,我觉得您完全可以放弃,您可以另选一款开源软件,或者完全放弃开源的这种策略,因为我也见过很多的,除了Cbench这款开源软件之外,我也见过很多的厂商和我们做测试,他会做很多自己特有的特性,但是在我们实际测试中性能上不去,你那些特性,基本上对这些性能的提升是于事无补的,但是你本身对ODL,或者控制器的理解并不深入,对他的内核这方面并没有做一个很深入的了解,对他的性能提升基本上属于束手无策的状态。虽然大家都在说开源多么好,但是我想说,还是说,如果开源软件不能符合你自己的一些本身的需求的话,那你不如自己重新另起炉灶,或者自己重新开始一个项目。

那么我们就按刚才那个图来说,进入到我们关于控制器的性能测试工具这方面,我们会首先定义一些需求,我们虽然抛弃了Cbench,但是我们的需求还是在的,我们是希望自己搞,但是我们也要做清楚为什么要做这些事情。第一个我们需要的东西,就是说,我们需要和设备做一个高频率的互动,这方面发一些openflow方面的内容,这方面强调的,你不仅仅是说你的频率越高越好,你可以预先设定好你的频率,你设定一千K每秒,每一个东西都是你可以调整的,因为这些是你性能测试比较重要的环境,并且在这种环境下,你才能得到一个有意义的测试结果,这个是我们的第一个需求。

第二个需求对网络环境的一个比较灵活的模拟,他的意思就是说你是控制器,当然我就是模拟层交换机来和你对接,来和你做交互,在这个过程里面拿到你性能的指标。但是这个时候,你就需要对你的可以模拟的网络状态做一个灵活的调整,包括他的拓扑,他的整个的交换机的个数等等这方面的东西,当然这方面,Cbench是不具备的,但是我们是需要的,所以这是我提出来的大概第二个要求。

第三个要求就是说你需要很灵活的去改变一些比较关键的参数,比如说你上pack in的报文,他发的是多少的包,这些东西都可以灵活的调整,他所有上发的内容,你都可以有比较方便灵活的调整的接口,这样你就可以大量模仿网络的情景,这些是我们性能测试所需要的东西。

第四一点就是十分详细的logo,还有就是说一些测试结果的可视化等等这方面的东西,作为一个开源的测试软件我们可能并不需要一个图形的界面,因为真正的测试人员他们可能更习惯那种方式,如果你做的很简单的话其实这个并不复杂,但是对于性能测试的结果,我们还是需要一个可视的直观的方式来表现,并且整个测试过程我们都需要有一个详细的记录,这是我们提到的第四点的要求。

在后面介绍我们开发的这款工具之前呢,我先简单的描述一下标准和开源软件这方面的关系。因为之前我好像一直在唱衰开源软件,但是其实并没有这个意思,只是具体到我们具体的案例,我们在开源软件这方面得到的经验和教训因此而已,并不是说开源软件并不好。这里面我简单介绍一下开源软件的好处,我不知道大家是不是清楚,去年我们推出了openflow1.3,这款工具是第一款认证的测试工具,我们使用这款工具大概推出了三款交换器的openflow1.3的技术认证,这里想强调的是什么呢?就是说开源软件对标准的促进的过程。因为我一直在测试工作组做一些标准开发的工作,在我们没有这款软件之前,我觉得所有的标准的撰写基本上是一个闭门造车的过程,你看着openflow1.3的标准,你看着这个标准区写它的测试标准,但是实际上,你是拿不到第一手的反馈资料的,就是说你是拿不到实际的交换机厂商对这个标准的实际的。这些标准的撰写基本上在电话会议上大家讨论来讨论去,最后也没有一个标定的过程,这个时候我们要寻找一种方法突破这种局面,那个时候,我们就基于(英),我们整个测试的第一个,算是产品吧,或者说是第一个开源的测试,这个标准,在这个oftes上,我们做一些基准之后,可以跟一些交换机做对接,这个时候我们可以拿到第一手的资料,把这些消息反馈给ONF,这个时候我们最终才把整个的1.3的一致性的认证项目拿下来。所以这个也是开源软件对标准组织的贡献或者一种促进,所以这也是我们一直看好开源软件的一个原因。

现在我想介绍的是,重点介绍(英),我们现在介绍的控制器的性能测试软件,他基本上也是仿造一样的套路,没有基于Cbench或者其他的软件来做,而是重新另起炉灶开始做的一款开源的尝试。但是他所达到的一些测试过程,或者说测试反馈,都反馈到了ONF关于控制器标准的测试工作组里边,关于这个标准我们现在也基本上定稿,虽然还没有正式发布,但是已经有定文,现在是一个NFV内部的一个评审的过程,相信也是在最近可以得到发布。

另外呢,还有关于标准的一些介绍,就是说,并不是NFV一个人在写这个标准。下面这个表格是关于这个标准的对比,左边是ONF的,下面的内容是他的测试率,右边是IETF的,这个表格里面有重合的部分。第一部分,(英),大概只是一些描述或者名称,但是实际的测试方法都是一样的。但是我们也发现也有一些不一样的地方,比如说ONF更看重关于辅助通道这方面性能测试的能力。但是IETF就没有涉及这方面的东西,ONF有关于集群方面的一些测试的例子,但是IETF里面没有涉及,所以我们觉得ONF这边还是比较全面的测试标准,所以我们的工具也做到算是标定ONF的测试标准,后来把11个标准全部都实现。

介绍这么多,真正开始关于这款工具的总结,第一个因为他是一款测试工具,我们也没有专用的硬件专门跑这方面的东西,所以我们需要把我们的软件做的十分的轻或者说十分的快,所以我们这个所有的东西,都是比较底层的C语言来做的,能达到这一点。第二个就是我刚才介绍的,我们的所有测试方法,都是标准化,都是依据一些国际标准组织规范来编写的。

最后一个就是,关于它正在的使用过程,它是一个灵活的组织架构,有很多的API可以提供出来给我们所有的测试人员,在这个基础上需要定制化测试的,实际上都可以在这个基础之上开发。当然我们主要还是的还是说一套架构,他的架构是可以在我们所有的这些可能的最基础的一个因素。我们只是把这个架构当成一个测试的工具,当然在这个基础之上你可以把它用在任何一个你觉得有意义的测试工具。

简单的介绍一下他的一些测试。比如说像我刚才第一个介绍(英),他为什么可以大量的openflow。这样的话,我们就可以标定一下,控制器的一些性能。当然这里展示的是一个比较简单的过程,我们是ONOS的一个截图,最开始是一百个交换机,后来我们可以逐渐的增加这些交换机,因为我们这款工具考虑到的需求,所以我们这个模拟的交换机的数量基本上是属于限定的标准,什么意思呢?就是说,每一个交换机都会开一个,(英),但是每一个(英)都是一个文件描述符,操作系统对这个文件描述符的数量是有限制的。所以我们这个,因为他的架构非常轻,设计的也非常高效。所以最终,他能支持多少,是看系统,它的文件描述符是多少。所以这个方面,关于这个方面的性能,我们还是比较满意。

第二个其实就是,我刚才提到的,我们需要他对模拟的网络环境的,要十分的灵活,这个意思就是说我可以有些提供给他的使用者,自定义。在这个里面我们其实自定义了,其实自定义了三重,包括线性的,包括(英)。这个是一些截图,当然在这里,因为你如果交换机太多的话,ONOS的界面上基本上看不清楚的。我们预定了一些拓扑。他有一些旧的链路洞口,这个时候,控制器响应的时间,所以在这个基础之上可以实现很多测试。

至于第三点,关于我们和控制器之间做交互的介绍,这个意思就是说,你要和大家熟悉的openflow,你上送。但是我们又希望你上送这个pack in,比如你一秒钟发一百个,或者一千个都需要你去调整,这样才能更好的达到结果,同时这个我们需要恒定的,一秒钟发一百个,前一秒发了90个,后一秒发了10个,这个测试结果不是很客观的。每一秒0.01,一直保持这个恒定的速度。这个就是我们这款架构吧,可以做到的一个事情,在一个比较低端的服务器上,可以达到恒定的一千K每秒的时间,我在这里有一些发包,大家可以看一下那个时间撮。左边的这个是0.001秒发送一个,大家可以简要的计算一下,右边的那个,因为是一百K每秒,因为抓包已经出现很多聚合的情况,所以表现的不是太好,但是我们有一些自己的文件,也可以验证。

那这个的话,其实就是说,我们所做的这个开源的尝试,我刚才也介绍说,他并不仅仅可以作为一个控制器测试的工具,这一套架构之上,你可以做任何你想做的,我们现在想到可以把它改造成一个安全测试工具,什么意思呢?就像我们刚才说的发pack in,如果我们发的数量很大的话,对控制器来说就是一个dos的一个攻击,天然的可以转换成一个安全的测试工具,同时我们可以修改报文的任何一部分内容。如果比如说我们一个pack in报文,我把他改错了,这方面我们想做的一些工作,把架构能够更好的利用起来,能够更好的让他为我们的网络技术的推进和发展而服务。

那么最后就是,关于数据可视化这方面的一部分内容,因为我刚才介绍说,我们可能并不需要可视化的界面,但是我们需要可视化的测试结果,这个结果就是我们从我们测试报告里面截下来的一张图,这个是关于拓扑发现时间测试率的测试结果,横坐标应该是他模拟的交换机的数量。然后他的不同颜色的柱状图,就是代表不同的拓扑类型。比如说蓝色是(英),左边的纵坐标就是测试结果,就是你的拓扑的发现时间,为什么后边的没有黄色柱状图,因为我们当时的测试设备,已经没法做了,结果只能这样了。

另外关于这个工具的一个全面的展示,我们是把所有的这些东西,都是写到了一个测试报告里边,现在就是,关于opendaylight控制器,我把它改成了这样,大家的名牌后面会有一个二微码,二微码就是公众号,如果你扫描一下点击测试按纽,就会弹出一些新闻,这里面就有所有的关于测试性能方面的报告,也有我们上周举办的SDNFV测试活动的白皮书,所有的消息都可以在这里边来查阅。当然最后是关于这款工具的一些计划。当然这还是我刚才说的一些内容,但是我们可以做更多的测试,我们可以把它做成一个安全的测试工具,我们可以给他做一个图形界面,等等。所有这些我们都可以做,但是更想要强调的一点是说这款工具,他本身,你可以做哪些测试,他有哪些特征并不是最重要的,他本身是一个地层网络的模拟器,你可以用他模拟openflow1.3的交换机,未来你也可以把它模拟成(英)的一个东西,最后可以把它做成云里面的一个东西,都可以在这里面来做,总的来说这就是我们开源的实践。所以我们希望能够向产业提供一个灵活可用的,高价值的开源的架构,可以让大家把这个方面共同的来找到大家自己的乐趣和价值,就是这些,谢谢大家! 


原文发布时间为:2016年06月02日

本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。

网友评论

登录后评论
0/500
评论
行者武松
+ 关注