Intel陈静:使用DPDK加速NFV

很高兴来到这里和大家讨论NFV的现状和未来。今天的内容很多,那么长时间现在留下来的应该是无论体力还是劳力,你们都是认真的人。

今天主要有四个议题,一个是说为什么要有网络功能虚拟化,另外一个是讨论一下在网络功能虚拟化的场景下面,我们怎么样应对这些挑战,我们怎样部署底层的IO网络。最后想讨论一下关于DPDK。

在网络功能虚拟化出来之前,服务提供商或者电信的运营商,它向设备提供商购买专用的硬件或者软件,在软件和硬件之上,部署自己的业务,但是一般来讲,其实这里面有几个问题,第一个是无论是硬件也好,软件也好,都是因为某种功能而进行了特殊的设计和优化的,所以说它的研发成本会很贵。另外因为它是为特殊目的而服务的,所以它的客户也不是那么广,所以会造成它的成本很高,卖给服务提供商,你的价格会很高昂。运营商购买这个设备了之后,部署的这个软件是和设备商紧密耦合的,这个耦合性非常高。如果要换一个服务提供商,或者一个设备提供商,你的设备可能要改。当你企业的业务需要扩容的时候,你重新需要部署网络,部署一些布线,服务器,你的扩容,你的运维成本也会很高。

基于这三个问题,我们提出了一个NFV的解决方案,核心应该是只有两点,一个是用市面上可以买得到的通用的服务去替代专用的硬件设备,另外用开源项目的软件去替代专用的一些软件,这样有两个好处,一个是这个硬件和软件完全耦合了,你的设备运营商不会依赖于设备的提供商的一些软件。你的采购成本会大大降低,从开源项目和通用的服务器。它的运营成本的问题,NFV主要是通过资源的持化,包括网络功能的持化,还有存储功能的持化,通过虚拟化的方式可以灵活部署自己的业务,使你的运营成本也会降下来。

在网络功能虚拟化的环境下面,对我们底层的数据面提供了什么样的需求呢?我想大概不外乎几点,一个虚拟化,一个是高性能的网络,易于编程,有很强的灵活性,可以快速的进行热迁移,这个是对我们数据面提供的一些要求。在几年以前,我们是怎么样的一种方式呢?我们写一个应用程序,通过内核的网络,把这个数据包文发送到网卡上面去,再送到网络上面去,这传统的方式。所以又有了右边两种的编程模式。通过网络,把网络设备,主要是网卡,通过虚拟化,通过把网络功能切片的方式,虚拟化采用SRV的技术,把VSwitch部署到虚拟机里面去,一种用传统的SOCKET的方式,还有一个轮训驱动的方式,有比较不好的缺点,编成灵活性不是太好。

综上所述,我们有一个比较好的编程模型,我在虚拟机和底层的网卡之间架设一个虚拟的交换机,所有的报文只要进出网络都要经过这个交换机,通过软件交换机的方式可以对它灵活的进行编程,而且实现一些差异化的服务,或者说做一些流量监控,防火墙等等。在虚拟机里面它不能再使用SRV的方式,可以解决之前的一些问题。事实上这种方案和SRV相比,你的性能也好,延时也好,其实大大降低了,是通过网卡,不是通过SRV的方式,主要是通过软件虚拟出来的一个网卡,所以是CPU来做的,所以你的性能不是很好。我并不是说右边的这种方案是一个完美的方案,像张总说的没有最好的方案,只有最适合的方案。每个方案的部署,它都有自己的需求,只有把这些需求转换成对技术的需求,才会是一个最好的方案。

OS现在有两种版本,把DPDK做一个后端,从而获得有一个比较好的性能,这个OVS怎么样运用到NFV的场景下面,怎么预设进去呢?

FD.io最早是思科、因特尔最早提倡开源的项目,很多厂家都积极的加入到里面,也包含了很多的子项目,这些子项目也是独立运行,其实它主要的目的就是打造一个四成到七成协议上面很好的工具,好的库,并且实现高性能的高处理。中间有一个大块把网卡的功能进行抽象的一种VPI,当用户程序使用这种VPI的时候,你不需要关心这个问题,因为它有一个统一的接口。

驱动中断的一种程序,从收到中断到用户真正拿到这个数据包,执行度是非常长的,这种的编程方式不是那么好,是采用一种轮训的方式采用数据报文的。之所以有这些API的作用,因为我们是打造一个快速报文处理的一个包,而这些小的库完全实现了很多的优化。下面还有流分类,右边还有一些关于硬件加秘设备的一些指示,DPDK不仅仅只有我刚才介绍的那么多,实际上有很多的库,其他的一些功能,其实大家可以去发掘。

这里谈一下DPDK的性能。我们经常聊到DPDK的时候一定会说DPDK性能到底是什么样的,这个是因特尔主机的转发能力的示意图,竖轴是每秒钟可以处理多少个报文。从2010年到2015年,我们从55兆到现在提高了六到七倍。另外一方面是各种的优化才能达到这么好的性能。

哪里可以下载到DPDK?一个就是在DPDK GitHub,这上面可以下载到最新的原代码,可以下载到所有的文档。从OS的里面,它们自己都已经集成了DPDK的版本,问题是这里面的DPDK版本不是那么新,如果想要获得最新的还是到DPDK.org去下载。他们提供的这些DPDK的版本肯定是当前的OS版本上面跑的比较稳定的,他们经过一些测试的,所以说这算一个好处吧。

我这里想通过一个问题来引发DPDK采用了哪些性能优化的技术。这个问题是什么呢?想象一下,如果我们说我们的主机能够达到40GD限速转发能力,我有个主机接收到网络包问,每秒钟有40G的流量,收到了之后同样有能力在这一秒以内把这40G的流量再转发出去,40G的流量换算成报文是多少个呢?差不多每秒有60个包,平均每17纳秒就会有一个报文到达主机,纳秒是秒,毫秒,微妙,纳秒。现在有一个服务器,主屏是2G,差不多每33个使用周期就要处理一个网络报文,33个使用周期是什么概念呢?我们大家都知道字库是离CPU最近的一个部件,L2是1个工作周期,L3差不多36-40个使用周期。大概是100多个使用周期到几百个使用周期不等,我实行最简单的报文处理,CPU把网络报文读进来,什么也不做,仅仅把它读进来,把它转发出去,大概涉及到多少个内存图形呢?至少应该有6-10次左右,驱动怎么写呢?通盘的考虑这个问题,要处理一个网络报文,仅仅内容就需要1000个以上了,但是我们的要求是说你只有33个去考虑内存。你还要进行上下文的切换。所有的东西加起来把我们的任务变的不可能完成一样的。

之所以提出这个优化方法的目的,一个是跟大家解释一下DPDK怎么样,另外一个,DPDK好象飞的很慢,大家在自己的程序例找找打造一个快速的高效的解决方案。

更多关于2017未来网络峰会的报道,请点击链接:https://www.sdnlab.com/2017-gfnds/


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/19066.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于17-04-18
0