最近,由于工作的需要,对NFV领域的硬加速需求做了一次调研和分析,跟公司一线的同事,以及各产品线的架构师和产品规划人员进行了一轮“访谈”,结果却有些意外的冷,就像今年的冬天一样,寒潮来的实在了一些。


还是在2012年的时候,我在研发担任过一个硬加速技术项目的项目经理,当时这个项目还不是针对NFV,而是针对当时3G网络的RNC产品。那一年我们电信领域的盒子产品刚刚由vxWorks进入Linux时代,RNC的接口板、用户面单板由MIPS多核切换X86,面临最大的挑战就是性能问题,原来MIPS多核靠着MIPS的高效和芯片内嵌的一系列协处理器带来的卓越性能,在X86上一下子都消失殆尽,但在MIPS/PowerPC江河日下而X86在服务器市场如日中天的大背景下,切换到X86是一条正确且必须搞定的选择,因此用各种方法搞定X86在某些领域的性能不足就提上了日程,我那个项目就是在这样的背景下运作的。当然,我们确实也用尽了各种办法,用FPGA和多核处理器Cavium/RMI等做X86的协处理器,把RNC的用户面业务处理下移到协处理器上,甚至还有跟高校的合作项目去研究GPU在IP包转发领域的应用。项目也取得了一定的预期,加速后性能提升了2倍多。在TDCP汇报时,当时的BOSS说“2倍太少,要提升10倍”!在场的人都笑了,而这一笑就是好多年过去了。


关于NFV到底要不要硬加速,业界一直没有停止争论,主流的观点有两种:一种是“坚决不要”,理由相当的简单粗暴:设备要通用化,不能引入专用硬件,否则又回到过去专用硬件盒子的老路;另一种观点是“NFV有必要引入加速器”,著名的言论有Telefonica在2015年的NFV World Congress大会上说的“NFV!=IT云计算”,还有某位资深人士说过的“想清楚的运营商都在考虑硬加速,没有想清楚的都只要通用硬件”。孰是孰非,几年过去了,似乎还没有真正的答案,甚至连前几年雷声大雨点小的景象也没有了,这跟当下热闹得要炒到天山去的人工智能、CloudNative等完全不在一个水平,甚至有声音在质疑,硬加速究竟是不是个伪需求。

硬加速为什么当下这么沉寂,大致有如下几个原因:

1、NFV市场没有真正起来,性能压力不大

截止2017年10月底,全球共508个NFV商用合同,其中已交付完毕投入商用的大约20%,剩余的都是在项目交付阶段,也就是说全球大概100个左右的NFV合同正式投入商用。在这100个正式商用合同中,以核心网的vEPC/vIMS为主,按照每个项目平均百万级的用户数,这点业务量跟传统网络承载的业务量相比只是蜻蜓点水。在这种局面下,跟客户提硬加速,确实推动力不足。另一方面,转发类网元vRouter/vBRAS对性能要求比较高,确实有很大的性能提升空间,但转发类网元只有区区个位数的合同,考虑到正在投标和机会拓展的,全球大概也只有200个可能的商用合同,而新建vBRAS多数也是小流量大session场景,所以在当前这种形势下,跟客户提硬加速,显然为时尚早。


2、旧业务萎缩,新业务没跟上

核心网在NFV/NFC的商用推进遥遥领先于其它产品,然而运营商的话音业务持续萎缩,用FPGA做语音转码的需求显得并不强烈,当前使用X86的AVX指令能达到一个核几百路话音,也足以应付当前的业务量;VR/AR这几年也没有突破,视频业务并没有真正起来,视频转码加速优先级在当下也不高。另外,X86的处理能力不断增强,DPDK/OVS在IO能力和L2~L3的转发能力不断提升,使得云核心网的网元对转发性能的诉求也得到解决;AES/AVX指令层面的优化,使得像安全的加解密、视频的转码压缩等加速需求,在很大程度上用X86本身得以缓解。


3、技术方案众多,没有统一标准

当前硬加速方案可谓百家争鸣百花齐放,各个玩家各显神通,根据不同业务场景和自身优势,推出了各种硬加速方案,主流的有FPGA加速(标准PCIe的FPGA加速卡,NIC+FPGA加速卡,CPU内嵌FPGA)、GPU加速卡、Network Processor加速卡、Intel QuickAssist加速卡,以及人工智能领域的TPU和NPU。10+种加速硬件,要运行在各种CloudOS上,再被各个厂家的VNF调用,想象一下这是一件多么可怕的事情!假如没有统一的标准来管理这些加速卡,没有统一的接口来让上层网元调用,硬加速这件事根本不可能玩下去。运营商好不容易从专用硬件盒子的路上转到通用COTS,结果又被搞一堆专用的加速卡,客户不会接受的。



好在,标准和开源在硬加速领域的进展还算有序,ETSI已经完成了IFA1~4的发布,硬加速信息模型、接口的定义、以及Use Case定义,已经完成Rel-1的相关标准制定,Rel-2也已经立项开展,在接口定义和资源管理上进一步完善;Openstack社区成立Cyborg项目,由华为主导,保持与ETSI的标准设计一致,在今年的8月份发布了第一个带硬加速管理的版本。有了标准和开源版本,接下来的事情也许就可以顺理成章的推进了。


4、运营商的思路刚刚转换180度,接着再转90度有难度

运营商被专用硬件盒子折磨了很多年,NFV给了一次绝佳的机会来解除这种lock-in,不管NFV!=IT的思想对不对,客户第一步肯定需要的是NFV==COTS。大T对硬加速非常谨慎,普遍的客户根本不认可Network Processor的加速方案,尽管在网络转发领域Network Processor非常适合,但客户认为专用硬件方案跟当下的COTS格格不入;保守的客户甚至连FPGA方案都非常谨慎,认为FPGA的定制程度太高,FPGA加速卡跟NFVI和VNF都深度耦合,这跟NFV领域分层解耦的思想也冲突。客户不是没有想清楚,而是想的太清楚了,以至于设备商拿出的这种陈旧的解决方案得不到客户的认可。让客户再转身90度,不是一件容易的事情,得有足够的说服力,不仅仅硬加速方案得具备竞争力,而且商业模式上也得符合运营商当下的诉求。


5、硬加速效益提升有限,竞争力不足

VDF对于硬加速一直非常谨慎,他们认为硬加速的综合效益并不明显,硬加速卡的价格、运维成本都远高于COTS,只有能效比相对于COTS提升非常明显时才会考虑。业界对硬加速的不同应用场景的能效比做了分析,对硬加速卡的CAPEX/TCO做了测算,粗略的计算显示只有性能提升超过60%才有价值,而当硬件加速提升100%时CAPEX节省15%,整体TCO节省只有可怜的9%,所以总体收益并不明显。另一方面,硬加速在产品化时也面临一大堆难以解决的问题,比如加速卡的兼容性,功耗/散热/尺寸是否兼容各种服务器,驱动能否兼容各个HostOS/Hypervisor/GuestOS;加速卡的集成安装部署也是个问题,开箱下电更换加速卡对客户来说估计会是个噩梦;技术上也有一些问题没有完全解决,比如加速卡的热迁移、加速卡的资源池化、加速卡的备份等。在这些实实在在的问题解决之前,硬加速将会继续在困窘中前行。


2015年Telefonica的那位发言人说“NFV!=IT云计算”的时候,他万万没有想到,IT云计算经过几年的业务爆发增长,底层的硬件早已不再是纯粹的COTS和白牌,尤其是互联网巨头,他们不断在原来的硬件基础上进行优化,引入各种加速卡。其中微软已经公开其公有云Azure的硬加速方案,成为业界的一个标杆。

微软的公有云加速方案经过几代演进,如今定格在Catapult v2这个版本,它将数据中心网络分为三层:L0:连接24台主机,L1:构造一个960台主机的POD,L2:POD互连,共25万台主机,每级网络都会引入带宽收敛,但是微软的网络可以做到:固定hops、低时延(跨L2时延不超过23.5us)。微软在服务器NIC和TOR交换机之间放置一层FPGA,提供两种加速模式:


1、本地:所有网络流量都通过FPGA,可用作网络随路加速器和本地计算加速器;

2、系统:每个FPGA可通过网络与数据中心其它FPGA直接以微秒级延迟通信,无CPU干预。该灵活性可将FPGA组合成资源池,构建异构计算即服务(HCaaS)。


微软通过这套系统,在Bing搜索业务上提升2倍吞吐量减少29%时延;在人工智能CNN神经网络加速的推理场景获得相对于CPU100倍的性能功耗比提升;在网络交换方面,网卡上集成NIC和FPGA构成的SmartNIC 2.0,支持40Gbps的加密性能。


硬加速在公有云的另一个成功案例则是亚马逊提供的计算加速服务租售模式。2016年年底AWS推出FPGA加速服务F1,作为增强EC2实例提供给第三方进行租用,主要场景为基因分析、金融分析、视频图像、大数据业务等。亚马逊通过将FPGA绑定到计算节点,提供具备FPGA计算能力的实例F1,销售模式和普通计算实例一样,按小时为F1计算容量付费,无需签订长期合约,也无需支付预付款。亚马逊免费提供开发工具和开发指南,第三方开发者在亚马逊提供的工具平台上进行代码开发和镜像制作,然后加载到F1实例上,同时也可以从AWS Marketplace上购买已经开发好的FPGA应用包,也可以将自己开发的应用包放到Martplace去售卖。

微软Azure和亚马逊AWS对硬加速的应用是两种典型的模式,微软是用来加速Azure自身的性能,微软的搜索、人工智能分析等都依赖于加速资源;而亚马逊则是将硬加速作为一种服务对外销售,共亚马逊的客户当作基础资源使用。两种模式现在看来都是成功的,对电信NFV来说,无疑都具有借鉴意义,尤其是AWS的模式,也许能给NFV的硬加速找到第二条出路。


如果几年前说“NFV!=IT公有云”,那是因为以前的公有云业务才刚刚起步,没有刚性需求用到专用的硬件加速,那么随着这几年公有云的急速膨胀发展,原有的网络架构已不足以满足当下的业务诉求,互联网巨头纷纷根据自身业务需要采用了最合适的技术,不管是微软的FPGA,也或是Google用以AlphaGo下棋的TPU,目的都是一个,用综合成本最优的解决方案。电信领域实时性、大流量场景更多,未来NFV一定会像今天的公有云一样,对硬加速的需求只多不少。


NFV硬加速可以从当下和未来两个层面来考虑,当下硬加速主要的场景有大吞吐量的报文转发类、高实时性的媒体处理类、计算耗时的安全加解密、以及算法复杂的业务感知类,各个设备商包括Intel都在寻找合适的方案去解决这些硬加速的需求。FPGA的通用性可编程性为其在加解密、报文转发、甚至包括视频转码几乎所有领域,都占据了最大的份额;GPU则凭借着易用性和突出的并发计算能力,除了视频转码外,在人工智能领域也获得不小的突破;而昔日明星Network Processor则逐渐没落,只能在报文转发领域有一些应用,最关键的问题是客户对网络处理器作为加速卡的不认可,这种在盒子时代创造过的辉煌恐怕很难在NFV/Cloud时代继续了。


未来电信网络对硬加速需求,主要是CU分离、5G、MEC以及人工智能领域。


◆    CU分离后,U面对性能的要求更高,专用盒子做U面一定会被运营商诟病,通用服务器+加速卡方案也许会成为主流;Intel联合中国电信以及HPE,采用FPGA版的增强网卡对CU分离的vBRAS进行测试,性能提升3倍,总功耗降低50%;

◆    5G网络要提供超乎想象的大带宽和低时延,那么只靠COTS性能难以满足,5G RAN、5G CORE以及5G前传,都有非常大的性能提升需求;

◆    MEC场景中受制于机房空间、散热、成本等因素,同时应用下沉会极大的增加MEC节点的计算开销,使用综合性价比更高的硬加速方案也许是唯一的选择;

◆    人工智能领域的硬加速在互联网公司已经大规模使用,无论是百度的FPGA版百度大脑、Google的TPU版AlphaGo,还是Tesla的GPU版无人驾驶,只靠通用CPU根本无法满足计算要求,采用硬加速方案对能效比的提升都在几十倍以上。电信领域的AI仍在探索研究中,但可以预见的是在将AI引入到自动化网络优化和故障分析预测等场景时,海量数据的处理、基于神经网络算法的推理和学习会占用大量的CPU和内存资源,这对资源本来已经捉襟见肘的网络设备来说是无法承受的,引入专用的人工智能芯片将会是大概率事件。


回到当下,NFV硬加速的推进滞缓一方面是因为NFV的市场以及像视频这类新的业务增速缓慢,另一方面则是硬加速本身技术竞争力方面存在问题,包括标准的滞后、产品化时的一系列问题。各个设备商在推出硬加速方案的时候,都是和VNF、NFVI强绑定,客户理所当然不愿意接受。改变这种局面一方面靠标准约束,另一方面则需要转换思路,寻找新的模式。游戏软件与显卡具有性能方面的强依赖性,但游戏公司从来不自己做显卡,同样,VNF厂家为什么一定要自己做加速卡呢?把FPGA像GPU一样,硬件的生产加工交给像华硕、微星、七彩虹这类制造业公司,在工业界定义好硬件接口、软件API,然后把驱动生态完善,VNF就像游戏公司一样只做应用,最多可以优化驱动提升自身VNF的竞争力。另外,AWS的模式一样可以借鉴,VNF厂商针对加速卡开发的应用和驱动,可以放到电信云的Marketplace上去兜售,而不是仅仅的只能垂直端到端的交付。


当至尊宝坚持认为“爱一个人需要理由”时,菩提只能用“我是跟你研究研究嘛,干嘛那么认真呢”的方法给自己找个台阶下,这跟当前NFV领域硬加速的尴尬何其相似。但我们满怀信心,未来可能不是NFV做大了需要硬加速,而是硬加速的大规模应用反过来促进了NFV的成功,就像有了Google的TPU,人类才有幸看到AlphaGo战胜柯洁一样。



©著作权归作者所有:来自51CTO博客作者mob604756f52321的原创作品,如需转载,请注明出处,否则将追究法律责任

更多相关文章

  1. Python实现二叉树的三种深度遍历方法!
  2. 一文带你领略JS中原型链的精妙设计!
  3. 一些Java开发人员在编程中常见的雷!
  4. 学软件测试看什么书籍推荐?
  5. Python技术分享:深入理解ThreadLocal变量的功能和使用
  6. 苹果 iOS 14.5 如何自动下载新的播客剧集并关注节目?
  7. 一文学会怎样设置AppleWatch手表自动解锁iPhone手机?如何用iphone
  8. Azure首席架构师John Gossman就微软加入Linux基金会一事答疑
  9. 智能化运维时代真的来了?这些必备技术你都懂了吗?

随机推荐

  1. SurfaceFlinger学习之路(一)View的绘制流程
  2. Android快速滚动
  3. androidmanifest.xml高级属性解析
  4. Intellij下的android实践
  5. android 创建文件夹失败
  6. Android平台上的JNI技术介绍
  7. Android通过startService播放背景音乐简
  8. Cordova+Vue整合到android studio上实现
  9. Android(安卓)Studio代码调试技巧篇
  10. android生命周期()