实验室报告 Cisco UCS 的测试显示了吞吐量约束

日期: 2010-04-06 作者:Rivka Gewirtz Little翻译:曾少宁 来源:TechTarget中国 英文

根据测试实验室的结果,Cisco Unified Computing System (UCS) 架构有严格的带宽限制,它会限制公司允许的吞吐量最大值。这个实验室也宣称 UCS 实际上不利于虚拟化环境所需要的自动化操作。   一位不愿透露姓名的 Cisco 竞争对手委托 Tolly Group 进行了这个关于 Cisco UCS 的测试。Tolly 指出,虽然 Cisco 承诺 UCS 刀片有 40 Gbps 的容量,然而在测试过程中实际的吞吐量只有区区的 27 Gbps。

  “最近几周,我们受邀于一个 Cisco 以前的刀片服务器伙伴,对 Cisco UCS 网络吞吐量进行测试并生成一个后续……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

根据测试实验室的结果,Cisco Unified Computing System (UCS) 架构有严格的带宽限制,它会限制公司允许的吞吐量最大值。这个实验室也宣称 UCS 实际上不利于虚拟化环境所需要的自动化操作。

  一位不愿透露姓名的 Cisco 竞争对手委托 Tolly Group 进行了这个关于 Cisco UCS 的测试。Tolly 指出,虽然 Cisco 承诺 UCS 刀片有 40 Gbps 的容量,然而在测试过程中实际的吞吐量只有区区的 27 Gbps。

  “最近几周,我们受邀于一个 Cisco 以前的刀片服务器伙伴,对 Cisco UCS 网络吞吐量进行测试并生成一个后续的比较报告。结果显示,至少Cisco 外部的基于交换机的 UCS 架构的局限性是令人大开眼界的,”Tolly Group 的创始人 Kevin Tolly 写道。

  熟悉 UCS 分析人员和工程师都一致认为 Cisco Unified Computing 架构 —— 这也包括刀片、机架、结构互联和扩充器、管理软件和网络适配器 —— 限制了带宽,然而竞争对手的技术却不会出现相同的状况,但他们争辩说所实现的吞吐量已经很好地支持了现在的应用。他们也提出竞争对手的产品也有其它的缺点。

  “这并不是一个实际的测试实例,”一位工程师说道,他使用 Cisco 产品组网,但还没有实现 UCS。“没有人能在一秒钟用完 10 Gb 的带宽。”他说,他自己的系统有 85% 是虚拟化的,运行在一条 4 Gb 的上行主干网,从来没有遇到瓶颈问题。

  Cisco UCS 测试:带宽限制可能的位置

  Tolly 的测试是专门针对统一计算架构的许多吞吐量问题点,测试是基于机架上的服务器比激活的上行链路多这样一个概念,而且它们还依赖于一个性能低下的外部交换机。

  一个 UCS 机架可以安装8台服务,每一台服务都有自己的 10 GbE 聚合网络适配器,但机架的结构互联却只为4条激活的连接顶级机架交换的上行链路。

  “虽然刀片服务器理论上总共有 80 Gbps 的容量,但它们都必须通过 UCS 2104 Fabric Extender 的最多4条 10 GbE 上行链路端口与顶级机架的 UCS 6120 XP Fabric Interconnect 交换机通信,”Tolly 写道。“UCS 机架能够接受多一个结构扩充器,但是 Cisco 文档清楚地指出第二个单元只用于故障恢复,并且不能够用于提供 80 Gbps 的上行链路连接。”

  Cisco 统一计算架构是静态的吗?

  Tolly 在他的报告中指出,当吞吐量实际上由于“8 台服务器争用4条链路”而减半时,这个系统将不会自动地在需要时给服务器提供 40 Gbps 的带宽。

  “Cisco 文档告诉我们一个特定的服务器被‘钉’在一个特定的上行端口。它被牢牢地‘钉’住了,不能移动,不能修改,最终用光,”他写道。

  在深入地阅读 Cisco UCS用户指南后,Tolly 发现下面的论据并不充分:“这个阻塞决定了哪些服务器流量通往互联结构上的哪个服务器端口。这个阻塞是固定的。你不能够修改它。结果,你决定一个机架的合理带宽分配时必须考虑服务器的位置。”

  根据 Tolly 的观点,这个“钉住”的问题不仅与自动化虚拟机迁移的概念相背,它还会导致更大的带宽限制问题。

  Tolly 首先正面测试了2台各自“钉住”不同上行链路的物理服务器之间的吞吐量。由于缺少双向 20 Gbps 带宽,他测试了 16.7 Gbps 的应用吞吐量,这还不包括更低的协议层。

  但当相同的测试在2台绑定到同一条上行链路的物理服务器之间进行时,在流量传输到顶级机架交换机时这2台服务器的测试结果存在争议。

  “吞吐量总和降低到 9.10 Gbps,并且远低于可能值 20 Gbps,”Tolly 写道。“更进一步的测试一般会显示最佳的吞吐量将在连接到四条不同链路的两对服务器进行1到2和3到4的通信时实现。这样我们会得到大约 36 Gbps 的吞吐量。这个结果非常好,但你其余的服务器呢?”

  当 Tolly 增加了另外两台真实的服务器并要求额外的带宽时,带宽争夺的后果就是性能大大下降。

  “我们到达所要求的额外 20 Gbps 带宽的极限值时,Cisco 的总体系统吞吐量会下降到仅为 27 Gbps,”他写道。

  Cisco UCS 带宽限制会演变成一个真正的问题吗?

  当 Cisco 着手设计 UCS 时,开发人员并没有预见到虚拟化应用的速度及它的带宽需求,Gartner 的研究副总裁 Joe Skorupa 说。而现在, Cisco UCS 超出了大多数系统的需求。

  他说,“随着虚拟化在未来 18 个月中的发展,带宽需求会进一步增加,”他补充道,最终 Cisco 将不得不解决这个问题。

  Skorupa 说,Cisco 如果不作这类声明,它在开始时关于这个问题的相关设计会做得更好些。毕竟,在这方面,这个网络巨人还是“新手”,在与对手的竞争过程中,它有可能将筋疲力尽。但他说很可能 Cisco 的下一个设备周期将会解决这个问题。

  Cisco 并没有回应 Tolly 的测试结果,它说:“Cisco 并没有授权或主动参与 Tolly Group 的测试,因此我们不会接受或验证它的结论。而且,Cisco 无法评论由其它供应商资助的测试报告。”

  Tolly 曾经联系 Cisco 参与测试过程,但 Cisco 拒绝了。

翻译

曾少宁
曾少宁

TechTarget中国特约技术编辑,某高校计算机科学专业教师和网络实验室负责人,曾任职某网络国际厂商,关注数据中心、开发运维、数据库及软件开发技术。有多本关于思科数据中心和虚拟化技术的译著,如《思科绿色数据中心建设与管理》和《基于IP的能源管理》等。

相关推荐