网卡革命―华为iNIC1000智能网卡评测报告
开篇：润墨网以专业的文秘视角，为您筛选了一篇网卡革命―华为iNIC1000智能网卡评测报告范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
因为工作的原因,我们经常在服务器上利用开源软件搭建一些测试环境,用以考察新软件或硬件平台的实际性能。长期的测试让我们注意到,无论是单路、双路还是四路平台,只要CPU核数超过两个,对I/O密集型应用的性能提升也只是微乎其微。更有甚者,双路平台下某些应用的性能竟不及单路平台,显然有违常理。
也并不是只有网络通信和安全方面的应用才算I/O密集型应用。经常关注实验室评测报告的读者朋友们应该注意到,我们已经很久不用静态页面脚本测试服务器性能了。甚至ASP、环境下负载较轻的脚本,测得性能也只列为参考。这是因为,失败的HTTP请求总是过早地出现,此时CPU占用率却并不高。而以往的经验(包括计算机世界实验室评测标准中的规定)是,只有当处理器整体利用率达到100%才会出现错误,这个临界值就是服务器针对当前脚本的最大处理能力。
前段时间,我们特别针对这个问题进行了研究,希望找到真正的原因。测试平台是一台配备了双路英特尔至强5472(3.0GHz,共 8核)、5000P芯片组、8GB FB-DIMM、双口英特尔82575EB网络控制器的服务器,操作系统采用了64位Red Hat Enterprise Linux 5.1,与多数商业用户目前实际使用的配置相仿。2.6.18版的Linux内核也能很好地支持我们选用的硬件平台,系统安装完毕即可开始使用。Kernel的配置文件表明,内核已开启NAPI模式处理网卡传送的报文。考虑到多数用户的使用习惯,我们没有再做更多的优化工作。
既然要最大限度地暴露问题,测试模型肯定要选择I/O密集型应用。配好网卡IP,启用静态路由,再使用iptables加载一条策略,测试平台就被改造成一台最原始的双口包过滤防火墙。我们按照RFC 2544规定,使用思博伦通信提供的SmartBits 600网络性能测试仪进行了测试。结果表明,测试平台64字节报文双向吞吐量只有29%,意味着实际处理能力还不到600Mbps。
8核至强平台的性能如此不济?看看系统资源的占用情况就明白了:8个核中,有6个核几乎没有负载; 其余两个却已经满载,且资源全部消耗在软中断处理流程中。显然,为了优化性能, Linux Kernel使用了网卡与处理器核绑定的业务处理方式。也就是说,跑包过滤防火墙这样的业务,理论上双核处理器即可达到同样效果。虽然这种情况可以通过代码优化的方式解决,但对普通用户来说是不现实的。
我们还在拔掉一颗处理器的情况下进行了同样的测试,64字节报文的双向吞吐量上升至34%,较双路8核平台提高了17%。进过分析,造成这种情况的原因应当是因为减少了两颗处理器间经北桥进行Cache同步这一步骤。
当然,路由与包过滤防火墙只代表一类特殊的业务模型。真实情况中,大量上层应用对CPU运算性能的要求要远远超过I/O,它们能否发挥出多路多核平台的真实性能呢?联想到很多用户都使用配置较高的服务器搭配Snort进行入侵检测,我们也搭建了这样一个测试环境。为了加大系统的运算负载,还特别加载了包含超过一万条规则的海量特征库,并关闭了日志输出。由于该软件启动时必须指定监听网口,所以系统内同时运行着两个Snort进程对接收到的报文进行检测。
我们使用SmartBits向服务器两个网口发送了64字节千兆线速流量,结果与预先猜测有很大差异:8个核中的4个近乎闲置,另有两个核在满负载处理网卡接收的报文,其余两个核的资源全部被Snort使用。即便是这两个核,分配给Snort做入侵检测业务的资源也不超过50%,其余都被系统(Libpcap)占用。从统计信息来看,60秒内SmartBits共向服务器发送了178571424个报文,网卡只接收了25874265个,Snort则仅处理了19474212个。也就是说,网卡本身就不能实现线速收包,加上snort又不能很好地利用多核资源,导致收下来的报文也不能全部进行检测,真正经过识别的仅占11%。
测试进行到这里,已经可以得到比较明确的结论:至少在与网络相关的部分业务中,现有的多路多核服务器平台并不能发挥100%的性能。并且,这次测试也印证了我们曾经对某些脚本成绩不正常原因的推断。目前来看,系统软件默认协议栈并行化方面的效果是比较失败的,至少我们测试过的64位Windows2003、Windows2008、Windows7和Debian Linux 5也同样存在这个问题。
就在验证测试后的不久,华为技术有限公司送来的一块智能网卡引起了我们的注意。这个代号为inic1000的产品声称可以有效解决I/O处理带来的高昂系统开销,使服务器真正表现出应有的功效。该网卡采用全高设计,使用PCI-E 4x进行连接,提供了4个千兆接口。虽然网卡主芯片上覆盖有散热器,但在实际使用中的温度并不高。我们用转接卡插在1U服务器中,直接合盖进行长时间测试,散热器表面温度也没有明显上升。
这是一块拥有很强处理能力的网卡。通过配置,智能网卡可工作在normal和rule两种模式。前者的功能主要是标准的数据接收、上报以及转发,后者则在此基础上实现了规则过滤特性。为保证兼容性,iNIC1000智能网卡的驱动提供了公开的API供应用程序调用,也有华为官方提供的Libpcap库可供选择。用户可以根据自身应用需求,选择合理的部署方式。
在对技术思路有了充分了解后,我们马上开始着手验证产品的实际效能。为方便进行对比,测试环境依旧沿用了之前的软硬件平台。对于包过滤防火墙这种应用来说,iNIC1000智能网卡在rule模式下的接收、规则过滤与转发特性已经可以独当一面。实际上,在主机上的操作也只是智能网卡过滤与转发策略的配置,并未用到系统自带的功能。我们使用SmartBits发送了双口双向64字节线速流量,这次的吞吐量基本达到100%,系统资源占用率却接近0。也就是说,包过滤防火墙的任务完全由智能网卡承担,服务器可以腾出更多的资源处理业务。
为了验证这一点,我们将网卡的工作模式改为normal,将上报队列的数量设定为与服务器平台处理器核数一样的8条,进行了针对Sonrt应用的测试。由于Snort需要借助Libpcap捕获报文,正好也可以考察一下iNIC1000智能网卡对原有应用的兼容性。操作方面我们没感觉到什么难度,不同的数据队列在系统中被映射为传统网络适配器加子接口的形式,用户使用时可以维持原有的操作习惯。
这次的测试结果较板载网卡大为改观,从最终统计来看,60秒内智能网卡接收上报的报文数与Snort累计处理的报文数均为178571360,做到了2Gbps(2.96Mpps)流量的线速接收上报与检测。8核平台的计算能力也终于有了用武之地,流量负载均衡到所有处理器后,平均CPU占用率还不到10%。
2Gbps的流量看来远未到达测试平台的最大处理能力,我们随即使用了全部4个接口进行了测试。在4Gbps的64字节单向线速流量(5.2Mpps)压力下,iNIC1000智能网卡依旧可以做到不丢包接收,并相对均匀地分队列上报给不同处理器。系统中运行的8个Snort进程也顺利完成了对357143108个报文的检测,此时CPU综合占用率也还不到40%。
测试后记
网络瓶颈亟需重视
对比服务器板载网卡与智能网卡的测试结果,差距之大,令人感慨。相对于硬件平台计算能力的迅猛提升,网络控制器在功能特性与处理流程方面却缺少革命性的改变,以至于逐渐成为系统性能的短板。业务应用的网络化趋势是不可逆转的,从小机房到大型数据中心,服务器之间以及与存储、网络设备之间越来越多地采用高速以太网进行连接,系统协议栈的瓶颈严重制约了整体性能。所以对于那些应用受限的用户来说,当你们计划升级服务器,乃至添购新服务器和昂贵的负载均衡设备前,请先想一想,现有硬件环境是在用100%的资源处理业务么?