车库咖啡网络现状及改造建议

受陈首席委托,本人于5月17日对车库咖啡的网络部署情况进行了实地考察,总结了一些目前存在的问题,并给出改造建议。水平所限,文中定有不妥之处,还望各位弯曲网友多给把关,集思广益得到最合理的解决方案。

网络现状

车库咖啡采用8线ADSL接入,速度均为下行2Mbps/上行512Kbps,服务商为北京联通。(据创始人介绍,除联通ADSL外,车库咖啡所在建筑无其他互联网接入服务可供选择。)线路由图中所示B点入户,在A点与B点各放置了4台ADSL Modem,再由位于同一位置的4台路由器做PPPoE/NAT,其中包括D-Link DI-7200企业级上网行为管理路由器(最大支持4路WAN接入,使用3路连接ADSL)2台、Cisco/Netgear家用级无线宽带路由器各1台。

车库咖啡营业面积大约800平米,分为会议室、书房、大厅三大功能区。为实现全面的Wi-Fi信号覆盖,4台路由器LAN口又连接了若干家用级无线宽带路由器,当做AP使用;在大厅中部分区域,采用了无线网桥的方式拓展信号。整个车库咖啡共有4个SSID供顾客使用,它们彼此独立,无法实现无线漫游等特性。

现存问题

经过调查分析,车库咖啡网络目前存在如下比较明显的问题:

  • 网络割裂:缺少核心交换设备的车库咖啡网络被分割成孤立的4个区域,接入不同SSID的用户无法实现高速数据传输;接入资源也未进行聚合及统一调度,导致带宽利用率失衡。例如考察当天下午(非高峰时间),接入Netgear产品提供Wi-Fi服务的用户数量一度超过拥有3条ADSL接入的D-Link DI-7200,前者的2M下行带宽已满,后者仍有很大余量。
  • 应用流控失控影响网络使用体验:D-Link DI-7200具有一定的应用控制能力,也配置了屏蔽P2P下载的策略,效果却不尽人意。在使用迅雷下载热门应用时,3条ADSL的上下行带宽很快饱和,影响到其他顾客的上网体验。多数在线视频服务也会对网络造成很大压力,例如打开优酷超清视频后,下行带宽很快从1M左右达到饱和。Cisco/Netgear的家用级设备则不具备任何应用识别及控制能力,且在提供Wi-Fi服务的同时要处理DHCP、NAT等业务,网络使用体验难以保证。
  • Wi-Fi接入体验欠佳:现有无线方案采用家用级产品部署,在顾客较多时效果欠佳,例如考察当晚金山公司在大厅做活动(目测来宾超过200人)时,几个接入点都会有拒绝连接的情况发生。即便侥幸连上Wi-Fi,网络也几乎不可访问。下图是连接后PING路由器内网口IP及百度时的延迟及抖动情况。
  • 不合理配置:个别AP启用了NAT,导致D-Link DI-7200上的MAC/IP绑定、ARP抗攻击、连接数控制及监控统计功能失效,对网络安全性及可管理性造成影响。

改造建议

综上所述,对车库咖啡网络提出如下改造建议:

  • 统一调度接入资源:将8条ADSL线路进行整合,提高带宽利用率。从保护原有投资角度考虑,可使用两台D-Link DI-7200各接4条ADSL。开启其中一台上的DHCP、MAC/IP绑定及ARP抗攻击服务。
  • 对应用进行识别、控制及分流:从车库咖啡“创新孵化器”的具体需求出发,结合日常顾客对互联网的使用习惯,针对应用设定不同的QoS及访问控制策略。同时可基于上述的双网关部署,实现关键应用及非关键应用分流。根据陈首席公布的认捐情况,可使用Panabit专业版实现此功能。
  • 集中交换:局域网需实现物理上的统一,保证性能及可管理性,同时划分不同VLAN给创业团队、VIP用户及普通顾客使用。为简化Wi-Fi方案的部署难度,交换机需支持PoE供电。根据陈首席公布的认捐情况,可使用盛科交换机实现此功能。
  • 部署企业级Wi-Fi解决方案:根据车库咖啡在Wi-Fi接入方面的复杂需求,需部署企业级Wi-Fi解决方案,以无线控制器+瘦AP的方式解决兼容性、可靠性及性能问题。建议开启多SSID特性,将VLAN划分策略延展至Wi-Fi接入层面。

关于车库咖啡(本节内容摘自百度百科)

车库咖啡于2011年4月开始营业,是一家以创业和投资为主题的咖啡厅,创业者只需每人每天点一杯咖啡就可以在这里享用一天的免费开放式办公环境。可以说,车库咖啡不仅是创业者的低成本办公场所,也是投资人的项目库。

车库咖啡的“常驻”创业团队大约有10个,并仍有新的团队不定期“入驻”。在过去半年时间内,车库咖啡已经促成12个创业团队获得天使投资。

车库咖啡的访客不仅有大量的创业者和投资人,还包括关注创新和创业的媒体记者。

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

绿盟上市招股说明书

(3个打分, 平均:2.33 / 5)

RSA2012花絮 。陈怀临历险记

RSA2012花絮(梆子):9点20左右赶到了会员中心。AeriosHive的刘总是司机。他有pass。问:你如何进。答:绿盟的弟兄会搞定。中国人民有智慧。掏出电话:地瓜,地瓜,土豆呼唤;地瓜,,,瓜!地瓜失踪了。一转身,司机也不见了。。灰溜溜的去Registration,票价;100刀。晕倒,醒来在会议中心医务组。。。

RSA2012花絮(0)黑人警察和西班牙大妈护士关切的问道:首席,没事吧,要保重!我眼睛红润,吞下了几个牙齿。“没事,早晨没吃面包。。。”。在金钱与名节的权衡下,我掏出卡,“黑人兄弟,帮忙去帮买个pass。。。我不像看到被划卡的场面”。。。“首席,搞定了”。。。这时,10:11,一个短信来了。

RSA2012花絮(1)”首席,今天忘记带地瓜电话了,请用这个138 888 8888联系。我们的展位是999“。 绿盟的小赵!兄弟就兄弟,100刀算算什么,不就是1,2个星期该吃方便面嘛。我原谅的小赵。“没事,我在喝咖啡呢。。。”。

RSA2012花絮(2)10:43,电话,是安天网络的肖总。“首席,来了嘛?”。“到了,绿盟的小赵专车接送的,还帮我买了100元的pass”。“小赵人一直都是这么厚道的。我特喜欢他,我过来接你。。。”,肖总说。肖总2,3分钟后出现在我面前,亲切握手。带来一个exhibitor的pass,领我进入会场。

RSA2012花絮(3)在与多位(小)年轻工程师照相合影之后,肖总送给了我一些礼物。受伤的心灵逐渐平复。希望大家一定要与安天科技合作呀。。。绿盟的小赵也赶到了。。。去绿盟的展位。。。说有弟兄希望见我。

RSA2012花絮(4)来到绿盟的展位,完成与小朋友门的见面会。看他们的设备。然后他们的小叶同学来了。叶总是他们的N个产品的架构师。我对他们基于Tilera的产品特别感兴趣。可惜不能开机。。。这是我见到的第一个Tilera的security box。小叶同学人非常厚道和谦卑。一看就是一个专心做技术的人。

RSA2012花絮(5) 看完绿盟,然后开始瞎逛。主要还是看有没有什么免费的纪念品,爱,WS的习惯。感觉自己对系统不是很感兴趣了,必须喜欢看芯片方面的。但Intel等也没show什么东东。Netronome的NP基本上是唯一的一家。Netlogic,Cavium,Tilera都没来。RSA会议的堕落也可见一斑了。。。

RSA2012花絮(6) 敏感的同学们会注意到,NetroNome的NFP带了两个QDR的SRAM interface,除了两个DDR3 DRAM。如果比较EZChip的NP4,提供了DDR3 DRAM,RLDRAM和TCAM的interface。从定位来看,NetroNome似乎是很贵,估计500美金至少。 看了一下Cisco的QFP(ASR系列),也只是DRAM加TCAM。

RSA2012花絮(7) 转来转去有点无聊。Aerohive的刘总是个喜欢学习的银。估计每个摊位的纪念品都要扫荡。不好意思催他。自己瞎灌。Oooops,我司!凑上前。。。”你们这个是华塞产品线的东东还是华为自己的“。”天龙盖地虎,我司原装的。。。“。。。拷问”你是?“。”我曾经在贵司美研,。。。“

RSA2012花絮(8) 本以为我司怎么也要把USG9000整出来,弘扬国威。但似乎啥盒子也没有。难道预算都到巴塞罗那去了??那个部长是华塞的,知道是我后,上前,哽咽着说:你,你,。。。首席辛苦了。。。聊了一点其他,例如对我司在北美研发的观点。[省略250字]旁边一个弟兄听了,道:我非常赞同。。。

RSA2012花絮(9) 看了看Juniper的展位,似乎也是在bullshit。没啥意思。我的重点基本上是在F5上。数据中心,芯片是我比较喜欢看的东东。。。靠,遇见一个朋友,说F5声称的FW的Performance已经要比Juniper SRX5800要好了。亲,我要看看。。。F5是好股票呀。。。我是小股东呀。。。

RSA2012花絮(10) 在F5的展台呆了半个小时。事情是这样这样的。Y的Big-IP Load Balancing设备过了辽国的安全产品证书。但离我大宋USG9000这样的神器还差很远。天佑大宋呀。F5的家伙对听众说:Paypal,Amzon在Y设备前面都不放FW的。。。亲,是否连Router也不放算了。都F5搞定。。。

RSA2012花絮(11) Fortinet最近是个香饽饽。应该是最玄的。整了一个高级跑车。车牌是:FORTINET,下标:世界上最快的防火墙(与华为的老总门在巴塞罗那说世界上最快的手机是一个道理)。

RSA2012花絮(12) 美军,共军都齐了。伪军在哪里?诺大个展厅看不见Hillstone,山石网科!据说来了几个人,但都潜行。低调一定有低调的原因。。。想不通。看看PaloAlto Networks,Nil恨不得裸奔表演。。。Hillstone要加油呀。。。

RSA2012花絮(13) PAN的展台也是人山人海。我没看见Nil,小样这几年减肥成功。整的像个Teenager了。Y是聪明有钱人,但似乎整了个特难看的女朋友,还在Facebook上乱奔。看的我们都装没看见。PAN的基因其实与Netscreen华人基本上关系不(太)大,Hillstone比较纯正。但显然,Hillstone市场能力差太远。

RSA2012花絮(14) 中午吃饭的时候,绿盟赵总邀请一起吃饭。很高兴。把身上的钱和卡都特意留在朋友的身上,坚决不带钱。赵总,叶总,匪兵甲,匪兵乙等一行出门。上电梯的时候。这谁呀?网康的袁总和风河的人在一起。我都认识。亲,我除了不认识贪官,基本上啥人都认识。袁总热情的邀请我一起吃饭。。。

RSA2012花絮(15) 风河在中国的强势是我心中的痛。在华为美研的时候,就大力希望能把风河逐步出局。可惜无人支持。风河的许多人其实也都是朋友。但在国家大事面前,我的立场很坚定。华为不做出自己的Linux Distribution,基本上无脸见国人。扯其他的都扯蛋。攒系统傻子都会。

RSA2012花絮(16) 后来就开始瞎逛,看美女[有一些],看了一个台湾的公司。帮人做板子和system,从cavium,rmi,intel 。。。很有意思。软件是核心呀。那个台湾小美女很漂亮。。。

RSA2012花絮(17)Aerohive的刘总(CTO)逛到熄灯,还在意犹未尽。熄灯的时刻,我心中是暗喜。。。回来的路上。万家灯火。忙碌了一天的人们,都在回家ing。。。想起了一句歌词“。。。为了生活,人们四处奔波,却在命运中交错。。。”

RSA2012花絮(后记) 1。 人多人傻 2。 没大亮点 3。 没有看见数据中心的东东。 4。 纪念品不多不好。 5。 美女还是有一些。 6。熟人太多。

(5个打分, 平均:4.60 / 5)

拨云见日:企业网络准入策略小议

近来有机会接触了一些企业网络准入的项目,感触颇深。针对这个复杂的市场有一点自己的心得,没有结论,意在抛砖引玉,为大家的思考和讨论铺路。

本文只关注企业用户,而且是具备一定用户规模的国内企业用户,不是学校、不是小区宽带;其次,范围是用户对网络资源的访问,包括有线、无线、VPN等等。之所以要这么规定一下,是为了后面的讨论更准确、更有针对性,企业用户有自己的特点和需求,适合其它环境的思路在企业网中很可能玩儿不转,任何一种技术方案只有在立足的环境中才存在讨论的意义。

一. 缘起

网络准入是一个由来已久的话题,但一直以来并不是IT安全的重点,直到近年来,才逐渐成为炙手可热的话题。无线接入、智能移动终端和云计算的兴起共同催生了这一波热潮。

随着云计算的不断深入,越来越多的企业业务系统由传统的C/S架构向B/S架构迁移,以往访问后台数据需要安装专用软件,IT部门控制客户端软件的许可发放,就能够大致控制访问用户的范围。而在B/S架构中,用户只需要一个WEB浏览器即可登录系统,加上智能手机、智能平板和WiFi的流行,以往的限制条件消失了,任何人手中的设备都成了可能访问后台数据库的平台,IT部门突然一下子失去了对局面的控制,因此,对网络的准入控制被重新提上日程。只有合法的用户才能够接入网络,通过对接入用户的控制,IT部门开始试图重新夺回对数据访问的控制权。

二.  几种思路

控制用户接入网络的技术伴随网络本身的诞生和发展已经衍生出五花八门的派别,每种方式都有自己的特点和适用场景,很难说那种方式在技术和最终效果上技高一筹取得了绝对的领先地位。

在新形势下,接入技术本身并没有发生翻天覆地的变化,其演进更多地是从满足需求的前提出发,将现有的方式进行重新的优化、组合,从而推出一个满足新需求的解决方案。在实际环境中常见的认证方式包括二层认证、三层认证和基于客户端方式的认证。

二层认证

二层认证就是用户在获得IP地址之前必须通过的认证,大型企业往往利用DHCP进行IP地址分发,用户在接入网络之初同网络侧通过二层连接进行认证数据的交互,只有成功通过认证才能向DHCP服务器申请IP地址,从而收发数据。

二层认证的代表实现方式就是802.1X。802.1X是IEEE 802.1协议集的一部分,定义了EAP在以太网环境中的实现方式,而EAP是IETF在RFC3748中制定的在数据链路层中进行认证行为的一种机制,以满足在不同的二层环境下进行统一、一致的认证的需求。这个逻辑连起来就是,IETF首先制定了在数据链路层也就是二层上进行验证的EAP机制,然后IEEE给出了EAP在以太网环境中的运行方式,这个方式就是大家熟知的802.1X。现在,我们可以回答两个常常被混淆的问题:

1)802.1X是802.11的子集吗?

No,802.1X不但可以工作在无线环境中,同样能够工作在有线环境中,并且在WiFi被大规模部署之前,802.1X就已经是有线网络中一种重要的认证方式。

2)EAP是802.1X专用的认证方式吗?

No,理论上EAP可以被运用在任何一种数据链路层之上,例如PPP或以太。

基于802.1X的二层认证基本工作方式如下图所示:

image

上图中的三个元素,分别是客户端(Supplicant)、认证方(Authenticator)和认证服务器(Authentication Server)。客户端就是支持802.1X功能的终端设备,如笔记本、智能手机;认证方是将客户端接入网络的接入设备,在有线网络中是接入交换机,无线网络中是无线AP和控制器,在VPN连接中,认证方则是VPN服务器,认证方负责接受客户端的认证请求,但本身并没有处理这些请求的能力,它会将获得的信息转发到认证服务器,由认证服务器辨别客户端的合法性;认证服务器通常是集中部署在网络内的一台安全设备,当收到转发来的用户请求后,认证服务器将请求信息同已有的用户资料做比对,并将结果返还给认证方,如用户合法,认证方便会将客户端接入网络,否则予以屏蔽,或放入特殊VLAN,至此,一个标准的二层认证流程才结束。

在这个过程中,认证方和认证服务器之间通过特定的协议通信,目前采用最普遍的两个协议是RADIUS和TACACS+,总体说来,TACACS+的稳定性、安全性和灵活性更高,但TACACS+是思科私有协议,因此,在一般的用户接入场合,RADIUS更加常见。

通过多年的发展,802.1X+RADIUS的实现方式已经发展成为一个功能非常强大的准入方案,RADIUS丰富的字段使得认证可以不仅仅针对用户名与密码,还可以根据接入设备的MAC地址、IP地址、交换机端口等信息来进行认证。

之所以解释这么多二层认证的细节,是想说明基于802.1X的二层接入是一个非常成熟的方案,市场接受程度很高,不管认证方还是认证服务器,都不难找到多家厂商的产品,客户端的支持方面也不是问题,主流的桌面操作系统和智能手机终端大都支持802.1X。用户的接受与市场的成熟,对于安全策略的长期部署是非常重要的,802.1X在这方面的优势异常明显,其他方案不一定有这么幸运。

总体说来,802.1X的二层模式具备了以下三个特点:

1)完全公开的架构,每一个部分都有相应的国际标准,便于企业客户自由选择软硬件、搭建一个灵活的安全架构,不会受制于特定厂家;

2)成熟的技术标准,802.1X已经部署在全球成千上万的园区网,本身是一个非常成熟的技术,实施风险和成本低;

3)包含完善的认证和授权机制,能够满足企业用户的大部分需求。

如果仔细揣摩这三点,你会发现802.1X同以太网非常相似–公开、成熟、实用,这其实就是企业客户的核心需求,企业的IT部门在做任何选择时首先考虑的都是技术的可延续性以及成熟性,如果某项技术大家都在用,本身功能又实现得七七八八,这个方案就是最优方案,华而不实的新鲜玩意反而难以得到企业用户的垂青。

三层认证

说了这么多,传统的二层方案是个完美的方案了?如果放在五年前,也许是这样,但随着网络的发展,接入环境越来越复杂,802.1X在某些方面渐渐显得力不从心了。例如,某些企业需要为访客提供无线网络接入,但不可能每次有来访人员时临时在笔记本电脑上配置802.1X策略,这就需要一个快捷的办法将没有经过认证的第三方设备接到网络中。

三层认证就在这种背景下应运而生了。

三层认证又被称为WEB认证,顾名思义,认证过程是通过一个WEB页面完成的。当有新的设备需要接入时,网络设备不会默认屏蔽它,而仅仅为其提供一些基本数据的转发能力,如DHCP、DNS等,客户端可以通过DHCP拿到地址,但他还没有办法获得完全的网络权限,比如上个QQ啥的;此时,用户需要发起一个HTTP请求(在浏览器中访问任意一个WEB页面),交换机或者无线控制器从中截取到用户的这个HTTP请求,并将用户重定向到一个预先写好的认证页面上(这个页面可以存放在任意一个IP可达的WEB服务器上),用户在在这个页面使用用户名/密码完成认证,从而获得全面的网络访问权限。

image


同传统的二层认证比较,WEB最大区别就是去除了对客户端的要求,用户端设备无需进行配置,只要有一个浏览器就OK了,而这个条件基本上所有的个人设备都能够满足。因此,近年来WEB认证的发展非常快,特别是在无线、大型园区等环境中得到了大规模的部署,而主流网络厂家也纷纷将WEB认证作为无线控制器和接入交换机的一项默认内置功能。

三层认证凭借其自身的特点获得了市场的认可,但在现阶段毕竟还是一个补充方案,难以作为企业环境的主力认证方式。首先,每次上网通过WEB页面登录的方式对大多数企业用户来说都“土”了一点儿,而且WEB认证检查的内容也比较简单,大部分时候仅有用户名和密码,在高安全级别的环境中仍显单薄。

客户端方式

除了三层认证和二层认证,还有一种很有意思的思路,即通过客户端对接入用户进行认证。这里所说的客户端是指安装在用户设备的上的软件,其表现形式五花八门,以杀毒软件起家的厂商会做成杀软的功能子集、以桌面控制立足的厂家会做成控制软件的一部分、而传统的网络设备厂家则会将这部分功能集成到VPN\无线接入的用户端软件中。不管是什么路子,这类软件一般只干两件事情:1)从操作系统接手802.1X的认证流程;2)对操作系统的健康状况做检查,如是否安装了最新版补丁、杀毒软件是否更新到最新病毒库等等,若操作系统处于可靠的状态则允许接入网络,否则拒绝。

这种方式有一点像一个加强版的360软件,它不但帮你检查身体,还基于你的身体状况决定你是否能获得一张游泳证。由于健康状态的检查内容包含了系统的补丁安装、应用软件安装、杀毒软件更新等情况,因此,必须在客户的设备上安装一个系统权限非常高的客户端软件才能完成所有的检查工作。

很明显,客户端方式完全是从企业IT部门的视角出发,对最终用户采取更多的限制。通常,这种方式都会和厂家进行紧密的绑定,通过在每台终端设备上安装客户端,用户的IT流程和安全规范也紧密地同厂家能够提供的功能选项结合在一起。

三种方式的对比表格

image

三.  延伸思考

用户需要什么样的方案?

企业网的准入是一项非常特殊的技术,最终用户的体验是决定一个项目成败的关键。有的方案从技术上评估非常完美,但实施之后发现最终用户根本接受不了,过多挑战用户的使用习惯,最终被行政层面废掉。

有的客户在被厂家忽悠过后决定在整个公司范围内推广严格的网络准入控制,在所有PC终端上安装安全客户端软件。结果,客户端装上后频频告警,因为不少人在自己的电脑上安装的下载软件强行修改了系统的下载线程限制,还有的员工干脆卸载了原有杀毒软件,自己重新安装了互联网上的免费杀软。这些被折腾过的电脑,在安全客户端内置的严格的策略规则前统统被亮了红灯,上线测试第一周就有不少员工无法正常接入网络。结果IT部门啥都顾不上,成天到各处救火,最后这个系统被大领导一句话下了马。

即使是最通行的802.1X方式,也不一定适应每个地方的水土。当一台配置了802.1X接入的PC机刚开机时需要一定时间同网络侧交互认证信息,如果用户接受程度不高,很可能会认为网络接入效率低,从而投诉,给IT部门造成很大压力。

因此,对于最用用户来说,最好的方案就是用户体验最友好的方案,只有对原有使用流程影响最小的技术方案才能得到上下一致的支持,从而推动最终的全面部署。另一方面,业务部门对准入的支持也至关重要。

IT部门需要什么样的方案

对于IT部门来说,网络准入是一个非常笼统、模糊的概念,什么样的用户能够接入网络?什么样的安全检查才是足够安全?同企业的其他安全策略该如何整合?这些问题在业界都没有统一的结论,而且安全防护是一场没有终点的拉锯战,IT部门不可能无限制地投入资源去追求极致的安全级别。

准入控制的实施过程是非常复杂的,是一个惊动全局的工程,因此,IT部门在上马准入时无不希望是一个循序渐进的过程,先从最基本的二层准入或三层准入开始,逐渐推进到设备健康状态检查等复杂的机制,这在准入项目的实施过程中尤其重要。

其次,准入控制的最终对象是企业内部的人员,而大部分企业往往已经具备了用户数据库,且用户的合法性以此数据库的实时数据为准,比如供人力部门使用的微软Active Directory。新的准入系统要能够方便地与原有数据库集成,特别是将准入系统内复杂的策略直接绑定到已有的用户帐号上。例如有的用户希望对PC机的MAC地址进行认证,而在原有的Active Directory内是没有MAC地址这一个字段的,且这个数据库的管理权不一定在IT部门手里,那么新添加的MAC地址信息如何同原有的用户帐号绑定,并实现帐号信息的定期自动更新就是一个挑战。

最后,准入控制系统一定要有一个清晰、简洁的管理流程和界面。

什么是完美的产品?

综上所述,一个优秀的准入控制技术方案需要具备以下特点:

1)可延续性

所谓可延续性是指采用的技术方案要具有长期的发展路线和支持力度,或者是被广泛应用的公开标准,或者是强大厂商的主流产品。准入机制一旦部署将延伸到网络的各个角落,并同企业今后的安全策略紧密结合起来,如果基础平台不稳定,后期变更将是迁一发动全局的麻烦事;

2)可用性

准入策略的顺利实施一定是以最终用户的接受为基础,因此,准入系统对最终用户的使用流程不能有太大的影响,要提供一个足够友好的用户体验;

3)灵活性

准入策略的内涵非常广泛,企业IT部门在实施时一定是一个逐渐完善的过程,为了应对这种需求,准入系统要具备一定灵活性,各个功能模块的实现不能有冲突;

4)整合性

准入系统要能够方便地同主流的企业数据库系统整合,并将安全策略绑定到相应的用户帐号之上,实现自动化的用户数据更新。

虚拟桌面的机会

网络环境的变化,带来的是访问方式的变化。一方面,网络准入技术开始快速发展,另一方面,很多人开始询问“是否一定需要在网络边界做这么严格的控制,还有没有其他方法?”。

也许是有的。

虚拟桌面在企业内部的应用开始逐渐铺开,员工对数据库的访问全部通过虚拟桌面完成,而硬件本身可能是一个简单的瘦客户端,不具备复杂的功能。在企业网络内部对虚拟桌面流量设置高优先级QoS策略,对其余流量以及网络接入采取从简的思路,在未来,这并非不会是一种解决方案。

总之,随着云计算、智能手机、WiFi等新应用的快速发展,传统的企业网络不得不开始主动变化,这种变化将如何发生,往哪里去,得出怎样的结果,现在都还不明晰,但有一点是明确的,那就是有意企业数据网络和安全的厂家现在就必须开始重视这股潮流,未雨绸缪,才能从容应对未来的新一代企业网络的发展。

(7个打分, 平均:3.29 / 5)

华为赛门铁克USG9560评测报告

如果USG9100和USG9300算是试水之作,USG9500就是华赛在高端安全领域的杀手锏。虽然它仍不完美(当然完美的产品也不存在),却也足够令人颤抖了。

原文发于《计算机世界》。

毫无疑问,我们已经步入了云时代。放眼神州大地,一座座数据中心如雨后春笋般拔地而起,服务器数量与网络基础架构的规模屡创新高;互联网建设也在高速发展,骨干与接入带宽的不断提升,为用户业务带来了日新月异的应用体验;而3G与无线技术的普及,又让移动终端成为后PC时代真正的宠儿,正在掀开移动互联的新篇章。

从底层网络的角度看,通信技术的发展构建了多个维度的高速通路,让一切变为现实。同样,用户也必须借助不断创新的安全技术,建立与网络规模相匹配的防护体系,为业务保驾护航。经过国内外安全厂商的不懈努力,目前顶级防火墙的处理能力已经达到百G级别。这并不是个宣传意义大于实际意义的噱头,因为用户的需求已经迫在眉睫。在今年国内运营商的安全产品招标中,对高端防火墙的性能要求达到了40G-80G,距离部署百G产品的日子已不再遥远。针对这一趋势,华为赛门铁克也于近期推出了全新的USG9500系列产品,再次升级了高端产品线。我们也在第一时间对USG9560这款产品进行了测试,亲身体会了新一代百G产品带来的与众不同的应用体验,在此与读者朋友们分享。

规格领先 功能全面

华为赛门铁克USG9500系列包含USG9520、USG9560、USG9580三款产品,均基于华为高端路由硬件平台打造。设备中所有部件均为冗余设计,其中单板、电源模块和风扇支持热插拔,符合电信级别的高可靠性要求。三款产品的区别主要体现在扩展槽位的数量与整机性能方面,最高端的USG9580提供了多达16个接口/业务扩展槽位,标称具有2.56T交换容量及240G接口容量,是新系列中的旗舰产品;最低端的USG9520则针对主流的万兆及多千兆接入环境设计,提供3个接口/业务扩展槽位,标称最大40G的整机处理能力,具有灵活的扩展性和相对较高的性价比。我们测试的这台中端定位的USG9560则需占用14U的机架空间,提供了11个扩展槽位,其中3个用于安装主控交换(SRU)及交换引擎(SFU)。SRU主要负责设备管理、系统监控与调度、路由计算等工作,同时内置一个交换引擎。当插满两个SRU与1个SFU时,两套主控系统会工作在主备状态,3个交换引擎工作在2主1备的状态,提供1.44T的交换容量。这种设计可以保证设备在任意一块SRU或SFU出现故障时还能正常工作,且性能不会出现瓶颈。

USG9500系列产品全家福,从左至右依次为USG9520、USG9560、USG9580

USG9560上剩余的8个槽位用于安装业务卡(SPU)与接口卡(LPU),考虑到未来接口容量与性能的升级,每槽位设计带宽达到双向200G。在SPU与LPU的设计上,华为赛门铁克采用了模块化的思路,显得非常独特。SPU板载了两颗1GHz主频的NetLogic XLR732处理器,具有10G的处理能力。该卡同时提供了一个子卡插槽,可安装同样配置的业务处理子卡(SPC),将单板处理能力提升至20G。而LPU也提供两个子卡插槽,可安装不同类型的接口模块子卡(包括以太网与POS),目前可实现单子卡两个万兆或20个千兆的接口密度。与我们去年测试过的USG9110不同的是,USG9500系列产品中的SPU和LPU之间没有任何强制性的对应要求,用户可根据需要进行灵活搭配。

在基本功能与安全业务方面,USG9500系列产品已经实现得相当全面。该产品可以支持NAT端口复用,能够有效减少海量用户使用互联网时对公网IP的依赖,对运营商、行业用户及园区网用户有很大的实际意义。除了防火墙,USG9500还具有VPN、应用流量识别控制、IPS和抗DDoS的能力(后两者使用单独的业务插板实现),以满足数据中心为代表的新应用场景的复杂需求。借助华为在数通领域的长期积累,USG9500系列产品在路由支持的种类、兼容性等方面有着先天优势,既能可靠地独立或参与组网,亦可在遭到DDoS攻击时与上下游网络设备联动,实现流量的牵引、清洗与回注。

架构灵活 性能强大

与USG9000家族中的其他产品一样,USG9500系列产品也采用了“两分布、一统一”的设计思路,即分布式处理、分布式转发与统一管理。由于集成了高性能的网络处理器,LPU可以实现基于多种策略的数据分发操作,将流量尽可能均衡地交给每个SPU上的每一颗处理器进行处理。这也意味着,该产品可以通过增加SPU数量的方式,线性提升整机的处理能力。

配置

测试项

1块SPU

(配备SPC扩展卡)

2块SPU

(配备SPC扩展卡)

5块SPU

(配备SPC扩展卡)

吞吐量

(IMIX)

20G 40G 100G
平均延迟

(IMIX)

85us 85us 106us
HTTP

每秒新建连接数

669463 1360407 仪器限制
HTTP

最大并发连接数

8340904 16681108 仪器限制

USG9560防火墙基准性能测试结果(路由模式/1条全通策略)

测试数据

攻击类型

处理能力 业务板处理器平均占用率
SYN-Flood 10G 87%
UDP Flood 10G 70%
DNS-Flood 10G 83%
1:1:1混合流量 10G 81%

USG9560抗攻击测试结果(配备1块抗DDoS业务板,不含扩展子卡)

我们在随后的测试中使用了多至5块内置SPC子卡的SPU及3块具有4个万兆XFP接口的LPU,组成20G-100G规格的多种配置,对这一特点进行了验证。测试仪器为搭配了多个10G-LSM-XM4S网络层测试模块和Acceleron-NP应用层测试模块的IXIA Optixia XM12。当USG9560中只有1块SPU卡工作时,该系统(路由模式,1条全通策略,后同)在IMIX模型(UDP混合包,64Byte:594Byte:1518Byte=7:4:1)下的吞吐量为20G,平均延迟为85微秒。如果再增加一块SPU,IMIX吞吐量马上提升至40G,平均延迟保持不变。当5块SPU卡均处于工作状态时,系统的整机IMIX吞吐量达到100G,平均延迟则小幅上升至106微秒。在这个过程中,每颗CPU的使用率都保持一致,系统的负载均衡效果十分优秀。我们也试着在处理能力留有足够余量的情况下在线减少SPU卡的数量,USG9560会立刻自动对负载进行重新分配,达到新的均衡处理状态。

除了吞吐量与延迟,分布式处理、转发的优势在连接相关的性能指标上也有所体现。当使用1块SPU卡时,我们测得的整机HTTP新建能力(64Byte页面,后同)为每秒669463个连接,最大并发连接数为8340904,达到并超过50万/800万的标称值;两块SPU同时工作时,HTTP新建连接数提升至1360407,最大并发连接数也达到了16681108。由于测试仪器的限制,我们没有再对配备更多SPU卡时的性能进行测试,但仅从这两组数据中,已经可以看出整机的连接处理能力可以随着SPU板卡数量的增多而线性提升。

对于数据中心这样的应用场景来说,其可能受到攻击的规模之大、种类之复杂,是集成于UTM、NGFW等设备中的抗DDoS功能所难以抵御的。针对这种情况,华为赛门铁克将该功能独立出来,以专用业务卡的形式提供了高性能抗DDoS解决方案(单卡标称10G流量清洗能力,同样可以通过扩展子卡提升一倍)。我们也利用手头的测试仪器,对插入1块抗DDoS业务卡(不含扩展子卡)的USG9560进行了测试。面对测试仪分别生成的10G线速SYN-Flood、UDP Flood和DNS-Flood攻击流量(64Byte,后同),该设备可以将攻击流量完全阻断,同时保证后端服务器的正常访问,此时DDoS业务卡上的CPU使用率分别为87%、70%、83%;我们又按1:1:1的比例发起了包含三种攻击的混合流量,USG9560依然可以将攻击完全阻断,此时的CPU平均使用率为81%,仍留有部分余量。

TCAM:让天堑变通途

作为成本、查找速度均极为惊人的可寻址存储器,TCAM大多被用于核心路由器、数据中心交换机等高端数据通信产品,在安全设备中极少出现。不过,我们去年在USG9110产品测试中,已经注意到其业务板上配备有TCAM。如今,这一设计被USG9500系列产品所沿用,大有发扬光大之势。这是个令人费解的举动,因为厂商在设计产品时会本着“次优”和榨干硬件处理能力的原则,选择能满足需求的最简单、成本最低的解决方式。对于TCAM这种成本极高昂的器件来说,除非它能让产品性能产生革命性的变化,否则绝无使用的道理。那么,华为赛门铁克坚持在高端安全产品中使用TCAM意义何在?我们通过混合非法流量和访问控制列表(以下简称ACL)查找两个测试用例,进行了一系列的验证。

在合法数据流中混合非法流量,是安全产品测试中不可或缺的手段之一。目前,几乎所有状态检测防火墙都借助快速转发技术提升性能,当合法数据流建立后,流信息会被下发到防火墙状态表中,剩余报文可根据状态信息直接转发;非法流量则通常不会建立状态,这就意味着流中每一个数据包均要由处理器进行完整流程上的处理,其中就包括了资源开销非常大的ACL查找操作。当非法流量的比例达到一定程度的时候,防火墙就会因资源耗尽导致性能大幅下降。以我们去年测试过的一款64Byte UDP帧吞吐量达到8Gbps的防火墙为例,当测试流量由合法的8G变为6G合法流量+2G非法流量后,该设备的吞吐量竟然下降到100Mbps以下。

由于TCAM的存在,USG9560在处理非法流量时的性能开销大幅减小,处理能力也就得到了保证。我们在1块SPU处于工作状态的前提下,向设备的ACL中加入一条阻断特定流量的策略,再使用测试仪先后发起16G的正常流量与4G应被阻断的非法流量(均为UDP/386Byte帧长)。USG9560在只有正常流量通过的情况下,可以做到不丢包转发,此时的CPU使用率仅为21%;当加入4G非法流量后,正常流量的转发没有受到任何影响,非法流量则被完全阻断。此时SPU卡的CPU占用率上升至47%,仍有余力处理其他安全业务。从这个结果中可以看出,虽然TCAM没能让设备的理论性能得到进一步提升,却在处理非法流量时弥补了性能短板,在实际环境中体现了其存在的价值。

与混合非法流量的测试相比,ACL查找能力测试更偏向底层,但在园区网、骨干网和数据中心规模不断扩大的今天,许多用户需要借助防火墙实现更加复杂的访问控制,这个原本偏重理论层面的测试用例也就有了更多的实际意义。我们知道,大部分采用状态检测机制的防火墙会在启动时对用户设定的ACL进行预处理,将其转换为引擎可识别、查找的树或矩阵。转换算法的优劣决定了存储空间的占用、转换速度和查找性能,是厂商核心技术能力的体现。好的转换算法不但能以较低的资源代价实现较高的查找性能,还可以对ACL进行有效的优化合并。比如许多测试中使用的针对1个C段内连续IP而设定的策略,最优状态下可以被合并为1条等效策略,其测试数据显然不能代表设备在实际环境下的性能。

有鉴于此,我们在制定实验室安全产品测试规范的过程中,包含了基于复杂策略的测试用例。该用例中的ACL列表模拟部分用户的配置思路,包含了5000条不相关联的策略。它使用有针对性的算法生成,阻止主流转换算法对其进行优化,且令生成的树或矩阵变得极其复杂,显著提升了设备查找时的性能开销。一些产品在测试中无法正常加载此ACL,或会在加载后性能大幅下降。这样的产品如果被部署在实际环境中,会为用户带来无穷无尽的烦恼。某行业信息中心主管与我们交流时就曾谈到这样一个情况:当他们逐步将分散的服务器群组迁移至数据中心后,防火墙的ACL数量已接近3万条。此时设备从加电到进入正常工作状态需要长达40多分钟的时间,且设备每次在添加新的访问控制策略时,都会有1分多钟处于无响应状态。而他们先前使用的产品则在加载1万条左右的策略后直接罢工,严重影响了业务的正常开展。

不过,我们在对USG9560的测试中没有丝毫担心,因为TCAM的工作机制决定了其策略查找性能不受策略复杂度的影响。测试数据也很好地证明了这一点:在加载复杂策略的情况下,USG9560的开机时间仅由之前1条全通策略时的9分4秒增加到12分12秒。在此基础上使用测试仪发起命中第4999条策略的16G正常流量(UDP/386Byte),系统可实现不丢包转发,CPU占用率为33%;当另外加入命中第5000条策略的4G非法流量后,正常流量的转发没有受到影响,非法流量也被完全阻断,此时CPU占用率上升至55%。这样完美的测试结果,足以保证USG9560在海量策略的应用场景中保持应有的性能表现。

应用识别步入百G免费时代

从用户群体的需求角度出发,高端防火墙通常强调高性能、高可靠性,提供的安全业务并不像企业级产品那样全面。如果要增加特定功能,通常也会以专用业务插板的形式实现,尽可能减小对设备性能的影响。不过华为赛门铁克在USG9500系列产品中,将应用流量识别控制与防火墙、NAT、VPN等一同列为产品的基础特性,免费交付给用户使用,令人十分惊讶。众所周知,应用流量识别控制确实是一个快速增长的市场需求,以此为基础甚至诞生了下一代防火墙(NGFW)这一新产品形态,但因其需要消耗大量系统资源,对防火墙性能造成很大影响,罕有厂商会在最高端产品中加入该特性。华为赛门铁克此举,是为运营商及大型行业用户提供增值服务,还是为了迎合市场的推广策略?

只有测试能给出答案。我们使用BreakingPoint提供的测试仪表,对配备1块SPU的USG9560进行了检测率与性能测试。该测试仪可以模拟多种互联网应用,实时生成近乎真实的测试流量,而不是简单地利用PCAP回放进行仿真。在开启防火墙与应用流量识别控制功能(路由模式,加载1条全通策略,只识别不做控制)的情况下,USG9560对测试仪发出的包含HTTP、BT、eDonkey、流媒体等业务的10G混合流量(预设并达到每秒10万新建连接/最大保持200万并发连接)可以做到完全识别与线速转发。此时SPU上的CPU占用率比单纯防火墙模式时略有小幅上升,数据包转发的平均延迟也仅增至160微秒。不过也许是为了减少大流量时的系统负载,设备并没有在内置的图形化界面中提供应用层流量的相关统计,而是通过eLog集中分析报表系统进行统一的挖掘与呈现。

作为USG9500系列产品的基础功能,应用识别特性以进程形式工作在SPU中,理论上性能可随SPU数量增加而线性提升。我们也在之前测试100G吞吐量的硬件配置下,对开启应用识别功能时的整机处理能力进行了考察。BreakingPoint测试仪此时已无法生成如此巨大的测试流量,所以我们改用IXIA Optixia XM12以发送双向UDP报文(IMIX模型,包含800个并发连接)的方式进行测试。在100G的UDP流量压力下,USG9560仍然顺利完成了测试,将数据报文正常识别为未知UDP流量,性能也如预期般达到线速转发。我们在测试过程中也注意了设备的资源占用情况,可以看到5块SPU上的20颗处理器基本保持着同样的负载,不存在单点瓶颈的隐患,并且开启应用流量识别后,CPU负载并没有上升很多,相信在错综复杂的现网环境中仍可保证线速处理。

集成高性能的应用识别引擎并免费交付给用户,无疑是USG9500系列产品的最大亮点之一。从华为赛门铁克公布的信息来看,该引擎目前已能鉴别超过1000种应用协议,且有专人对协议特征进行扩充与更新。对于运营商与行业用户来说,集防火墙、NAT、应用流量识别控制功能于一身的高端设备正是他们目前梦寐以求的产品形态。我们感觉华为赛门铁克的思路很清晰,即短期以免费流控和应用防火墙为卖点,增强产品的竞争力,争取更多的市场份额;长期来看,应用识别的价值绝不仅仅在于流控或应用防火墙,它是未来几乎所有安全业务的核心,以此为基础通过升级的方式增加新的安全业务,对供求双方来说都是双赢的结果。

测试后记:彪悍的产品不需要解释

“我们主要就是一条连教育网的万兆出口,高峰期上下行流量加起来也不过10G出头,厂商却建议我至少在防火墙上插三块标称20G处理能力的业务引擎,这到底是为什么?”面对不久前交流时某高校信息中心主管抱怨式的咨询,我们感到很难回答。客观原因是存在的,任何安全产品在真实环境中的性能都会低于实验室中测得的理论值,当应用场景非常复杂时,下降幅度甚至会超过50%。为保障业务的正常运行,厂商一般会建议用户部署时做性能预留,但即便如此,要求用户至少购买3块业务卡的做法也是难以理解的。分布式防火墙本身就有着按需配置的特点,用户凭什么要为用不着的性能买单呢?

抛开技术上的因素,我们也许触及到一个比较敏感的话题,那就是性能标称值的准确性。它不像产品测试,有很多业界公认的评价标准,依据某一标准测得的性能,对任何产品都是公平有效的。而厂商在进行产品包装时的性能度量方法,是不存在任何统一标准的,也许吞吐量你标IMIX,我标1518Byte帧,或者新建连接你标HTTP,我标TCP。个别厂商甚至本着“人有多大胆、地有多大产”的思路,虚报出一个产品根本无法达到的性能。这种不负责任的做法给用户的选型工作增加了许多不必要的麻烦,也让用户对厂商宣称的性能指标产生了强烈的不信任感。所以我们看到,虽然越来越多的厂商开始在产品规格表中注明标称性能的测试环境,用户却完全不在乎了。他们怕了,他们伤不起了。

换个角度看,厂商即便给出了实实在在的性能参数,又有多大意义呢?用户买产品是要解决问题,他们没有兴趣研究为什么开启某功能后一块业务卡的性能就不再是20G,然后还得折算用多少块业务卡才能在理论上满足需求,最后再战战兢兢地通过测试去证明。彪悍的产品不需要解释,华为赛门铁克显然认识到了这一点,并成功地将其付诸实践。就像USG9560,不管我们怎么折磨,其单板性能永远等于标称值,包括本应属于下一代防火墙定义范畴的应用识别控制功能,你开,或者不开,20G的性能就在那里。这样的产品,才是对用户最大的尊重。

做到这一点真的很难。从产品角度看,华为赛门铁克为实际应用中的性能损耗做了充分的资源预留,这也是一块业务卡配备4颗NetLogic XLR732处理器的主要原因。在没明白这一点之前,我们甚至一度怀疑华为赛门铁克的研发实力,因为这样的处理器即便拿出一颗做业务卡,也完全有理由标称20G处理能力(实际上,大多数高端分布式防火墙也是这么做的)。该公司能顶住成本与研发上的压力,放低姿态去做“不需要解释”的产品,其魄力值得称赞。“千淘万漉虽辛苦,吹尽狂沙始到金”,任何用户都不会冷落这样一款实实在在的产品,这一点,不管你信不信,我反正信了。

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

《给力吧,x86》专题连载九:英特尔Sandy Bridge平台网络通信性能测试分析

本篇是《给力吧,x86》专题的第9篇连载内容,也是截至目前最后一篇。其中性能评估从Atom N270到Sandy Bridge,涵盖了目前主流嵌入式平台(尚缺3420)。后面如果时间、精力、环境允许,会补充针对NIC的独立测试。再次感谢同事与厂商朋友们付出的努力,也感谢弯曲站务组和读者朋友们的支持。

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

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

上一期连载内容中(见本报今年35期第36、37版),我们记录了上海交通大学网络信息中心的老师们通过严谨的测试,选择基于英特尔5520平台的x86服务器打造校园网流量分析与优化系统的全过程。那么,万众瞩目的英特尔新一代Sandy Bridge平台在网络通信应用中又会有怎样的表现?它是否可以将效能推进到一个新的高度?就让测试数据去证明一切吧。

价格越来越低、性能与可靠性越来越高,这就是x86平台在网络通信领域的发展现状。从之前的一系列测试中也可以看出,目前英特尔嵌入式产品解决方案已经很好地覆盖了百兆级、千兆级乃至准万兆级应用领域,并有着继续向上延伸的趋势。向上拓展的先锋自然是英特尔Sandy Bridge平台,基于该架构的桌面级产品自发布之日起就凭借超强的实力在市场上独领风骚,也大大增加了人们对其企业应用效能的期待。千呼万唤始出来,在经历了更多的设计与验证周期后,基于Sandy Bridge的网络通信硬件平台终于批量入市。本次我们测试的立华科技提供的FW-8865,就是首发产品中的优秀代表。

规格放大 体积缩小

FW-8865的核心是英特尔Cougar Point C200芯片组中最高端的型号C206,支持LGA1155接口的Sandy Bridge处理器,包括企业级的Xeon E3和桌面级的Core i3/i5/i7。理论上,LGA1155平台的Sandy Bridge处理器和芯片组可以混合搭配,但前提是使用正确的、高质量的BIOS,因此并不是所有的主板都能良好地兼容两种处理器。FW-8865在这方面显然不存在问题,因为测试中使用的就是一颗四核心、32nm工艺制造的Core i7 2600K。该处理器具有256KB L2缓存(每核)和共8MB容量的通过环形总线和CPU核心连结的共享L3缓存,主频为3.4GHz,最大Turbo Boost频率可以达到3.8GHz。不过从稳定性的角度考虑,该特性在测试中没有被启用。同样的道理,Core i7 2600也支持超线程技术,可以提供8个硬件线程,但在测试中也被关闭。

针对处理器内置PCIe 2.0 Lane数量的差异,FW-8865的主板也分为支持Core i系列的MB-8865A和支持Xeon E3系列的MB-8865B。对于后者来说,Xeon E3系列处理器额外的4个PCIe Lane也连接到左起第三个扩展接口模块,与C206提供的另外4个PCIe Lane共同工作,使接口带宽加倍;另外两个接口扩展模块的规格则没有区别,使用的都是处理器上16个PCIe Lane配成的两个x8接口。内存方面,MB-8865A/B都提供了4个ECC DIMM插槽,最大支持32GB的Unbuffered ECC/Non-ECC DDR-1333内存。而我们测试的这台设备配备了两条2GB容量的DDR3-1333内存,工作在双通道模式。FW-8865的标准配置还包括一个Mini-PCI插槽、一个x4的PCIe Riser(与OPMA远程控制模块复用)、一个CF卡插槽和4个SATA端口,并使用一颗Realtek出品的RTL8110SC千兆网络控制器作为管理配置接口。

作为最新一代的网络通信硬件平台,FW-8865提供了多种高速以太网接口扩展模块(甚至包括万兆电口的型号),可供用户灵活选配。对于这个目前最强大的x86平台来说,千兆级别的负载显然不能充分挖掘其性能,所以本次测试都在搭配双万兆接口扩展模块的FW-8865上进行(使用与处理器直连的槽位)。该模块基于英特尔82599ES打造,它是常见的82599EB的串行版本,主要区别是针对高密度/刀片应用增加了对串行背板总线的支持,功能、性能都极其强大。在T540尚未推出前,它们是英特尔万兆网络控制器产品线中最顶级的型号。82599ES/82599EB使用了5GT/s的PCIe 2.0 x8接口,支持32个PCIe并发请求和512字节的PCIe有效载荷,以及MSI和MSI-X(Extended Message Signaled Interrupt,扩展消息告知中断)特性。单芯片提供双万兆以太网接口是82599ES/82599EB的标准规格,每个接口可以支持128个TX/RX队列,并可根据需要最多划分为64个RSS(Receive Side Scaling,接收方扩展)队列。此外,它们还支持RSC(Receive Side Coalescing,接收方聚合)、低延迟中断等技术,以及包括基于L2 Ethertype、5元组、SYN标识以及英特尔Ethernet Flow Director在内的多种分类/过滤特性。

也许是因为英特尔在芯片层面就开始整合,基于Sandy Bridge平台的FW-8865在设计上显得并不复杂,2U规格的机箱内留有大量空间,对系统散热十分有利。而从最大300W的冗余电源的配置来看,该机的整体功耗也相对较低。有了这样的优势,立华科技也推出了接口数量略低的1U规格产品,在机架空间愈发宝贵的今天相信会有更强的竞争力。

40G:理想照进现实

我们依旧采用了NCPBench 0.8评估软件,依照RFC 2544标准对多达4个万兆接口进行了纯转发模式下的测试(NCPBench的功能介绍和使用方法见本报今年第16/17期51版)。起初我们曾怀疑这个发布已有一段时间的版本不能充分发挥最新硬件平台的性能,但事实证明这种担心是多余的。FW-8865在测试中的表现,足以用震撼二字来形容:当我们将一个扩展模块上的两个万兆接口配置为网桥进行测试时,64Byte帧的整体转发速率达到22.3Mpps,吞吐量达到14.98Gbps;换用128Byte帧时,吞吐量上升为19.37Gbps,已接近线速。有了这样的铺垫,FW-8865在使用256Byte-1518Byte帧的测试中做到线速转发就丝毫不令人惊讶了,这台基于Sandy Bridge架构的网络通信硬件平台就这样轻松刷新了x86平台的性能记录。

测试项

帧长度

包转发速率

(单位:pps)

百分比

(100%=20Gbps)

包处理能力

(单位:Gbps)

64 Byte 22298854 74.92% 14.98
128 Byte 16360295 96.85% 19.37
256 Byte 9057262 100.00% 20.00
512 Byte 4698882 100.00% 20.00
1024 Byte 2394448 100.00% 20.00
1280 Byte 1922926 100.00% 20.00
1518 Byte 1644608 100.00% 20.00

表1 FW-8865吞吐量测试结果(1组桥,1组双向流量,同模块)

一直关心本专题的读者朋友们可能记得,在上一篇关于英特尔5520平台的测试记录中,由上一代顶级至强处理器X5690搭配82599万兆网络控制器的系统在同样的测试条件下只达到整机10.24Mpps的64Byte帧转发能力。仅仅更新系统平台就能让性能翻倍,Sandy Bridge的火力未免也太过强劲。为了寻找系统瓶颈,我们开始人为地制造一些障碍。在以往的测试中,我们曾经遇到过一些产品,其跨模块测试时的性能要远低于同模块内测得的性能。为验证这种现象在FW-8865是否存在,我们将隶属不同模块的两个万兆口配置为网桥,重新进行了一次测试,结果不降反升:系统自128Byte帧起就已线速转发,64Byte帧时的整机转发速率更是达到了惊人的28Mpps,吞吐量接近19Gbps。我们猜测之前单模块时的接口资源有限,如PCIe接口的并发请求数量和重传缓冲都可能受到限制;跨模块测试时,可以调用的资源翻倍,从而提升了平台的整体性能。而两个万兆接口模块直接连接到CPU,其间没有了可能成为性能瓶颈的桥片,也许是性能提升的另一个因素。

测试项

帧长度

包转发速率

(单位:pps)

百分比

(100%=20Gbps)

包处理能力

(单位:Gbps)

64 Byte 28025373 94.17% 18.83
128 Byte 16890653 100.00% 20.00
256 Byte 9060031 100.00% 20.00
512 Byte 4698905 100.00% 20.00
1024 Byte 2394459 100.00% 20.00
1280 Byte 1922935 100.00% 20.00
1518 Byte 1644616 100.00% 20.00

表2 FW-8865吞吐量测试结果(1组桥,1组双向流量,跨模块)

看来20G已经无法阻止彪悍的Sandy Bridge平台了,感谢立华科技为我们提供了两个万兆接口扩展模块,能让压力测试继续上升到x86从未染指过的40G级别。在巨大的压力下,当同一模块上的两个万兆口分别配置为网桥进行测试时,整机64Byte帧的转发速率为23.3Mpps,较同模块1组桥时略有上升,但大大低于跨模块1组桥时的性能。但在使用128Byte帧的测试中,FW-8865的整机转发速率基本没有下降,吞吐量达到27.54Gbps。并且从256Byte开始,做到40G流量的线速转发。我们随后也在跨模块两组桥的配置下重复了测试,结果没有发生任何变化。老实说,有了之前的测试结果打底,本次测得的多个40G线速转发的结果并没太令人惊讶。照这种情况推断,只要接口带宽不成为瓶颈,Sandy Bridge平台的大包转发能力即便测到60G也不足为奇。相反,64Byte帧时的性能下降是个很意外的情况,在以往测试中很少出现,推断其瓶颈应出现在I/O层面。

测试项

帧长度

包转发速率

(单位:pps)

百分比

(100%=40Gbps)

包处理能力

(单位:Gbps)

64 Byte 23348963 39.23% 15.69
128 Byte 23259771 68.85% 27.54
256 Byte 18114599 100.00% 40.00
512 Byte 9397796 100.00% 40.00
1024 Byte 4788915 100.00% 40.00
1280 Byte 3845870 100.00% 40.00
1518 Byte 3289229 100.00% 40.00

表3 FW-8865吞吐量测试结果(两组桥,两组双向流量,同模块)

测试项

帧长度

包转发速率

(单位:pps)

百分比

(100%=40Gbps)

包处理能力

(单位:Gbps)

64 Byte 23348963 39.23% 15.69
128 Byte 23259771 68.85% 27.54
256 Byte 18114599 100.00% 40.00
512 Byte 9397796 100.00% 40.00
1024 Byte 4788915 100.00% 40.00
1280 Byte 3845870 100.00% 40.00
1518 Byte 3289229 100.00% 40.00

表4 FW-8865吞吐量测试结果(两组桥,两组双向流量,跨模块)

为了弄清造成这种情况的原因,我们又构造了一个新的测试用例。在刚才的环境中,我们去掉了1组桥中某个方向上的所有数据流,对FW-8865施加共30Gbps的测试流量(1组双向流量+1组单向流量)。这次的结果又高得令人感到意外,该平台在使用128Byte帧测试时吞吐量就基本接近线速;64Byte帧时的整机转发速率更是大幅增加至32.5Mpps,吞吐量达到21.86Gbps。并且无论将同模块还是不同模块中的两个接口配置为网桥,性能都保持一致。虽然这一结果依然无规律可寻,但我们确实是第一次在x86平台上见到64Byte帧转发能力超过20Gbps,就请记住这个由Sandy Bridge创造的里程碑吧。

测试项

帧长度

包转发速率

(单位:pps)

百分比

(100%=30Gbps)

包处理能力

(单位:Gbps)

64 Byte 32526021 72.86% 21.86
128 Byte 24869179 98.15% 29.45
256 Byte 13585927 100.00% 30.00
512 Byte 7048342 100.00% 30.00
1024 Byte 3591684 100.00% 30.00
1280 Byte 2884396 100.00% 30.00
1518 Byte 2466920 100.00% 30.00

表5 FW-8865吞吐量测试结果(两组桥,1组双向流量+1组单向流量,同模块)

测试项

帧长度

包转发速率

(单位:pps)

百分比

(100%=30Gbps)

包处理能力

(单位:Gbps)

64 Byte 32526021 72.86% 21.86
128 Byte 24869179 98.15% 29.45
256 Byte 13585927 100.00% 30.00
512 Byte 7048342 100.00% 30.00
1024 Byte 3591684 100.00% 30.00
1280 Byte 2884396 100.00% 30.00
1518 Byte 2466920 100.00% 30.00

表6 FW-8865吞吐量测试结果(两组桥,1组双向流量+1组单向流量,跨模块)

需要说明的是,以上所有测试结果都是在NCPBench中设定一个vcpu(即一个物理核)做管理、两个vcpu做I/O时得到的。我们也尝试着使用除了管理核外的其它所有3个vcpu做I/O,但测得的性能并没有像预期那样线性增长,反而会略有下降。但当NCPBench运行在“转发+简单业务”模式时,两个vcpu情况下的性能会有超过20%的下降,3个vcpu时的性能则不受影响。这至少说明在第二种情况下,处理器的负荷仍未达到100%,理论上可以在保证速度的前提下进行更加复杂的业务处理。

纵观所有测试数据,即便只使用一个万兆接口扩展模块,基于Sandy Bridge平台的FW-8865也能够达到接近15Gbps的64Byte帧转发性能。而在帧长度超过256Byte时,该平台在任何情况下均可做到线速转发,吞吐量最大可达40Gbps。根据经验,如果基于FW-8865打造传统的状态检测防火墙,在40G的现网环境中正常工作是毫无问题的。我们甚至认为,如果软件的效率足够优秀,使用该硬件打造40G规格的流控产品也是极有可能的。无论如何,英特尔最新的Sandy Bridge平台已经创造了历史,凭借革命性的性能表现开启了x86在网络通信领域的新篇章。

测试后记:x86,真的开始给力了

自从2月28日刊登第一篇内容开始,本专题已陆续进行了9期连载。我们与读者朋友们一起,回顾了x86平台在网络通信领域的应用历程,也分析了曾经活跃在市场上的一些产品解决方案。此后,我们开始了网络通信硬件平台的实际测试工作,对几款目前主流的x86解决方案进行了分析,亲眼见证了其规格与性能不断提高的过程。虽然它们与同级别的专用产品解决方案相比仍不占优,但差距已明显缩小,表现出一定的市场竞争力。而英特尔最新的Sandy Bridge平台在测试中表现出的超群实力,完全扭转了之前的被动局面,达到业界领先水平。在用户业务逐步由网络层转向应用层的今天,x86平台凭借I/O与计算能力方面的综合优势,也有机会去赢得更多的市场。如果说以前英特尔在网络通信领域处于追随者的位置,那么Sandy Bridge平台的横空出世,则意味着这个通用领域的巨擘已经站在了该领域的最前沿,抢占了云时代的先机。

链接:“企业级”价值何在?

今年4月,英特尔面向四路及四路以上服务器市场发布了代号为Westmere-EX的Xeon E7系列处理器。一同发布的还有Xeon E3,一类面向单路服务器/工作站市场的产品。实际上,Xeon E3就是1月份发布的Sandy Bridge-DT处理器的Xeon版本,它们非常相似,例如一样都是LGA 1155封装,使用的芯片组也同属Cougar Point PCH系列。甚至在价格上,英特尔官方给出的两类同级别产品的指导价也只有很小的差异。

英特尔Xeon E3-1200系列平台架构图

不过,面向企业市场的产品和面向桌面市场的终究还有一些不同。目前,大部分英特尔平台已经走向单芯片组方案,很多功能融合进CPU,因此差异也更多地体现在CPU上。与桌面版本一样,Xeon E3也集成了传统的北桥,提供PCI Express 2.0接口,但它提供了20个Lane,比桌面版本多出4个,较为明显地增强了其综合I/O能力。例如对工作站用户来说,可能需要使用一个x16接口或者两个x8接口连接单显卡/双显卡,同时还需要通过阵列卡连接磁盘系统,并使用高速网卡连接到局域网。这时,桌面级处理器的16个Lane就显得捉襟见肘,虽然设备也可连接到PCH上,但其带宽和延迟均无法与CPU直连的模式相提并论。而对于网络通信应用来说,PCIe Lane的数量直接决定了最大接口数量,自然是多多益善。

第二个差别体现在内存支持上,几乎所有的桌面级处理器都不支持ECC内存。而企业级应用通常都会长期持续运行,它们需要7×24的可靠性,因此所有的Xeon处理器都支持ECC技术。常见的可以检查多位错误并纠正单位错误的ECC内存会自动检测并纠正约99.99%的内存错误,可以消除约1/3的由数据破坏引发的系统出错事件,提升了系统长期运行时的稳定性。

Xeon E3还提供了无内置显卡的版本,这也是一个比较明显但不是所有情形下都能从中获益的区别。笔者在Sandy Bridge测试分析系列连载的第5篇(见本报今年11期第48版)中曾经介绍过,目前所有的桌面版Sandy Bridge处理器中均集成了显卡,它将会与CPU共享L3缓存。如果确定不使用内置显卡,可以通过屏蔽的方式提升CPU可以使用的L3缓存容量,从而提高性能。

Cougar Point PCH的桌面版本是为人所熟知的P67、H67、Z68等芯片组,而其服务器版本则称为C200系列,目前有C206、C204、C202三个型号。它们的区别主要体现在扩展性方面,例如最低端的C202仅能支持CPU提供的16个PCIe Lane,不支持CPU内置显卡,也不支持SATA 6Gb/s端口及Intel AMT 7.0特性。除此之外,C200系列芯片组能够支持更多的TACH/PWM风扇控制信号、PECI(Platform Environmental Control Interface)界面和SST(Simple Serial Transport)总线,C204还可以实现英特尔特有的Node Manager特性,可以监控管理每个节点的能耗。以上多种企业级特性,对提升网络通信产品的可靠性来说有着非常积极的意义。(文/计算机世界实验室 盘骏)

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

《给力吧,x86》专题连载八:英特尔5520平台网络通信性能测试分析(下)

上一期连载内容中(见本报今年34期第28、29版),我们介绍了上海交通大学网络信息中心的老师们在流量分析与优化系统选型中面临的问题。那么,x86平台在万兆环境下能否稳定工作?现有平台的性能是否又能满足需求?针对种种疑虑,老师们对送测产品进行了长期、细致的测试验证工作。

在完成了基于戴尔PowerEdge R710服务器的安装调试工作后,实验室环境中的测试终于拉开了序幕。为了充分验证Panabit应用层流量分析与优化系统在高负载下的性能表现,上海交通大学网络信息中心的老师们设计了为数不多但极其复杂的测试用例。例如他们使用IXIA的专业测试仪表,分别在两个10G接口后端模拟了100个MAC地址和10万个IP地址,随机发送双向流量去测试设备的吞吐量。这是非常苛刻的测试手段,至少我们在平时的测试工作中不曾使用,因为根据以往经验,许多安全产品在这样的环境下都会死机或者重启。但老师们这样测试却无可厚非,上海交通大学校园网内有数万节点,网络边缘也没有执行任何NAT策略,Panabit上线后将面对的就是测试中模拟出的情况。真实的就是最好的,也只有这样的测试,才能更精准地体现出被测设备在特定应用场景下的性能。

性能初测通过

在吞吐量测试中,老师们只选择了64Byte和512Byte两种比较具有代表性的帧长。前者是对设备极限性能的考验,现网中绝少出现(个别DDoS攻击会在短时间内产生大量小包,对工作在4层以上的设备造成很大压力);后者则比较接近现网中的平均包长(600-700Byte),测试结果具有比较强的参考价值。考虑到个别设备会在超过极限处理能力后性能大幅下降,丢包率远远超过理论值(通常丢包数量应等于测试流量减去极限处理能力),有着资深运维经验的老师们还特别考察了Panabit在过载时的性能表现。

测试项

帧长度

吞吐量

(4层,数据包有IP头/协议类型UDP)

丢包率
百分比

(100%=20Gbps)

包转发速率 包处理能力

(实际载荷)

64 Byte 20% 5.96 Mpps 3.04 Gbps 0
25% 7.44 Mpps 3.80 Gbps 14.9%
30% 8.92 Mpps 4.58 Gbps 21.6%
512 Byte 64% 3.00 Mpps 12.32 Gbps 0
70% 3.28 Mpps 13.48 Gbps 11.4%
80% 3.76 Mpps 15.40 Gbps 22.3%

表注:吞吐量、丢包率测试结果(4层,数据包有IP头/协议类型UDP)

从结果中可以看出,面对一系列苛刻的测试条件,由顶级英特尔5520平台所承载的Panabit应用层流量分析与优化系统还是表现出了不错的性能。在使用64Byte帧进行测试时,系统整体吞吐量达到20%,整体包转发速率为5.96Mpps;当使用512Byte帧时,系统整体吞吐量达到64%,整体包转发速率为3Mpps。测试结束后在Panabit提供的统计信息中可以看到,所有流量也被顺利识别为未知协议。而在使用略高于两个极限值的测试流量进行过载测试时,测试仪统计得到的丢包率也在预定范围内,系统整体运行稳定。

测试项

帧长度

吞吐量

(3层,数据包有IP头/协议类型None)

丢包率
百分比

(100%=20Gbps)

包转发速率 包处理能力

(实际载荷)

64 Byte 24% 7.14 Mpps 3.64 Gbps 0
27% 8.04 Mpps 4.12 Gbps 8.2%
30% 8.92 Mpps 4.58 Gbps 17.9%
512 Byte 64% 3.00 Mpps 12.32 Gbps 0
70% 3.28 Mpps 13.48 Gbps 10.5%
80% 3.76 Mpps 15.40 Gbps 21.6%

表注:吞吐量、丢包率测试结果(3层,数据包有IP头/协议类型None)

瓶颈究竟出现在哪个环节?是转发层面还是业务层面?老师们利用之前的环境,使用另一组测试用例进行了验证。这次测试仪发出的流量将不包含UDP头部,仅为带有IP头的3层报文。根据Panabit应用层流量分析与优化系统公布的运行逻辑,这样的流量从负责数据转发(I/O)的内核提交到做状态检测与应用协议识别控制的内核后,将只进行连接层面的处理,业务逻辑基本等同于工作在桥模式下的状态检测防火墙。在抛开繁重的应用协议识别的包袱后,系统的整体处理能力是否会有一个飞跃呢?测试得到的结果令人感到意外,当使用64Byte帧进行测试时,整机吞吐量仅比之前高出4个百分点;而当使用512Byte帧测试时,吞吐量没有发生任何变化。虽然目前无法判断状态检测引擎是不是瓶颈所在,但基本可以判定应用协议的识别控制并不是系统整体的瓶颈,x86处理器在计算能力方面的优势还是值得肯定的。而这一阶段的测试数据也让老师们相信,Panabit应用层流量分析与优化系统对于上海交通大学校园网目前的运行情况来说,也是能堪大任的。

5520平台深度分析

在征得老师们的许可后,我们在同样环境下使用久经考验的评估利器NCPBench 0.8进行了测试,得到了可以用做纵向对比的数据。在这个环节中,服务器上的两个万兆接口和每两个相邻的千兆接口被配置为网桥,在纯转发与简单业务两种模式下使用64Byte帧进行测试(NCPBench的功能介绍和使用方法见本报今年第16/17期51版)。

测试项

帧长度

纯转发模式 简单业务模式
百分比

(100%=24Gbps)

包转发速率 百分比

(100%=24Gbps)

包转发速率
64 Byte 39.163% 13.99Mpps 39.163% 13.99Mpps

表注:NCPBench吞吐量测试结果

我们又得到了两组几乎一致的数据,无论是纯转发模式还是简单业务模式下,被测平台的吞吐量均为39.163%,包转发速率则接近14Mpps。还有一处值得注意:两种模式下,4个千兆接口间均能达到线速转发,两个万兆接口间则只能达到单向4Mpps、双向共8Mpps的转发速率。我们非常关注前者会对后者造成多大的影响,所以在最后单独对两个万兆接口进行了纯转发测试。此次得到的数据是单向5.12Mpps、双向共10.24Mpps,较之前有所上升,但与整机处理能力仍有不小的差距。需要说明的是,NCPBench允许测试者自行设定要使用处理器内核的数量,上述数据是在使用两个核情况下的测试结果。我们也尝试使用更多的内核数进行了测试,得到的数据基本相同,个别情况下还会略低。

这是个很有意思的现象,对瓶颈定位有着很大帮助。与Panabit“特定内核处理特定业务”的逻辑不同,NCPBench的业务模型采用SMP模式构建,每个内核都进行数据包转发与业务处理操作。理论上如果每个核都达到满负荷工作状态,纯转发模式时的性能会高于简单业务模式。所以我们从测试结果中只能得到这样的结论,即无论在哪种工作模式下,处理器内核的利用率都没有达到极限,即便只使用两个内核时也是如此。

在长期的测试工作中,处理器资源耗尽通常是系统整体瓶颈的惟一原因,而这种“喂不饱”处理器的情况,还是第一次出现。我们也曾怀疑性能瓶颈可能来自于NCPBench自带的网卡驱动,但在稍后进行的对英特尔Sandy Bridge平台的测试中,同样的驱动在一块同样基于英特尔82599EB网络控制器的网卡上带来了28Mpps的纯转发能力。所以,我们只能做出最遗憾的推测,即戴尔PowerEdge R710服务器的某个部分也许存在I/O方面的设计瓶颈。之所以不怀疑5520平台,是因为我们在另一个测试中,在一台采用E5550/4GB/82599EB配置的网络通信硬件平台上得到了两口间16Mpps、4口间超过22Mpps的测试数据。这也与我们经验中侧重于计算的服务器平台,在I/O方面逊于专注于通信业务的网络通信硬件平台的认识相吻合。

其实,即便是同样类型、同样配置的设备,在承载网络通信、安全这种时延敏感型业务时的表现也可能存在很大差异。在之前我们进行的基于Atom D525平台的评测过程中,就出现过来自不同厂商的配置完全一样的产品性能差异达40%的情况。我们无法对此做出更准确的解释,只能提醒广大用户和各厂商负责供应链的人员,在选型时一定要做更加细致的测试工作。

识别准确 稳定可靠

经过一系列测试,由英特尔5520平台承载的Panabit应用层流量分析与优化系统表现出了不错的性能水准,受到上海交通大学网络信息中心老师们的普遍认可。实际上,老师们对该系统在应用协议识别率及稳定性方面的测试早在去年底就已开始,他们使用另一台基于英特尔至强E5620处理器的服务器搭载Panabit,以旁路模式对两个万兆接口镜像而来的所有IPv4出口链路的上、下行流量进行了长期的监控分析。从老师们提供的统计资料中可以看出,未知协议所占流量在累计数据中所占的比重为2.8%,在10分钟统计数据中的所占比例也仅为3%,识别率堪称优秀。而在稳定性方面,资料显示该系统已连续运行超过168天,老师们也坦言没有出现过任何异常,只是在系统更新等人为操作时才会重启。

图注:旁路部署的Panabit系统运行截图

出于更加稳妥的考虑,老师们还是决定进行更长时间的旁路测试后,再讨论将其部署到网络边界。不过我们认为,在如此复杂的应用场景下长期稳定运行的事实,至少可以适当修正那些“x86架构产品稳定性不如专用系统”的论调。如果决定接入,硬件设备还要在可靠性方面满足更多的要求。例如现在工作在旁路模式下,可以不考虑接口的硬件Bypass,但当接入现网环境时,硬件Bypass特性就成为一条底线。服务器搭配多网卡的方式显然不能满足这一需求,我们建议老师们辅以专用的硬件Bypass设备,或直接选购支持该特性的x86网络通信硬件平台。

站在科研的角度,网络信息中心的老师们还提出了一些颇具价值的建议。例如针对前景被广为看好的OpenFlow,老师们建议Panabit增加在协议识别后输出Syslog信息的能力。这样一来,该系统就可以直接部署在一些基于OpenFlow搭建的网络环境中,为控制器提供基于应用层协议的策略配置能力。网络设备在并发连接方面的限制如今也需要突破,像本次测试版本中限定的600万并发连接数,仅用两台高性能服务器做端口扫描(模拟DDoS攻击)就可以打满,此时协议的正常识别就会受到影响。毫无疑问,这些来自科研领域兼一线用户的真知灼见,对产品的完善提高有着宝贵的指导意义。

测试后记

本次测试时间久、项目多,我们认为其中最有价值的内容当属老师们使用的测试方法。被测设备两端模拟大量MAC及IP地址后随机发送流量,可以快速制造出大量的新建连接和并发连接,对一切基于状态检测机制的设备造成较大的压力。即便是传统防火墙,也可能在连接的建立和拆除过程中遭遇性能瓶颈,其直接表现就是系统假死机(CPU占用率100%导致失去响应)或真死机/重启(如果系统架构有缺陷的话)。当连接信息足够多时,CPU在处理中也不得不频繁更新Cache中的数据,会对性能造成非常大的影响,许多高端x86架构产品选择Cache较大的至强处理器就是为了规避这一瓶颈。此外,如果使用比较少的流进行测试,业务处理时通常会走快速路径,而随机多流测试可以更好地模拟现网模型,充分评估设备处理慢速路径时的性能。根据我们以往的测试经验,不少安全设备在这种测试环境下性能会有数量级上的下降。

另一方面,我们在之前的下一代防火墙专题中曾经讨论过,使用UDP数据包进行吞吐量测试,不太适合于IPS、WAF等设备的评估,却很容易对流控、上网行为管理等一切基于应用层协议识别技术的设备造成极大的压力。因为目前来看,对UDP包的检测通常是应用协议识别引擎中的最长路径,而测试时构造出的UDP包又必然会被判断为未知协议类型,后继流量没有快速路径可走,设备应对其进行逐包分析。这一环节对硬件处理能力的需求,理论上远远超过状态检测,所以用户即便没有很强悍的测试仪表,也可以通过高性能PC/服务器加发包软件的方式自行测试。惟一需要注意的,是一定要在测试前验证协议识别的效果,保证协议识别引擎处于正常工作的状态。

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

《给力吧,x86》专题连载七:英特尔5520平台网络通信性能测试分析(上)

在之前两期连载内容中(见本报今年第21期、29期),我们分别测试分析了目前英特尔面向中低端网络通信市场推出的G41、D525嵌入式解决方案。它们已经被证明在目标市场中有很强的竞争力,被不少通信、安全厂商所使用。但在数据中心、骨干网等万兆网络环境中,x86平台的效能与稳定性仍然有待验证。本期我们就与上海交通大学的老师们一起,对英特尔5520平台在万兆环境下的应用效果进行一次测试分析。

上海交通大学是教育部直属、教育部与上海市共建的著名高等学府,也是国家 “七五”、“八五”重点建设、全国首批7所“211工程”和首批9所“985工程”建设的高校之一。该校在信息化建设方面始终走在前列,率先建成了采用WDM技术的跨城域校园网,为数万名师生提供高质量的网络接入服务。随着学校规模的不断扩大,上海交通大学在徐汇、闵行、七宝三个校区之间部署了带宽达10Gbps的校园网主干环路;三个主要校区和上中、法华校区间也采用了1Gbps链路构成网状拓扑结构,使每个校区与其他校区之间存在两条以上的冗余链路,保证了各个校区间互连互通;徐汇、闵行校区内主要汇聚点之间也分别实现了环状连接,保证了校园网运行的稳定、可靠。

做为中国教育和科研计算机网络(Cernet)华东南地区网、上海教育与科研计算机网(Shernet)和校园网(SJTUnet)的建设、管理单位,上海交通大学网络中心拥有很强的科研实力,长期担负着三大网络运营维护的艰巨任务。在此过程中,该中心充分发挥科研能力上的优势,独立自主地解决了许多难度较大的运维问题。我们在连载中就曾经提到,该校两年前在对校园网出口入侵检测系统的选型中,遇到了市售产品难以满足需求的窘况。在充分分析了业务需求的前提下,网络中心的老师选择了带领团队自行研发的方式,以多组x86服务器分布式处理的方式实现了对万兆链路的实时监测。这样的方式,不仅构建了一个开放的、可以承载多业务的科研平台,更将科研成果转化为实际的安全服务,为校园网的稳定运行提供了保障。

虽然上海交通大学校园网目前拥有多条出口链路、总计超过10Gbps的带宽,但在愈发丰富、模式愈发复杂的网络应用面前,也不是永不拥塞的高速路。目前,流量的可视化与可控性已成为网络中心老师们重点关注的问题,他们需要一个强大的应用流量分析管理系统,为运营维护乃至下一步网络建设规划提供准确的参考依据。经过细致地评估,老师们初步选定了连续两年获得计算机世界年度产品奖的Panabit应用层流量管理系统。不过,与大多数同级别通信、安全产品不同,该系统运行在x86而非MultiCore-MIPS或NP平台上,而老师们(或者说是大多数人)对于x86平台在万兆环境中稳定工作都没有太多信心。

来吧,就让测试去证明一切。

规格全面提升的5520平台

上海交通大学网络中心的老师们为这次测试准备了一台戴尔PowerEdge R710服务器,它是戴尔为第一代Nehalem-EP处理器平台及其后续Westmere-EP处理器平台设计的2U机架式产品。PowerEdge R710基于英特尔5520 IOH芯片(代号Tylersburg-36D)设计,提供了36个PCIe 2.0信道,最多支持两颗英特尔Xeon 5500/5600系列处理器,可以搭配英特尔ICH9或者ICH10使用。在英特尔尚未明确推出Sandy Bridge嵌入式解决方案的今天,基于5520芯片组的产品仍然是目前设备制造商与用户能够获取到的最高端x86平台。

得益于戴尔灵活的定制化销售模式,测试使用的这台PowerEdge R710配置了一颗英特尔Xeon X5690处理器。它支持SMT超线程技术(测试中关闭),具有6个核心、12个硬件线程,主频达到3.46GHz,最大的Turbo Boost频率高达3.73GHz,属于英特尔32nm Westmere-EP处理器家族中的最高端产品。这颗处理器中的每个核心都具有32KB的L1指令缓存和L1数据缓存及256KB的L2缓存,所有核心共享12MB的L3缓存。此外,Xeon X5690还通过两个6.4GT/s的QPI总线和另一颗处理器以5520/5500 IOH芯片通信,QPI总线为一个双向的并行总线,在X5690上,单向带宽为12.8GB/s。

由于集成了较高规格的内存控制器,单颗Xeon X5690可以支持3通道R-ECC DDR3内存,每通道又支持最多3个R-ECC DIMM。在使用能够支持的最高规格的16GB内存条的时候,每颗处理器可拥有144GB的总内存容量,整个系统(双路配置)则可达到288GB的最大容量。X5690支持的最大内存频率规格为DDR3-1333,不过当所有DIMM插槽都插满内存的时候,运行频率将会降低至1066。而本次测试使用的这台PowerEdge R710服务器配置了3条4GB容量的内存,运行在3通道模式。

英特尔Xeon X5690处理器通过6.4GT/s的QPI总线连接到5520 IOH上,而IOH目前主要的功能就是提供更多的PCIe总线连接,这正是网络通信产品所需要的。英特尔5520 IOH提供了36个PCIe 2.0信道和一个连接ICH芯片的ESI总线接口,这个ESI总线就是桌面级IOH芯片常用的DMI总线,其实质是一个x4的PCIe信道。而36个PCIe信道则以10个端口的形式提供,分别为8个x4的端口以及两个x2的端口。其中8个x4的端口可以聚合为4个x8或者两个x16端口,另外两个x2的端口则可以聚合为一个x4端口,但是不能与其余8个x4端口进一步聚合。我们知道,PCIe 2.0的每个信道可以提供5.0GT/s的单向传输速率(500MB/s),因此5520 IOH提供了巨大的IO带宽。在不需要这么多带宽的场合,英特尔也推出了一个简化版的5500 IOH产品,将PCIe信道数量减为24个。它的代号是Tylersburg-24,这一命名就体现出了PCIe信道的数目。

与时俱进的网络子系统

和桌面级与嵌入式产品不同,在服务器上,所有的高速设备都直接连接到IOH芯片上,而不是相对低速的ICH芯片,理论上减少了性能瓶颈。测试使用的PowerEdge R710服务器上提供了1条PCIe v2.0 x16插槽和两条PCIe v2.0 x4插槽,分别连接到3组顶级网络控制器。其中一组是一块基于英特尔82599EB芯片的英特尔X520双口万兆网卡,另两组是基于英特尔82576EB芯片的双口千兆网卡,一共提供了两个万兆接口和4个千兆接口。实际上,戴尔PowerEdge R710还板载了4个基于Broadcom网络控制器的千兆接口,但在测试中并未用做业务处理。

英特尔X520双口万兆网卡使用的82599EB是一个强大的网络控制器,是目前英特尔在万兆级产品中最顶级的型号。该芯片原生两个万兆接口,每个接口都可以支持128个TX/RX队列,并可以根据情况最多划分为64个RSS(Receive Side Scaling,接收方扩展)队列。此外,82599EB还支持MSI和MSI-X(Extended Message Signaled Interrupt,扩展消息告知中断)特性和一些与数据中心应用密切相关的高级功能。由于万兆环境下的数据传输需要巨大的带宽,82599EB推荐使用PCIe v2.0 x8或以上规格接口进行连接,否则可能会出现瓶颈。

英特尔82576EB也是比较强大的网络控制器,使用PCIe v2.0 x4接口进行连接,是82580出现前千兆级产品中的顶级型号。该芯片原生两个千兆接口,每个接口支持16个TX/RX队列,最多可划分16个RSS队列。和82599EB一样,82576EB也支持MSI和MSI-X,并支持VMDq、VMDc等虚拟化功能。在与英特尔服务器级Tylersburg IOH芯片搭配时,82576EB和82599EB可以通过I/O AT技术加速其DMA的传输性能。

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