《给力吧,x86》专题连载六:网络通信硬件平台巡览•D525篇

在上一期连载内容中,我们测试分析了目前主流的G41网络通信硬件平台。结合其价格定位与性能表现来看,该平台比较适合用来打造中低端产品。而在更低端一些的,也是出货量最大的领域,来自英特尔的Atom平台才是毫无疑问的王者,堪称x86架构真正的杀手级解决方案。

在本系列第三篇连载内容中,我们曾经提到协助北京市某学校信息中心的老师们进行过一次选型测试。当时,该校供应商提供了一款基于Atom N270的网络通信硬件平台,在部署为流控服务的情况下达到小包接近900Mbps、大包超过2Gbps的处理能力(使用4个英特尔82574L提供的千兆接口进行测试)。而本次我们的测试对象,是汇尔科技提供的一款基于Atom D525的网络通信硬件平台。与N270相比,D525平台处理器主频更高、计算能力更强,成本却没有太多增加,已成为时下低端领域最主流的选择。

架构精简 配置合理

IEC-516P采用1U规格设计,前面板提供了6个千兆电口(其中两组支持硬件ByPass)、两个USB 2.0接口和一个DB9或RJ45形态的串口。该产品采用了英特尔Atom平台,基于45nm的Atom D525处理器,隶属于PineTrail架构。比起第一代Atom平台,PineTrail从三芯片改进为双芯片设计,在CPU中集成了北桥芯片的部分功能。Atom D525处理器主频为1.80GHz,采用双核四线程设计,集成2 x 512KB L2 Cache,提供了不错的处理能力。其实Atom处理器内核采用的顺序执行机制对于网络业务处理来说并不太合适,双核四线程的D525处理器比起上一代单核双线程的N270会有更大的优势。D525处理器还内置了内存控制器,支持单通道的DDR3-800或DDR2-800内存,最大容量可达4GB。IEC-516P提供了两条DDR3 SO-DIMM插槽,送测样机配备了1条1GB的DDR3内存。

按照英特尔PineTrail平台的规划,D525应该搭配NM10芯片使用,然而NM10仅提供4个PCIe Lanes,限制了通信产品的整体处理能力和部署的灵活性。所以在嵌入式产品线中,英特尔给出了D525与ICH8M的推荐配置。ICH8M可以提供6个PCIe Lanes,以及PCI、IDE、SATA等丰富周边I/O接口。和上一代产品ICH7相比,ICH8比较明显的区别是它支持PCIe v1.1,因此可以支持包括MSI-X在内的一系列新特性。而和面向桌面应用的ICH8相比,面向低功耗移动应用的ICH8M将支持的SATA端口数减少到3个,功耗也有所降低。其实ICH8M内部还整合了1个千兆网络控制器的MAC部分,但其性能无法满足压力较大的网络业务处理,所以包括IEC-516P在内的许多网络通信硬件平台都对其进行了屏蔽处理,转而使用功能、性能更强的独立网络控制器。

IEC-516P通过ICH8M南桥的6个PCIe v1.1信道分别连接到6颗82574L芯片。82574L是沿用已久的嵌入式/服务器千兆以太网控制器,支持两个TX/RX队列和两个RSS队列,是一个成熟稳定、性能尚佳的产品。该芯片使用PCIe v1.1 x1接口,能支持MSI-X等技术,在规格上正好与ICH8M相匹配。ICH8M和Atom D525通过DMI总线连接,实际上就是一个x4的PCIe总线,其单向信号速率/双向信号速率为10Gbps/20Gbps,数据速率则为8Gbps/16Gbps。

在机箱内部,IEC-516P为TDP并不高的Atom D525配备了一个小风扇,并将其安置在机箱出风口的两个风扇附近,因此散热方面完全不成问题。由于整机功耗较低,该产品使用1个180W功率的电源为系统供电,整机功耗不会高于100W,因此180W已经绰绰有余。可靠性方面,IEC-516P内置了支持可编程控制的WatchDog,完善了x86平台的监控机制。存储方面,主板上提供了1个IDE接口和3个SATA接口,可以使用DOM、CF及其他常见的存储介质。送测样机配备了CF接口、IDE界面的1GB DOM,用于安装NCPBench。此外,主板边缘还设计有1个PCI插槽和1个PCIe x1接口的金手指,提供了符合产品定位的扩展性。

性能卓越 低端通吃

考虑到性能数据的可比性,我们依旧使用了NCPBench 0.8对IEC-516P进行测试。按照该软件设定的评估方法,我们将每两个相邻接口配置为桥模式,分别多次考察了1组、2组、3组桥时的整体转发性能,取得稳定后的性能数据(NCPBench的功能介绍和使用方法见本报今年第16/17期51版)。由于IEC-516P只提供了6个千兆接口且不可扩展,在测试3组桥性能时,我们直接将显示器、键盘鼠标插在主板上引出的接口上进行操作。

测试项·配置

帧长度

1组桥

(100%=2Gbps)

2组桥

(100%=4Gbps)

3组桥

(100%=6Gbps)

64 Byte 58.827% 59.475% 40.394%
128 Byte 60.325% 60.582% 45.765%
256 Byte 77.228% 76.136% 53.960%
512 Byte 89.672% 86.620% 59.600%
1024 Byte 97.784% 91.375% 61.583%
1280 Byte 100% 93.207% 62.276%
1518 Byte 100% 94.288% 62.732%

表格:IEC-516P吞吐量测试结果(百分比形式,NCPBench 0.8/转发模式)

测试项·配置

帧长度

1组桥

(100%=2Gbps)

2组桥

(100%=4Gbps)

3组桥

(100%=6Gbps)

64 Byte 1.18Gbps 2.38Gbps 2.42Gbps
128 Byte 1.21Gbps 2.42Gbps 2.75Gbps
256 Byte 1.54Gbps 3.05Gbps 3.24Gbps
512 Byte 1.79Gbps 3.46Gbps 3.57Gbps
1024 Byte 1.96Gbps 3.66Gbps 3.69Gbps
1280 Byte 2Gbps 3.73Gbps 3.74Gbps
1518 Byte 2Gbps 3.77Gbps 3.76Gbps

表格:IEC-516P吞吐量测试结果(带宽形式,NCPBench 0.8/转发模式)

测试项·配置

帧长度

1组桥

(100%=2Gbps)

2组桥

(100%=4Gbps)

3组桥

(100%=6Gbps)

64 Byte 1.75Mpps 3.54Mpps 3.61Mpps
128 Byte 1.02Mpps 2.05Mpps 2.32Mpps
256 Byte 0.70Mpps 1.38Mpps 1.47Mpps
512 Byte 0.42Mpps 0.81Mpps 0.84Mpps
1024 Byte 0.23Mpps 0.44Mpps 0.44Mpps
1280 Byte 0.19Mpps 0.36Mpps 0.36Mpps
1518 Byte 0.16Mpps 0.31Mpps 0.31Mpps

表格:IEC-516P吞吐量测试结果(pps形式,NCPBench 0.8/转发模式)

从测试结果中可以看出,当NCPBench运行在转发模式时,IEC-516P的64Byte帧整机最大转发速率超过3.6Mpps,吞吐量达到2.42Gbps;采用1518Byte帧进行测试时,整机的最大转发速率为0.31Mpps,吞吐量达到3.76Gbps。由此可见,Atom平台虽然在网络通信领域被英特尔定位为低端嵌入式解决方案,却也有着不小的潜力。能在纯转发情况下达到这样的性能,也就意味着D525平台在运行一般的防火墙业务时,可以满足高端百兆乃至低端千兆产品的设计需求。或许,我们印象中“低端产品”的概念需要更新了。

通过挖掘,我们还能从有限的测试数据中捕捉到更多的信息。在1组桥和2组桥的测试中,除了前者在1280Byte、1518Byte时达到100%的极限值外,64Byte-1024Byte帧长有着基本相同的百分比数据(蓝色部分)。当我们将其转化为以带宽和pps为单位的数值时,可以看到2组桥时的处理能力基本是1组桥时的两倍,呈线性增长的关系。而在3组桥的测试中,64Byte-1024Byte帧长时的吞吐量数据并不存在这一规律,反倒是在1280Byte和1518Byte两种帧长时,3组桥的性能与2组桥基本保持一致,整体转发能力均为3.7Gbps左右(红色部分)。

要弄清造成这种情况的原因,我们必须深入了解D525平台做数据包纯转发时的业务流程。以IEC-516P为例,D525处理器通过4x DMI通道连接到ICH8M,后者再通过6条PCIe v1.1 1x通道连接板载的6颗英特尔82574L千兆以太网控制器。通常在进行数据包转发操作时,网络控制器先发起DMA请求,将接收缓存中的数据直接传输到内存;CPU经过软件处理定位到目的网络控制器,通过DMA引擎将数据传输到它的发送缓存中,或是让网络控制器自行将数据从内存中取走(82574L整合了DMA引擎)。这是一个逻辑上简单、实现起来复杂的流程(如果要达到高性能),内存子系统、DMA引擎、DMI、ICH8M、PCIe 1x通道、82574L和软件、驱动程序都有可能成为影响整体性能的因素。

再回到我们刚才注意到的两个情况,既然1组桥和2组桥时,64Byte-1024Byte在带宽和pps测试结果上呈线性增长,说明瓶颈不在内存子系统、DMA引擎和DMI。而我们在测试其他更高规格的平台时,基于82574L也得到过更高的性能数据,说明这款网络控制器和PCIe v1.1 1x通道也不是瓶颈。只有在进行3组桥的64Byte-1024Byte帧长测试时,得到的数据才有可能是系统整体的极限。而2组桥与3组桥在1280Byte、1518Byte帧长测试中表现出来基本一样的吞吐量数值,显然是在带宽方面遇到了瓶颈,但可能与DMA引擎、ICH8M、PCIe v1.1 1x通道和82574L关系不大。我们暂时无法再对性能短板做更加精准的定位,不过从完整的测试数据来看,DMI、内存控制器与软件处理逻辑有可能是造成D525平台整体性能瓶颈的关键因素。

无论如何,目前D525平台在NCPBench的驾驭下,已经有着十分优秀的性能表现。随着厂商研发的继续深入和软件技术的不断发展,该平台的性能一定会得到更充分的挖掘,在低端网络通信、信息安全领域有着很好的应用前景。

(4个打分, 平均:3.25 / 5)

《给力吧,x86》专题连载五:网络通信硬件平台巡览•G41篇

子曰:工欲善其事,必先利其器。在上一期连载中,我们介绍了新兴的网络通信平台评估软件NCPBench。从本期开始,我们将陆续测试一批网络通信硬件平台,看看在优秀系统软件的支撑下,x86架构究竟有着怎样的性能,以及不同硬件配置对网络处理能力造成的影响。

价格不是最高也不是最低,规格不前卫但也不落伍,这就是G41,我们今天的主角,英特尔嵌入式产品线中在网络通信市场上拼杀的绝对主力。而它的载体,是台湾伯昇科技股份有限公司推出的一款网络通信硬件平台,代号NSP-1096。这款产品采用1U规格设计,前面板提供了6个千兆电口、2个USB 2.0接口和一个9针串口。接口左侧设有附带按钮的液晶屏,右侧空间则留给了扩展槽位。伯昇科技为NSP-1096准备了多种规格的扩展卡,用户可以用来为硬件平台添加多达4个千兆接口。

合理的配置与设计

打开NSP-1096的机箱上盖,可以看到处理器所在位置做了有针对性的设计。NSP-1096没有使用处理器散热风扇,而是采用了一个较大型的铜质散热器,通过特别制作的导流罩,配合机箱风扇形成一个专门风道,给CPU、内存条以及北桥芯片散热。风道两侧是磁盘悬挂位和电源,该产品配备了全汉的80Plus电源,让NSP-1096在所有的工作负载时间内都能维持较高的电能转换效率,降低了发热量以及其散热需求。

NSP-1096采用了专门为嵌入式平台设计的英特尔G41芯片组,和ICH7/ICH7R南桥芯片搭配使用。作为系统的核心,G41连接着处理器、内存和PCIe总线。它支持1333MT/s的FSB,可以兼容嵌入式产品列表内LGA775接口的各种赛扬、酷睿处理器;内存规格则支持到DDR2-800和DDR3-1333,且拥有两个内存通道,最大容量达到8GB。I/O方面,G41提供了16个PCIe v1.1信道,可以配置为1×16或者2×8;此外,通过DMI 1.0总线和G41连接的ICH7R南桥还能提供6个PCIe v1.0a信道。在NSP-1096上,这6个信道连接了6颗英特尔82754L网络芯片(对应前置接口,其中2组支持硬件ByPass);G41提供的PCIe v1.1 x16则连接到扩展槽位,用以连接使用了82576、82580等中高端网络控制器的扩展模块。

NSP-1096内置的6颗82574L芯片是沿用已久的嵌入式/服务器千兆以太网控制器,支持2个TX/RX队列和2个RSS队列,是一个成熟稳定、性能尚佳的产品。该芯片使用PCIe v1.1 x1接口,能支持MSI-X等技术。不过由于连接在支持PCIe v1.0a的ICH7R上,它仅能使用传统的MSI模式。扩展模块上应用较多的82580则是英特尔最新推出的单芯片四网口千兆以太网控制器,采用了支持5GT/s速率的PCIe v2.1 x4接口,支持包括LTR、TPH、DCA等在内的诸多特性。面向网络通信、主流服务器和高密度刀片的82580是十分强大的芯片,其规格甚至比上一代的王者82576还要强一些。

测试使用的这台NSP-1096还配备了一颗主频为2.66GHz的英特尔Q9400处理器,该处理器使用45nm工艺设计制造,具有4个核心和6MB二级缓存。内存使用了2根DDR3-1333规格、1GB容量的产品,工作在双通道模式。网络接口方面,除了板载的6个千兆铜口,我们还在扩展槽位安装了一块编号为BEM-580-F4的扩展卡。该卡使用了一颗英特尔82580网络控制器,提供4个额外的SFP接口。不过,理论上该芯片在连接到G41的PCIe v1.1后速率将降为2.5GT/s,功能特性也只有包括MSI-X模式在内的v1.1部分可以使用。

整体性能超越预期

在CF卡中安装了NCPBench 0.8后,我们将每两个相邻接口配置为桥模式,进行纯转发性能与带简单业务情况时的测试(NCPBench的功能介绍和使用方法见上一期连载内容)。对于NSP-1096来说,BEM-580-F4扩展模块在很大程度上左右着整机的处理能力,我们也对其进行了重点考察。考虑到是第一次在这样的配置场景中进行测试,每个项目在使用测试仪表进行测试后,都再使用NCPBench进行一次自测试。我们可以对比两组数据的差异,用以评估NCPBench测试结果的准确性。

从测试结果中可以看出,当NCPBench运行在纯转发模式时,BEM-580-F4扩展模块上的4个接口转发64Byte帧的速率超过4Mpps,其他帧长时均接近或达到线速。这个结果虽然出色,却使人略感遗憾。我们曾经在一台采用5520芯片组的硬件平台上,测得过82580的4个接口间所有帧长均线速转发的结果,也就是说瓶颈不在网络控制器。而对NSP-1096全部10个千兆接口的测试结果表明,该产品对64Byte帧的整机转发能力接近9Mpps,这又意味着,之前测试中的性能瓶颈也不应该在处理器。经过排除分析,我们推测问题很可能来自I/O方面,理论上G41与82580协商后只能使用PCIe v1.1规格进行连接,在传输速率和效率上都大打折扣。此外,硬件平台在缓存和内存等方面的差异,也可能会对数据包转发能力造成一定影响。不过总体来说,NSP-1096的设计已经最大地发挥了G41芯片组的潜能,表现出来的整体性能也超越预期,足以满足其目标市场的需求。

本次测试中,测试仪与NCPBench得到的两组结果保持高度一致,我们只在高负载情况下观察到pps统计数值略有不同,没有出现往常几个百分点级别的差异;加载简单业务后,性能数据也没有发生很大变化,只在使用128Byte帧长测试时有所降低。我们认为,造成这两种情况的主要原因是处理器本身有性能余量,接口带宽也限制了极限数据的出现。单就NCPBench来说,其自测试结果还是比较准确的,可以满足用户的常规测试需求。

测试项·配置

帧长度

转发

(100%=4Gbps)

转发+业务

(100%=4Gbps)

测试仪 NCPBench 测试仪 NCPBench
64 Byte 67.773% 67.773% 67.773% 67.773%
128 Byte 96.143% 96.143% 93.707% 93.707%
256 Byte 100% 100% 100% 100%
512 Byte 100% 100% 100% 100%
1024 Byte 100% 100% 100% 100%
1280 Byte 100% 100% 100% 100%
1518 Byte 100% 100% 100% 100%

表格:NSP-1096吞吐量测试结果(针对BEM-580-F4扩展模块)

(2个打分, 平均:3.00 / 5)

《给力吧,x86》专题连载四:网络通信平台评估软件NCPBench应用分析

x86网络通信硬件平台的迅猛发展,已经吸引了许多厂商、用户的关注。在进行评估测试时,如何才能准确、便捷地了解硬件平台的整体性能,是所有人都关心的问题。本期,就让我们聚焦于新兴的评估软件NCPBench,感受一下它诸多与众不同的特性。

在上一期连载中,我们介绍了与北京市某学校信息中心合作进行的一次硬件平台选型测试,并以此为依据,证实了x86平台在网络业务处理方面的潜力。随后一段时间内,我们收到了许多来自厂商、用户的咨询;个别用户甚至愿意提供更完善的环境,希望我们将这一系列测试长期进行下去,持续公开更详细的测试结果。对于来自读者的热情关注,我们表示感谢,并将在后续连载中安排更多平台的测试分析。同时,我们也在这里介绍一款经常使用的网络通信平台评估软件NCPBench,供读者进行独立的性能评估。

以互联网的名义

NCPBench是近期兴起的一款测试软件,用于评估x86硬件平台做网络业务处理时的性能。在我们看来,该软件融入了大量的互联网基因,与日常使用的诸多软硬件评估产品有着明显的不同。众所周知,用户参与是互联网产品成功的基本要素,NCPBench显然抓住了这个要点,在产品发展的方向性上与用户需求保持着高度一致。该软件采用了十分开放的构建模式,版本升级比较迅速。与之对应的,在主要功能保持稳定的情况下,再根据用户反馈需求的迫切性,逐步完善产品的细节功能。而互动的效果则取决于用户数量与质量,所以NCPBench本着“让更多人使用”的理念,采用了免费的许可授权模式,允许甚至鼓励被用于包括商业在内的各类评估环境。

NCPBench与其他软硬件评估产品的第二个不同,体现在操作的便捷性方面。一般来说,网络通信、信息安全等领域的测试解决方案都比较复杂,使用时需要较高的专业素养,配置过程也相对麻烦。NCPBench则很好地简化了用户端的工作,使用时只需对网络接口、业务模式等几个必要环节进行设置,即可进行性能测试。一键式安装也是非常实用的功能,我们拿到新的硬件平台,用几分钟时间就可以将NCPBench安装到本地或USB存储设备上,而不必经历从磁盘分区到编译的诸多步骤。该软件还内置了常见的硬件驱动,在多数平台上可以直接发挥出硬件的所有潜力。

利用NCPBench,我们可以评估任何x86平台的网络业务处理能力。现阶段该软件提供了“转发”与“业务”两种应用模型,前者不对数据包进行任何处理,考察的是硬件平台的数据包转发极限;后者将建立数据流的概念,其业务复杂度与NAT、状态检测引擎类似。通常,我们会测试x86硬件平台在两种模型下的吞吐量与延迟,当然这些结果都是理论值,仅供评估参考。根据经验来看,设备在真实流量下的综合效能,如果能达到模拟测试环境中的50%,就已经相当难得了。不过“转发”模型下的性能还是很重要的,毕竟对于没有任何加速逻辑的x86平台来说,数据包纯转发的性能是一个极限标杆。没有高性能转发做支撑,任何上层业务都将是纸上谈兵。

高性能的诱惑

众所周知,目前x86平台用做网络业务处理时,首先要解决的就是多个处理器内核间的调度与资源分配问题。如果使用传统的处理模型,很可能导致资源使用的不平衡,无法发挥出硬件平台的整体性能;而多核并行处理的模式,虽然在理论上可以提升性能,实际使用时的效果却大多难令人满意。NCPBench在这方面就显得非常灵活,用户可以人为设定用做转发及业务处理的内核数量,并且转发与业务在每个独立内核上也都是并行处理,系统呈纯SMP形态。该软件也不像某些同类产品那样必须人为地将网络接口与处理器内核进行绑定,而是根据硬件平台配备的接口种类及数量,自动建立关联关系。

经过多次测试,我们已经确认NCPBench在x86平台上可以做到非常强悍的数据包转发性能。现有测试数据中,64byte UDP数据包的最大转发速率接近30Mpps,是在英特尔Sandy Bridge搭配i82599万兆网卡的平台下测得。此时使用RFC 2544规定的7种帧长的数据包测试转发延迟,时间也均在10微秒以内。这意味着,x86平台用做20G/40G环境中的业务处理,并非是遥不可及的目标。需要注意的是,x86平台所能达到的的数据包转发能力与处理器、桥片、网卡芯片等都有很大关系,如果在硬件规格上无法很好地匹配,性能瓶颈就会过早地出现。我们发现,网络通信硬件平台大多经过有针对性的定制,硬件搭配相对合理;服务器的配置则大多是计算远强于网络,很可能要另行采用高性能网卡以达到更快的转发速度。

为了让用户更方便地了解x86硬件平台的网络处理性能,NCPBench还内置了一个自评估工具。该工具的使用极其简单,只需用网线将要测试的接口两两互联,就可以在环路内生成指定帧长、方向、强度的UDP测试流量,对硬件平台自身进行测试。我们注意到,在多数情况下,使用自评估工具得到的性能值都较测试仪得到的略低,但观察到的最大一次误差也仅在3%以内,还是具有比较强的参考价值。

(1个打分, 平均:4.00 / 5)

《给力吧,x86》专题连载三:x86平台网络应用效能实测

弯曲评论现在的影响力很大,甚至能吸引到一些行业用户的关注(潜水居多)。本文就是《给力吧,x86(1)——11月10日测试记录》一文刊登后,用户直接与我们沟通进行的一次测试合作的副产品。这是一个良好的开端,后续还有与其他用户联合进行的更大、更深入、更给力的测试,敬请关注。

==============================================================

前两期连载中,我们简单回顾了x86平台在网络产品中的应用历程,又逐一分析了其面向不同用户群体的硬件供应模式。实践是检验真理的唯一标准,本期就让我们走进现实中,借助近期的一次测试,看看在网络技术及应用高速发展的今天,x86平台对业务的承载能力究竟如何。

虽然一些业内人士已经看到x86平台的发展,认为其将在网络领域有所斩获,但对于普通用户来说,再次接受x86平台有着很大的难度。一方面,这个曾经不太适合做网络业务处理的硬件平台为许多用户留下过不好的应用体验;另一方面,一些厂商长期对x86架构并不客观的宣导,也加深了其在用户心中的负面印象。

先入为主的误会

我们在之前的调研中发现,抱有这种看法的用户并不在少数。北京市某学校信息中心负责人李老师就是一个典型代表,虽然他在目前进行的流控产品选型中比较中意连续两年获得计算机世界年度产品奖的Panabit应用层流量管理系统,却因其运行在x86平台上而犹豫不决。

“我们一直用着一台x86架构的UTM产品,效果越来越不好。”李老师介绍说,“以前网络负载不大时,设备运行没有任何问题;现在越来越多的教学、科研任务要通过网络进行,学校网络出口的百兆带宽经常被占满,UTM运行也变得不稳定。”令人没有想到的是,他紧接着又说出一个令我们很难理解的结论,“看来,x86平台也就是这个样子了。”

x86架构与网络运行不稳定有直接关系?实验室工程师习惯以量化的数据去看待问题,自然无法认同李老师的推断。在他的协助下,我们走进该校信息中心,对网络运行情况进行了实地考察。经过分析,我们发现造成学校网络出口拥塞的主要原因大致有三:其一是在线课件播放系统产生的数据流量,由于学生分布在不同校区,远程教学会在上课时段对网络造成比较大的压力。其二是学校周边视频监控的数据上传流量,根据教委要求,为加强校园安全工作,各学校的视频监控数据需实时汇总到教委信息中心,以便对突发事件做到事前预警、事中监控及事后取证。李老师所在的学校需要实时上传4路监控视频,这也是该校网络上行带宽占用率居高不下的原因之一。其三则是P2P、在线视频等非业务应用产生的流量,此类应用会无限制地占用网络带宽,是每一个网络管理员都非常头疼的问题。我们在分析报表中看到,以迅雷为代表的下载应用在网络使用高峰期一度抢占了70%左右的带宽,严重影响了该校教学工作的正常开展。

根据分析得到的数据,我们建议李老师对UTM上的安全策略进行了调整,不再对远程教学与视频监控相关的流量进行应用层面的安全防护。由于它们都是可信流量,修改过的访问控制策略非但不会造成安全隐患,还能有效降低UTM的负载。很快,我们看到设备的CPU占用率显著下降,内网用户访问网络的延迟也回到相对合理的水平,x86“不行”的误会也就此得到解除。但对于非业务流量的控制需求,该校主出口使用的这台国外某品牌的UTM产品并没有足够的本土化保障,对国内主流应用的支持力度相对薄弱,无法进行有效的控制。可以说,流控产品的部署势在必行。

标前测试:大放异彩

虽然解决了UTM运行不稳定的问题,李老师所在的信息中心管理团队还是对x86架构产品存有疑虑,不愿直接将设备接入实际环境进行测试。这一点大家都能理解,毕竟学校网络承担着大量的教学、科研任务,万一出现意外,后果将不堪设想。在我们看来,李老师所在团队目前所需要的,是一次客观、严谨的标前测试。实际上,这一环节已经被国内越来越多的用户所认可,因为是否选购产品,或者是否再接入实际环境测试,都可以用标前测试得到的量化数据作为决策依据。

在实验室合作伙伴思博伦通信的支持下,我们与李老师所在团队合作,于近日测试了他们关注的Panabit应用层流量管理系统。该产品运行在x86平台上,拥有优秀的协议识别率及性能。商务模式方面,Panabit可以通过软件授权或服务的形式进行交付,给用户自行选择硬件的自由,还可以节省大量开支。李老师这次带来的硬件,就是供应商基于该校网络实际情况,推荐的一款带有6个千兆电口的基于Atom N270的x86网络通信硬件平台。

Atom N270?实验室工程师们感到难以置信。要知道,流控引擎是在DPI(Deep Packet Inspection,深度包检测)的基础上结合多种技术发展而来,属于处理模型相对复杂的一类业务应用,对硬件平台的计算能力有着相当高的要求。而Atom N270是什么级别的产品?放在上网本里也算是两代之前的配置了,它真能满足百兆级别应用层流量管理的需求?

诸多疑问化作动力,催使我们立即开始了测试。被测设备预装了Panabit 10.10专业版,开启了应用层流量分析,作用于4个千兆口绑定成的两组桥。根据联合制定的测试方案,我们首先对带业务情况下的吞吐量、延迟进行了测试。虽然常用的UDP测试流量对于IPS、WAF等应用层安全设备来说意义不大,对流控产品测试却有着十分现实的意义——据统计,目前互联网中占流量比例最大的是在线视频应用(在教育、网吧等行业中比例数字更为惊人),它们其中大多数都使用了UDP传输,且数据包偏小。测试结果令人震惊,当我们单独测试1组桥的性能时,该平台64Byte帧的吞吐量达到41%,也就是800多兆的处理能力。当帧长逐渐增加时,吞吐量也呈线性增长,并在1518Byte时达到线速。此时最大的平均延迟,也仅为68微秒。而在同时对2组桥的测试中,设备的整体吞吐量又有所增加,在256Byte时就已拥有接近2G的性能。我们也利用全部4个接口测试了该产品的链接处理能力,当链接的Timeout时间设为0时,Avalanche测得的稳定值在90000左右,峰值为90014CPS(HTTP)。这一次的数据体现出了设备的极限性能,根据以往经验,其表现完全可以胜任普通千兆接入环境中的应用。

测试项·配置

帧长度

2个GE做1组桥

(100%=2Gbps)

4个GE做2组桥

(100%=4Gbps)

吞吐 平均延迟 吞吐 平均延迟
64 Byte 41.19% 24 us 22.28% 34 us
128 Byte 54.42% 24 us 37.37% 38 us
256 Byte 67.65% 24 us 48.08% 42 us
512 Byte 82.10% 37 us 52.35% 42 us
1024 Byte 92.02% 76 us 53.38% 54 us
1280 Byte 95.58% 64 us 55.37% 58 us
1518 Byte 100% 68 us 56.92% 68 us

有了这些测试数据,老师们基本放下心来,将设备接入实际环境中进行了长时间的测试。对于流控设备上线后的效果,李老师给予了充分的肯定:“业务流量控制住了,学校网络出口的流量也就下来了,UTM的负载就更小了。”而在稳定性方面,他也坦言没有遇到过任何异常情况,不过我们仍然建议做更长时间的测试,以便进一步考察x86网络通信硬件平台长期不间断运行的效果。

后记:广阔天地 大有作为

从测试结果中可以看出,x86平台的网络业务处理能力确实有了长足的进步。目前,在英特尔面向网络应用的嵌入式产品线中,Atom N270是最低端的一款产品,都有着如此强大的处理能力。随着网络通信和信息安全业务的关注点逐步向应用层迁移,x86平台的优势将会越来越明显。当然,现有基于x86架构的产品仍不足以在高端市场和基于专用网络通信处理平台的产品竞争,但在其他诸多领域内,x86已经表现出了一定的竞争力。对开源系统良好的支持、海量的软件资源、较低的开发难度、价格优势和易获取性,这些都是其取胜的砝码。是否有点眼熟?没错,如果哪天基于x86架构的网络通信和信息安全产品(至少是中低端)开始山寨化,大可不必感到奇怪。

(1个打分, 平均:5.00 / 5)

《给力吧,x86》专题连载二:x86平台在网络领域的发展应用分析

上一期,我们系统地回顾了x86平台在网络产品中的应用历程,得出了其目前处于高速发展中的结论。越来越多的设备制造商也认识到这一点,开始在产品的研发中考虑x86平台。那么,自主研发硬件与定制网络通信硬件平台,究竟哪条路更适合设备制造商?x86服务器缘何又受到最终用户的青睐?

得不偿失的自主研发

自主研发是产品核心竞争力的基础,网络领域也不例外。对于网络设备的硬件部分来说,自主研发意味着差异化、定制化和成本的可控性。这既可以与业务高度匹配,又能取得技术、规格与价格上的优势,是每个厂商都梦寐以求的局面。

但真要做到全部自主研发,却也未必就是好的选择,甚至不太可能。自主研发需要投入大量人力物力,且有着相对较长的时间周期,这是大量初创企业乃至市场规模较小的安全厂商很难接受的。如果自主研发的硬件平台存在瑕疵,其代价将更为惨重,厂商损失的不再只是前期投入,而是转瞬即逝的市场机会。所以,通常只有通信行业的巨头才会去押宝硬件平台的自主研发,更多地体现技术上的壁垒,且在预研阶段不会拘泥于某种特定的方案。

此外,x86平台一些不可磨灭的消费类特性,也是阻碍网络设备制造商实现自主研发的关键因素。虽然嵌入式范畴内的x86平台也拥有了较长的生命周期,CPU、桥片、网络控制器的种类却偏多,更新换代的速度又比较快,且不同时代、不同桥片对应的CPU针脚都不是100%兼容。相信没有一个网络设备制造商可以跟得上这种更新速度,我们在长期的测试工作中,也确实没有见到过哪款通信或安全产品是采用自主研发的x86平台(少量定制型号与CheckPoint除外)。大家共同的选择,还是定制化服务器或由工控机衍生而来的x86网络通信硬件平台。

服务器:近水楼台先得月

既然x86平台以通用性为主打,那么注定其在市场等非技术层面更具竞争力。以服务器为例,采用x86体系架构的产品在价格、性能和易获取性方面都有着明显优势,占据了绝对主流的市场地位。近几年来,x86架构服务器在网络处理能力和I/O特性方面有着显著提升,标配4个千兆网口的产品也屡见不鲜。更有甚者,一贯拥有良好前瞻性的英特尔将于今年发布标配2个万兆网口的新服务器平台,会将网络应用效能提升到一个新的高度。

基于以上多种原因,越来越多具有一定研发能力的用户开始采用唾手可得的x86服务器来打造适合自身应用的网络设备。尤其在电信、金融、教育等行业,用户业务本身存在比较强的定制化需求,性能要求又相对较高,故此类情况时有发生。在我们的调研中,就出现了一些具有代表性的案例。上海交通大学网络信息中心的姜开达老师曾坦言,两年前该校在对校园网出口入侵检测系统的选型中,就遇到了市售产品难以满足需求的窘况。在充分分析了业务需求的前提下,姜老师选择了带领团队自行研发的方式,以多组x86服务器分布式处理的方式实现了对万兆链路的实时监测。这一举动,不仅构建了一个开放的、可以承载多业务的科研平台,更将科研成果转化为实际的安全服务,为校园网的稳定运行提供了保障。

许多数据都表明,面向网络应用的x86硬件平台的市场需求处于不断扩大的阶段,而服务器因其易获取性成为了用户的首选。网络产品本身也有着互联网化的倾向,以软件授权、服务为代表的商业模式剥离了传统软硬件一体化的产品形态,开始赋予用户自行选择硬件平台的权利。来自学术界的激进看法甚至认为,未来无论互联网还是数据中心,都将只由交换机和服务器两种硬件产品构成。

工控机的反击

x86服务器在网络领域的无心插柳,也刺激了传统的网络通信硬件平台提供商。他们开始推出有针对性的产品及商业模式,直接面向最终用户。我们在调研中发现,原本对新硬件方案不甚敏感的他们也逐步加速产品研发流程,主动接纳较新的x86平台,积极拓展产品线。对于用户在存储子系统方面比较普遍的应用需求,许多网络通信硬件平台提供商也开始在产品中增加硬盘位及相应的RAID特性。某些厂商还针对x86平台在硬件狗等方面的先天不足,以板载CPLD芯片等方式实现了强大的监控与联动能力。用户及设备制造商可以通过软件接口读取、调用这些功能,甚至基于CPLD自行开发其他监控手段,增强x86平台的可靠性。

与服务器相比,网络通信硬件平台有着一些无法被超越的优势。首先,它从内到外都可以由用户深度定制,无论是接口种类或数量,CPU、网络控制器的型号,还是PCB的板型及工艺,机箱规格及面板设计,都可以根据设备实现的业务进行最合理化的搭配。这种裁剪还降低了整机成本,也减小了系统功耗及散热难度。其次,可靠性在网络通信硬件平台的设计中至高无上,诸如网口的硬件Bypass等特性是绝大多数服务器产品无法提供的。而在元器件规格方面,多数网络通信硬件平台也都采用了比服务器更专业化、寿命更长、对工作环境要求更宽松的产品,使系统的稳定性有了更多的保障。虽然这一切都增加着硬件整体成本,所改善的却是网络产品必须具备的特性。所以,虽然销量巨大的服务器有着相对低廉的价格,但标准化的产品形态和对网络业务并不十分友好的支持,都使其在短时间内无法替代x86网络通信硬件平台。在网络通信硬件平台提供商逐步走向前端的今天,用户不妨在选型时也多给予一些关注。

(2个打分, 平均:5.00 / 5)

《给力吧,x86》专题连载一:x86平台在网络产品中的应用回顾

曾经在弯曲上发过两篇关于x86硬件平台的性能测试报告,还煞有介事地起了个《给力吧,x86》的专题名。后来决定将此内容扩大化、正规化,便专注于平面媒体的发布。直至今日,本专题已陆续连载了9期,从产业、产品、应用等方面比较完整地介绍了x86平台的现状,现整理发布于弯曲评论。专题的制作过程中,得到了很多朋友、同事鼎力协助,在此一并表示感谢。未来希望还能有机会把专题延续下去。

本专题内容原文刊登于《计算机世界》。水平有限,文中定有偏颇之处,希望弯曲网友不吝赐教。

==============================================================

x86,通用市场的王者,却在网络产品领域背负着诸多骂名。在与厂商、用户的交流中,计算机世界实验室的工程师多次听到“落后的产品架构”、“性能方面有致命缺陷”之类的评语。这些说法有无偏颇?x86平台是否真的不堪一用?本期开始,我们将通过技术分析与实际测试的手段,以专题连载的形式对x86平台用做网络处理时的性能进行细致的评估,努力梳理出一个客观的结论。

微博上流传着这样一则关于IT的冷笑话:“世界是你们的,也是我们的,但最终还是x86的。”的确,以英特尔、AMD为代表的x86阵营在通用市场长期占据着压倒性的优势,给许多用户留下了“电脑就是x86”的概念。而在相对封闭的网络产品领域,x86则远没有这么风光。此类设备要求硬件平台拥有高速I/O、对专有业务的加速能力和极高的可靠性,这些恰恰都不是x86的强项。所以,虽然x86平台在网络产品诞生之日起就在其中占据了一席之地,却一直处于非主流的地位。

不进则退

应该说,x86平台与网络产品结缘,开篇还是很美好的。在那个骨干网尚不如今天小区宽带接入速度快的时候,x86平台的网络处理能力完全可以满足要求。那个时候的x86 CPU和套片也没有如今恐怖的功耗和发热量,稳定性与PowerPC、MIPS架构的SoC平台在伯仲之间。真正有说服力的还是工业界对x86平台的广泛认同,作为当时的标志性产品,思科的PIX系列防火墙在网络安全发展史上有着很高的地位。即便是今天,在一些环境下依然能看到它的身影,可谓久经考验。

随着互联网技术的高速发展,网络产品很快遭遇性能瓶颈。不管是路由器还是防火墙,都面临着提升转发能力的迫切需求。恰恰在这个时候,x86开始了在通用领域的急速扩张,将性能改善的重点放在个人计算、企业计算乃至数字娱乐等方面,并不热衷于(也没有必要)对总线、I/O等方面进行有针对性的设计。在这种情况下,网络设备制造商开始尝试采用专用芯片对转发流程进行加速,通用处理器则只负责路由计算与查找、状态检测等计算密集型任务。这种做法虽然很好地解决了性能瓶颈,但在研发难度、制造成本方面的门槛却也相当高。为了满足市场需求,英特尔和IBM先后发布了被称为网络处理器(NP)的一系列产品。它们针对网络应用而设计,采用非x86内核+微引擎的设计思路,具有很高的转发性能和一定的编程能力,受到工业界的热捧。也正是因为它们的出现,使得孤木难支的x86平台与网络产品渐行渐远。

英特尔:史上最强亲友团

待到x86再次回归,已是近几年的事了。这次的需求主要来自信息安全领域,随着安全防护的重点由网络层向应用层迁移,硬件平台的计算能力逐渐成为网络设备制造商考量的关键因素。在计算机世界实验室测试过的非模块化安全产品中,只要涉及病毒过滤、入侵防护、协议识别等应用层功能特性,设备的整机处理能力一般都不会超过2Gbps。在巨大的计算压力面前,目前主流多核/众核网络处理器强大的I/O没有了用武之地。

英特尔显然也看到了未来网络产品乃至信息化的发展趋势,一直从系统体系结构、处理器结构(内存控制器、多核/多线程、专用加速指令/引擎)、总线类型(QPI、PCIe)、网络控制器(8257x/8258x/8259x)等方面加以改进,大力提升x86平台的网络业务处理能力。同时,该公司还重新着手完成网络领域的产业布局,让x86平台更具竞争力。英特尔长期对Linux的发展提供全方位的支持,去年又收购了在网络领域很有影响力的系统解决方案提供商Wind River,力图为x86打造足够完善的软件配套环境。这就像选秀节目一样,英特尔在x86平台参与的新一届网络产品选型大战中充分发挥了业界巨擘的实力与影响力,堪称史上最强亲友团。

从尾随到超车

目前来看,这个亲友团表现得相当有作为。主打中低端网络产品市场的Atom平台凭借不错的性价比,抢得了相当规模的市场份额。以国内首家推出Atom平台安全产品的网御神州为例,该公司2010年基于该平台产品的出货量就达5000台左右。另一方面,在Wind River Network Acceleration Platform等软件系统的支持下,高端x86平台的网络处理性能提升迅猛,国内也有多个研发团队实现了10Mpps以上的转发速度,在指标上已开始赶超同级别的多核/众核网络处理器。

解决了产品和配套方面的问题,并不意味着就万事大吉了。实际上,x86在网络领域,仍然面临着一定程度的产业生态环境不健全的问题。相传,华为当年历经千辛万苦,完成了基于英特尔奔腾处理器平台的路由器开发工作时,却被告知所采用的处理器即将停产退市,气得领导们发誓永不再采用x86平台进行开发。这个故事也许只是极端个例,但任何一个网络厂商,都不能容忍连产品备件都无法提供的供应链事故。那么,面向通用领域的x86平台更新速度越来越快,产品生命周期也越来越短,如何才能满足嵌入式形态的网络产品的供货要求?英特尔的解决办法是,在现有产品的基础上,针对嵌入式应用推出拥有长生命周期(7年)、工作环境适应能力更强的特殊版本,给设备制造商吃个定心丸。没有了后顾之忧,x86平台在与专用处理器的竞争中才有足够的资本。

(6个打分, 平均:4.83 / 5)

ISF2011邀请函

(没有打分)

曙光计划。Dawn。中文。

曙光计划[中文译本]

译者小序

本文是网上流传的《曙光网络》计划的中文翻译版本,译者是安天安全研究 与应急处理中心(Antiy CERT )的三位女性工程师。

我们看到此文时,便能感到其堪称同类文献的精品,我们希望从事恶意代码 分析、安全事件响应的同事们都能读到这样一份文档,从资料组织、互联网信息 检索、信息聚合、综合分析、图和表格的使用等很多技巧,以及综合全面的视野、 富有逻辑的推导等方面,都有很多的借鉴意义。

但我们有部分同事很少阅读外文文献,为此我们于是萌发了翻译的冲动。而我们特别认为,对很多长期只关注底层技术和分析方法,而忽略文档能力和系统 思维的同事来说,本文是一个很好的学习案例。

当然由于历史和文化的差异,对文中作为背景的事件的政治立场,可能仁者见仁、智者见智。但这些都不影响作为一份高质量的技术建议计划文献的学习价 值。

本文篇幅较长,翻译用时 30 多个小时,时间较为仓促。水平非常有限,可能有大量错误。希望大家理解。

感谢产品与项目管理中心-文档组的同事们提供中文版排版。为了便于对照 阅读,他们将翻译文档基本排版成了与原文风格完全一致的风格。

Antiy CERT Sunny、 Dirace、RorW 2011 年 6 月 17 日

(2个打分, 平均:4.50 / 5)