取消
搜索历史

    EMC VMAX虚拟矩阵:RapidIO还是内存带宽?

    来源:存储网 2012-06-06 00:00NAS

    专题——《EMC World 2012 变革——IT+业务+你自己

    EMC World 2012已经过去一周,终于能够有时间静下心来,把来自各方面的信息和我们脑子中的理解沉淀一下。在这里笔者不想对整个大会做一个综述性的回顾,而是想从自己当时来不及整理的观点中,挑主要的方面进行讨论,与大家交流分享。

    接上篇:从EMC World看存储硬件更新换代

    存储网 Stor.com.cn 6月6日在本次大会之前的《EMC World 2012展望:XtermIO、雷电和VMAX》那篇存储新闻报道中,笔者已经对EMC高端存储系统新品VMAX 40K在虚拟矩阵方面的增强做过简单的分析。诚然以我的从业经验,没有亲手使用过高端阵列,也没有实际拆解过它们的控制器。从某种角度来说,我可能没有资格对EMC Symmetrix这种级别的产品“指手划脚”?

    记得数年前,笔者曾在某部队用户的机房里见到3个并排放置的满配EMC存储机柜,当时没有仔细查看里面具体设备的型号(也不太方便),因为我当时是去安装调试HP的服务器。不过另一方面,EMC自VMAX开始在高端产品的控制器中使用Intel x86服务器的硬件平台,这个对于我来说倒不是外行。

    无论专业与否,今天这篇文章里中笔者只是想提出自己的疑问,然后尝试着去解释它们。当然结论是开放式的,欢迎读者提出不同的意见,进一步与我们交流。

    接下来的讨论可能有些偏技术细节,您也可以直接点击今天这篇文章里第二页“全局 vs.分布式内存、紧耦合还是松耦合?”来查看我们的得出结论。

      VMAX虚拟矩阵:RapidIO还是内存带宽?

    上图已经在我们的EMC World 2012系列报道中出现了不止一次,笔者在这里先埋一个伏笔:

      左边VMAX 20K(即2009年最早发布的VMAX)的PCIe Gen1(一代)是否存在不妥?其控制器引擎使用的Xeon(至强)5400平台应该支持PCIe Gen2,那么EMC在这里出现了笔误吗?对此我在最初翻译国外的新闻时也注意到了,当时由于时间所限来不及多想,那么读者将会在今天这篇文章里中看到答案。

      从EMC VMAX 40K的官方文档中,我们看到每个引擎(Engine)的虚拟矩阵(Virtual Matrix)带宽为50GB/s,而最大配置——8个引擎的总带宽为400GB/s。一方面这个数字让我们惊讶,另一方面“Virtual Matrix Architecture is extensible to other standard interconnects”这句话又意味着什么呢?

    EMC VMAX(20K)引擎配置示意图

      笔者在去年VMAXe(即今天的VMAX 10K,20K的精简版)推出不久时写的评论中出示过上图,来自我的朋友——业内大作《大话存储2》一书的作者张冬。“集群节点互联带宽10GB/s”指的是VMAX 20K引擎中每个Director提供的2条虚拟矩阵接口(RapidIO)A和B具备5GB/s的带宽(一共还是冗余?)。前面我们看到VMAX 40K的50GB/s,我的第一感觉是:这意味着5倍的提升吗?两个数字之间有可比性吗?

      万一说这个图片的来源可能不是官方的话,我们还在VMAX的资料中看到过以下内容:

    “整个架构的全局内存读写Director之间的系统内部互连聚合带宽为80GB/s”——对应8个引擎一共16个Director。

      在当初VMAX的文档中,笔者曾认为80GB/s这个数字比较靠谱,如今VMAX 40K的400GB/s乍一看也是它的5倍。不过EMC现在可没说虚拟矩阵互连带宽提高5倍,因为虚拟矩阵(RapidIO连接)的数量只是从2个增加到4个

    进一步查看EMC的文档,我们注意到关于VMAX(20K)的虚拟矩阵带宽似乎有两种说法?

      上图中针对VMAX(20K)的24GB/s192GB/s这两个数字,显然与笔者刚刚列出的10GB/s和80GB/s不符,倒是和前面VMAX 40K对应的文档相比,新产品的带宽大致提升了一倍。

      尽管虚拟矩阵与RapidIO互联带宽“对不上号”,不过24GB/s似乎与VMAX(20K)引擎示意图中2个节点的内存带宽之和恰好一致,这只是个巧合吗?

      Intel Xeon 5400/5600平台内存带宽回顾

    Intel Xeon 5400服务器/工作站平台芯片组示意图(红圈部分就是我们接下来要讨论的)

      这里首先有点意外的收获:Intel 5400 MCH北桥可以提供8个PCI-E x4 2.5Gbps连接,加上连接6321ESB ICH南桥的一个PCI-E x4,一共是36个PCIe lane。前者还可以组成4个PCI-E x8或者2个PCI-E x16,但应该只有用于连接显卡的x16插槽才支持PCI-E Gen2的5Gbps速率,否则就是PCIe 1.0的带宽。

      看来上文在EMC资料中列出的VMAX 20K是PCIe Gen1,应该就是这个原因。联想到当年的硬件平台,Intel 5400只是在5000X/P基础上的一款升级产品,并不像Xeon 5500那样有大的架构改动。

      为了进一步印证自己的判断,我们找出了当年Xeon 5400平台刚发布时撰文曾使用过的资料。首先是17-21GB/s(533-667)的内存带宽,这是在四通道全缓冲内存(Fully Buffer DIMM)的情况下。其实5400B版本还能够支持FBD DDR2 800MHz的内存频率(5400A不支持),对应内存带宽可达25.6GB/s。那么上文中VMAX(20K)引擎示意图中的12GB/s又指的是什么呢?

      在讨论内存带宽的同时,我们还要考虑前端总线(FSB),这个在Xeon 5500及之后整合内存控制器的CPU中已经不存在的概念。Intel的Xeon 5000系列芯片组(包括用于服务器的5000P、V和用于工作站的5000X)以及增强的5400采用了两条FSB的设计,而之前的SMP多处理器平台都是共享前端总线的。上图中所示的1067/ 1333MT/s和内存总线的位宽都是64bit,对应的FSB带宽为8.5GB/s和10.6GB/s。5400B最高可支持1600MHz的高端Xeon 5200/5400 CPU,FBD DDR2-800内存就是为了搭配它,此时前端总线带宽达到了12.8GB/s,也就是单个处理器访问内存的最大带宽

      最后一个数字就比较接近VMAX 20K中的每个Director 12GB/s了。可能有人觉得2颗CPU同时访问内存时的带宽会超过这一水平?从理论上说确实如此,但在实际应用中,每一个CPU分别并发访问不同内存页面地址中数据的情况有多少?或许EMC认为这个数值相对实际一些吧。

      还有一点不得不指出,VMAX 20K引擎使用的四核Xeon CPU主频为2.33GHz,万一对应Intel产品线中的L5410——支持1333MHz而不是1600MHz FSB的话,12GB/s恐怕就只是一个理想(理论)中的数字了?

      写到这里,可以说从前一张图片开始的一段话进入了技术细节的讨论。当然万一只是为了2009年发布的VMAX(20K)我们显然不会下这么大功夫,因为接下来要以此为基础来看VMAX 40K。

    Intel Xeon 5500/5600处理器+5520芯片组(IOH)服务器平台示意简图

    需要说明的是,上图中的CPU是Xeon 5500而不是5600,笔者没有花太多功夫去找后来的资料,而是使用了手头早期的。因为Xeon 5600在5500基础上的改动相对不大,功能上主要是增加了6核,L3 Cache由8MB提升到12MB,其它方面如QPI连接速率以及芯片组主板平台都是沿用上一代的。

    Xeon 5500/5600处理器集成的三通道DDR3内存控制器,支持1333、1066和800MHz内存频率,根据每通道安装的内存数量而定。那么根据VMAX 40K每个引擎最大256GB缓存内存(单一Director控制器128GB),按今天的情况有可能是8条16GB或者16条8GB?万一按照1066MHz的频率来计算,此时每个处理器的理论内存带宽正好是25GB/s。另外一个CPU还能够通过QPI连接访问另一个CPU控制的内存,这里QPI的的理论带宽也是25.6GB/s

    每个Director 25GB/s内存带宽,又对应上了EMC资料中一组VMAX 40K引擎50GB/s的虚拟矩阵带宽。至此我们基本能够证明:VMAX 20K和40K那个192GB/s和400GB/s的虚拟矩阵总带宽,指的应该就是本地内存访问,而不是引擎之间的RapidIO互连

    那么这个看起来“很好的数字”对用户有多大实际意义呢?联想到一位业内资深人士在EMC World 2012之后吐槽中的一句话——“EMC公布的性能指标,在实际应用中能达到10%就不错了”,当然这个评论可能不够全面,每家厂商的市场宣传中也都或多或少会有类似的“水分”,但却引发了笔者进一步思考VMAX等高端存储互连效率的兴趣...

    接下页:全局 vs.分布式内存、紧耦合还是松耦合?

    (文章为作者独立观点,不代表存储网立场,版权疑问请联系客服。)
    关于我们| 隐私条例| 版权申明| 联系我们

    2018-2022 Copyright © Stor.com.cn