思博伦 王岩:思博伦致力于从SDN /NFV测试方面推动其近一步落地

简介:

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

 王岩,思博伦通信虚拟化测试解决方案市场拓展经理

思博伦通信虚拟化测试解决方案市场拓展经理  王岩

思博伦通信虚拟化测试解决方案市场拓展经理王岩表示,目前业界针对SDN /NFV的测试面临着诸多问题。Openflow协议虽然有标准,但是控制器与不同OF交换机的互通仍然存在问题;SDN控制器南向接口协议众多,北向接口却尚未标准化;控制器和VxLAN交换机的单机测试能否覆盖实际的应用场景还需推敲;且测试工具和方法仍存在不确定性;最后,虚拟化框架NFVi性能是NFV测试的难题。根据以上这些问题,王岩在会上以“思博伦通信助力SDN/NFV部署”为题发表了演讲,为与会嘉宾,从思博伦的角度,阐释了思博伦的测试解决方案是如何解决了以上问题。

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

王岩:各位来宾大家下午好,首先感谢组委会,邀请我作为演讲嘉宾给大家分享一下思博伦通信在这几年做SDN/NFV测试方面所积累的一些经验,在这两天的议题里边,我们听到了很多让大家觉得振奋的一些产品,技术上的解决方案。那思博伦通信一直致力于推动SDN/NFV测试这方面的技术发展,所以我们也非常希望能够有机会和在座的各位一起,完善SDN和NFV的一些测试解决方案,包括测试工具还有包括测试产品。共同来推动SDN和NFV的部署。

今天,我们给大家分享的内容,主要是在这几个方面,在这几年我们做了很多SDN和NFV相关的一些测试,包括跟运营商,包括和厂商。还是发现有很多测试方面的困难,对应的解决方案,在思博伦的产品解决方案中会给大家一个解决方案,对于SDN和NFV的测试方案来看,虽然大家做的很热,北向接口和南向接口的开发如火如荼的进行做,在实际的测试里面还有很多的问题,第一个就是接口的标准型,提供了相应的一致性的测试,但是在不同厂商之间。在overlay这一层,不同厂商之间可能在Vxlan的互动上也会面临一定的困难。

对SDN控制器来说,SDN控制器的接口非常多,南向的openflow。我们看到很多供应商提出一些APP的概念,当然它的前提就是面临着北向接口的标准化。在这方面思博伦通信和国内的运营商,中国移动,在广域网的SPTN的领域已经做出了一些工作,我们把他合作定义了SDN北向接口的标准化,这样的测试解决方案,希望能够致力于推广在SDN控制器北向接口这种标准的向前的推进。

第三部分,就是说,在我们实际的测试里面,现在我们对于SDN,或者是交换器这块的测试大部分都是作为单独的一套系统,独立于云的环境进行测试的。其实这里面有一个存疑的地方,我们进行了这样的测试,是不是真正的完全能够覆盖到SDN真正部署到数据中心以后他所有的应用场景,毕竟在整个云的数据中心里面,他还面临着跟openste( 英)控制器这些节点的机制,这些方面我们是不是以单纯的测试方法,就能够体现出来,它所有的问题?包括测试工具本身我们客观的说,现在也在努力的去追赶各个标准的,或者是厂商的这些技术的发展。那我们在openflow上做的是比较完善的,包括在测试方法方面,都在致力于这方面的工作,思博伦通信也是努力的和各个标准单位一起在合作,希望能够推进测试工具和测试标准的完善性。

前面提到的都是SDN方面的一些测试。对于NFV来说,那我们可以把它分为两个层面上来看。传统的NFV其实对于我们测试仪表的厂商来说,这个并不是一个大的难题,因为我们可以把它等同于一个传统硬件的这种测试方法。反而来看对于承载NFV的I层是我们现在很困难的一个测试点。就是说怎么样的什么样的I层的结构,不管我们是在ovs形成的优化,还是在切片这层形成的优化,到底他提升的性能的程度是我们需要一个测试工具和测试方法来进行完善的。这就是我们在思博伦通信和大家在一起希望能够推动整个业内测试标准所需要努力做的一些工作。

思博伦通信对于在整个标准合作上其实是非常积极的,我们作为ONF,这些都是最早期的合作厂商,国内这边我们也积极的和国内几家运营商的研究院展开全面的合作,推动SDN北向接口这些方面,甚至在南向接口的标准化方面,我们也会努力的做一些这方面的工作。对于SDN的整体架构上来看,在整个的SDN的解决方案里面,我们把它看为南向接口的相关的协议,overlay这一层的,还有其他的一些协议。那这些,我们把它作为传统测试仪表的一个解决方法。因为在这种测试里边,它需要依托于硬件来产生对应的流量,新的软件的功能模拟这些SDN所需要的协议。北向接口这方面就变得复杂一些。那,我们知道北向接口基本上通过res(英)的EPI进行控制的,除了一些接口性能上的测试以外还面临量子模型,这样的一些测试场景,这些方面非常类似于编排层的调度的工具,在这个层面上思博伦借助于自动化的测试工具和方法提供北向接口的测试,包含一致性的测试工具和测试方法。到底虚拟化或者SDN的测试对于我们测试工具的厂商来说区别在哪里?这里面我们可以看到,对应于SDN或者是NFV的测试方案来说我们把它分成了两个部分,第一部分是传统硬件能做的,这里面看到的我们大的硬件的机框,用我们的(英)这样的测试工具来模拟我们所需要的这些协议和流量。

在另外一种场景需要在虚拟的网络中产生的这种业务数据流量或者是协议,我们把它作为这种虚拟化的测试口解决工具的这种测试场景。那在这部分,我们把原有的硬件仪表,基本都实现了完全的虚拟化,在原有的硬件测试平台上能够实现的功能和协议,在软件的虚拟化的测试工具上,也都完全能够向大家提供了。

那对于整个SDN来说,ander(英)的这一层,或者是物理网的这一层测试是不可避免的。对于这样的 测试场景来说我们提供了一个最新的,我们可以叫测试板卡,我们可以提供不同速率的测试的需求,在这里面能够满足我们对于数据中心,我们做了32个100G接口的还有48个100G接口的测试设备,这种测试场景,这里面我们不光是解决了接口速率匹配的问题,还可以在overlay这一层的协议上,来进行一个仿真,在交换器的测试里面,我们这种方式不完全足够,我们还必须要模拟这种SDN的控制器来下发流表这样的一个闭环测试场景来实现。在这个场景里面,思博伦通信的测试解决方案,提供了一个完整的闭环测试系统,在中间我们可以通过测试工具所提供的SDN控制器的仿真来实现对于openflow交换机这种协议上面的可控制。

在这样的一个闭环测试系统里面我们能对整个数据中心交换机,硬件层面上的指标,包括他的流表数量,转发能力,这些学习时间等等这些指标来做一个全面的评估。另外一部分就是对于这种控制器本身的一些测试,在这个测试场景下,我们就需要,我们有对应的高性能的工具,来模拟数据中心的交换机,OVS,TV2,来向数据中心的控制器上报它的一些状态,来跟openflow的控制器来建立连接,这样我们关注的指标变成了从控制器能够管理最大交换机的数量,能够支持流表的(英)的这种能力的评估的测试。这些方面,都是借助于我们传统的硬件,能够完成的。

从协议层面上来看,这些overlay或者是an(英)的集成协议在我们的硬件流上提供了支持,我们常见的openflow的协议,这些Vxlan封装的协议等等我们已经提供了很好的支持。包括数据中心互联,我们也提供了支持。对于SDN控制器来说我们之前所强调的都是一个对它的性能这些方面的评估。但是有一个很重要的,控制器的这种智能,弹性也好,这些功能都体现在调度层面的,这种调度层面跟下层的网络有很大的关联性,包括故障,保护时间的切换,这些场景体现各个厂家控制器的优势或者是独到算法的地方。这种功能的验证其实我们怎么来做,在这个方案里面实际上我们是通过对于虚拟网络质量的一些模拟手段,来把我们SDN控制器的这种调度算法的机制进行一个验证。

在这里面我们看到中间部分的这些工具把网络的质量这部分因素模拟进来,可以创立丢包,时延这些故障的场景,由控制器探测到故障以后,他所有的调度工作是不是能够生效,所以在整个测试闭环系统里面我们还可以借助于流量发生器,借助于完全虚拟化的产生流量,这样的话,就可能对SDN控制器的一个智能调度的能力进行一个验证。

前面提到的都是SDN方面的一个解决方案,对于NFV的测试来说,我们前面提到了,对于NFV我们如果是对于NFV功能本身来看,它跟我们传统的这些网源的测试,防火墙,EPC这些,CPE,这样的一些网源测试其实没有特别本质的差异性。对于这方面,我们刚才也提到了,这些所有思博伦现有的硬件测试仪上的协议仿真的能力,和功能,都实现了虚拟化。也就是说我们把硬件的仪表可以以一个虚拟测试仪的形式部署到我们的虚拟化平台上协助我们完成测试,在这个二三层做的工作包括最简单的流量的仿真,做一些转发性能的测试,2544,2889这样的测试方法,对于协议层面的模拟,能够对PPOE这些性能上的一些压力的测试,这些都可以在我们二三层的虚拟化的测试工具上来完成。

应用层的安全,在座的如果跟虚拟防火墙,这些应用层的解决方案的厂商相关的这些嘉宾可能就比较关注了。那在很多虚拟化NFV的测试平台上,我们可能需要解决的是一个怎么在公有云的平台上部署的问题,思博伦的解决方案,也能够帮助我们在不同的云平台上解决测试的问题,这些测试工具,不光可以部署在我们实验室的测试环境下,也可以部署在公有云的测试环境,对我们NFV部署的功能进行验证。
对于整个虚拟化,NFV的测试,我们现在提出来一个新的测试闯,这面我们可以看到,从物理服务器上面,他所安装的虚拟化的这种heb(英)这种测试场景下我们可以通过前面提到的虚拟化的测试工具,来对我们不同的网源来进行评估测试,可能是虚拟路由器二次功能的转发,协议的互通做一个验证,也可能是应用层的设备进行测试,甚至可以作为这种EPC的网管进行验证,5G的方向上,他的EPC的部分和接入网的部分都会要求。我们开源的工具完全实现不了的,必须实现测试工具有很深的积累才行,这方面是我们思博伦作为传统的仪器测试工具的厂商,所具备的最大的优势。除了单纯的测试工具以外,我们还提供了一个自动化的调度,这样的编排层这样的工具。在这个工具上,我们通过自动化的对应的接口,rest的接口或者其他的接口来对我们整个测试床里面所需要的NFV的功能,服务器的配置,网源的配置,测试仪表的结构统计诸多的指标进行统一的管理,不需要对单独的某一个网源逐一配置去做,很快的帮我们解决快速部署,快速场景切换这样的一个功能。所以这是一个完整的针对SDN/NFV的一个测试床,能够更快的加快我们在SDN/NFV测试的效率。

测试NFV的测试方面有很多,有DBDK这样的一些硬件厂商提供的解决方案,我们可以通过硬件仪表结合软件的方式来做。在这里面我们通过外部流量注入的方式,通过硬件仪表连接在服务器网卡的40G,100G接口或者其他接口类型的网卡上面,通过流量注入到虚机的内部,中间的转发可以依据OVS进行转发,也可以依据第三方的工具,能够帮我们做这种OVS性能的评估,同时也对DBDK转发能力进行很客观的,很精准的指标的衡量。

在整个虚拟化,或者是NFV的演进方向上,其实对我们研发的体系有一个很大的挑战,我们现在讲敏捷开发这样的一些场景,在这个场景下我们传统的硬件测试工具不具备这样灵活的特性了,所以我们把测试工具全部虚拟化了以后,又衍生出不同的版本,来适合我们在不同的研发测试,运营管理,或者是做QA团队所使用的一些组装,比如说QA团队需要一个很丰富的协议能力的虚拟化的测试工具,这就是我们使用的(英)这样的工具。刨除硬件仪表的限制,他完全在虚拟化的测试床上进行脚本的开发和功能回归的测试。另外场景包含的现在虚拟化技术的发展,我们从原来的环境,(英)可能将来还会向一些容器化方面发展。思博伦把这些测试工具,也都提供了不同平台的支持,思博伦是目前业界唯一最早提出doc(英)解决方案。所以对于不同的测试场景我们的虚拟化工具有不同的类型与之匹配。

最后我们还可以看一下,在NFV的使用场景里面很多是在公有云上来做的,比如我们做的虚拟防火墙,虚拟路由器,他可能会在阿里云,亚马逊这些公有云平台上测试,我们传统的测试根本没有一个介入方法,这样的测试场景是不现实的,我们思博伦通信也开发了基于公有云平台的测试解决方案,这里边的测试工具,我们叫(英),他包含了三个测试功能的组建,第一个我们把它看作是一个流量的性能压力,也就是说在我们的公有云平台上构造我们需要不同的QAS,封装格式的数据流量,验证我们在公有云平台上他的转发能力,这方面的测试。

另外就是测试中心,我们看到不同的标准,他都会有自己的测试规范,这些测试规范落实到我们具体的测试上面,可能会需要变一些很复杂的测试脚本,这方面所需要的工作,就不如交付到,像整个在生态系统里面我们专门做测试的厂家来完成,这里面我们提供了一个完整测试方法学的知识库,在这里面会不断的完善,不断的更新,满足我们将来在SDN和NFV测试领域上所需要的测试方法学方面的支持。

第三块关于云平台,虚拟化平台压力测试的工具。第一个,我们看,公有云平台上的一个转发性能,这部分不光在公有云,或者是在私有云,混合云的场景下,来在纯虚拟化的环境下构造我们需要的测试流量,对我们中间的虚拟的这种网源,NFV的网源进行一个测试,他同时也可以作为一个虚拟网络健康度检测的一个工具。比如说我们需要很小的探测流量长期的检测数据中心与数据中心他网络的健康度的情况。然后我们标识一定的健康度的域值,高与多少会产生报警,这样的测试方法能够解决我们在公有云或者这样的一个场景下,对于流量仿真上的一些需求。

第二部分,我们刚才也提到了,就是关于虚拟化平台上的压力测试的工具,压力产生的工具,这个工具我们叫cloudstress,它通过对虚拟化资源的占用,来看我们能提供多大的内存的读写速度和磁盘的读写速度以及网络的吞吐量,这样的工具很好的帮助我们解决NFV在部署之间,对于平台性能的验证。这个可能是我们很多做过NFV的厂家所面临的问题,你的功能做好了,都不错,但是部署在不同的公有云平台上就会存在一些差异性,这些差异性,你也没有办法借助传统的测试方法来完成,这样的工具其实就是帮助我们解决这样这些问题,把这种测试工具部署在公有云平台上,由他所测试出来的性能的结果,CPU的最大利用率是多少,是不是有相互的资源独占的能力,或者资源的抢占的问题,我们都可以基于cloudstress这样的工具来获得我们的结果。把这样的工具可以延伸到跟overlay相关的测试,对于NFV本身的一些相邻资源的噪声的测试,我们NFV的功能,在一个正常的运行状态下,如果周边的同一台速读机上面有另外一个NFV的网源在跑,但是他占用了很大的CPU,或者是磁盘读写一些资源的时候,会不会对我们当前的网源产生性能的影响,我们可以借助于这样的工具和手段进行验证的。

刚才也提到了,我们的SDN也好,NFV也好,可能很多情况下,都不能够排除跟openste(英)这种公有云的管理系统拖开关系,我们能够支持的管理的能力是多少,也包含对openste这样的节点的测试,单独的控制场景,不能单独完成云部署环境下的需求所产生的工具,在这个测试里面,我们通过我们叫hyperScale,把我们的测试工具部署在平台上,可能是公有云平台,由这些产生的大量的虚拟机,我们可以经过实际的验证,在单一的服务器上,我们可以实现两百到四百台虚拟机的部署,并且以后能够产生交叉流量的场景,这样的话对于SDN的控制器是非常有价值的,以前我们对OVS也好,对于SDN的控制器也好,这些流表的产生都是基于我们的脚本产生的。我们是通过真实部署的虚拟机,我们在这种复杂的流表下面来进行流量的压力测试,刚才提到的单机部署200到400个虚拟机。我们这个hyperScale工具实际上帮助我们解决在SDN控制器,或者OVS做优化,或者openste这方面做评估所进行的场景。整个测试过程中,hyperScale通过简单的应用管理界面帮助我们看怎么做overlay来进行流量的统计,最后我们可以看到,整个在这末大规模的虚拟网络下面我们的控制器或者我们的虚拟网络,它的转发的情况,是不是跟我们预期的是一致的。

在这样复杂的一个测试场景下,我们也提到了,前面有个NFV的测试,这张图上看到的是我们和ATMT在北美所提供的一个标准测试床,这是基于系统架构上所产生的测试工具,测试脚本的维护,还有被测试网源的集成的测试环境,有了这样的一个全面的测试工具,包括测试脚本以及配置这样的一个测试环境的话,能够非常方便的帮助我们去解决在NFV测试方面,我们所面临的测试工具复杂,脚本难以维护,而且各种资源之间的一个结果的协调和一致等等这方面的相关的这些问题。

那我今天演讲的内容就这么多,所以希望有机会能和在座的各位厂商一起,我们来推动SDN和NFV技术向前推进。如果有希望在SDN和NFV测试方面,有需求的这些在座的各位嘉宾,可以我们下来在我们的展台上进行交流,谢谢大家!


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

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

相关文章
|
11月前
|
SDN 网络虚拟化 人工智能
带你读《智慧光网络:关键技术、应用实践和未来演进》——2.9.6 光接入网SDN/NFV
带你读《智慧光网络:关键技术、应用实践和未来演进》——2.9.6 光接入网SDN/NFV
|
SDN 网络虚拟化
SDN与NFV分类对照表
SDN与NFV分类对照表
163 0
SDN与NFV分类对照表
|
云安全 存储 SDN
第一章 SDN介绍 (附件2)【SDN&NFV基础、云计算】(三)
第一章 SDN介绍 (附件2)【SDN&NFV基础、云计算】(三)
164 0
|
SDN 网络虚拟化 云计算
第一章 SDN介绍 (附件2)【SDN&NFV基础、云计算】(二)
第一章 SDN介绍 (附件2)【SDN&NFV基础、云计算】(二)
149 0
第一章 SDN介绍 (附件2)【SDN&NFV基础、云计算】(二)
|
存储 运维 负载均衡
第一章 SDN介绍 (附件2)【SDN&NFV基础、云计算】(一)
第一章 SDN介绍 (附件2)【SDN&NFV基础、云计算】(一)
207 0
第一章 SDN介绍 (附件2)【SDN&NFV基础、云计算】(一)
|
存储 物联网 大数据
论数据中心SDN和NFV技术关系
论数据中心SDN和NFV技术关系
314 0
论数据中心SDN和NFV技术关系
|
5G 测试技术 API
5G架构之NFV和SDN | 《5G移动无线通信技术》之十一
本节介绍了5G架构的NFV和SDN,包括成立背景和基础信息等。
5G架构之NFV和SDN | 《5G移动无线通信技术》之十一
|
SDN 网络虚拟化 异构计算