在上一篇“大数据与存储系统：分散还是集中的选择？”的末尾，笔者已经预告了本文要讨论的内容，是关于NetApp推出基于E系列平台的产品与解决方案，包括E5400存储系统，还有与Hadoop应用的结合等。
视频解决方案、分散与汇聚的折中
NetApp E5400存储系统，来自从LSI收购的Engenio部门
从NetApp的官方新闻稿中，我们简单总结出如下重点：
1.NetApp E5400是一款第六代存储系统，针对高带宽应用、极高存储密度及超长运行时间而优化。
这里面的“第六代”让我们感到有些困惑，在“NetApp收购Engenio 双线出击求增长”一文中我们曾提到E7900（原Engenio 7900，对应IBM DS5300）的控制器设计，采用了LSI已经发展到第七代基于PowerPC处理器的XBB2架构。那么上面的“第六代”又是从何算起呢？我们暂时没有得到来自NetApp的更多信息。
对于“高带宽”和“存储密度”（4U规格将控制器与驱动器集成在一起），我们将在下文中进一步分析。而“超长运行时间”则代表E5400具备99.999%（5个9）的可用性，这一点与定位中端存储系统的E7900相同，低端的E2600（原Engenio 2600，对应IBM DS3500）则没有表示能够达到这个水平。
2.NetApp为联邦政府量身定制提供了一套存储解决方案来处理其对全动态视频的特殊要求。利用NetApp E系列平台中新增的 E5400，并与Quantum公司的StorNext数据管理解决方案相结合，使其成为对要求高带宽的全动态视频进行捕获及分析的理想之选。
Quantum StorNext文件系统 + LSI 2600-HD（如今的NetApp E2600）联合解决方案
NetApp E5400加上昆腾StorNext SAN共享文件系统，组成的针对（高清）视频采集/编辑应用解决方案，让我们想起了以前给大家介绍过的LSI Engenio 2600-HD（现已更名为NetApp E2600-60）。同样是在4U机箱中可以容纳60个3.5英寸驱动器，二者之间的具体区别我们稍后就会谈及。
3.Hadoop存储解决方案是构建在现在正发售的NetApp E2600 产品之上的一套预配置的模块化产品。作为E系列平台的一部分，这套解决方案具有一个16到32节点的基础配置。它所具有的系统规模设定与验证功能让客户能够省去不必要的猜测，在几小时内完成 Hadoop 集群的部署，而不像从前那样需要花数星期的时间。
NetApp在谈到的“Hadoop存储解决方案”，对应的产品似乎不是新发布E5400而是大约一年前推出的E2600。这样由SAS连接Engenio阵列共享DAS的理念，在外置RAID控制器的存储系统产品中，倒是和Hadoop分布式文件系统（HDFS）通常搭配JBOD + SATA硬盘的廉价存储方式相对较为接近。
NetApp E2600——8个SAS主机端口配置时，非冗余连接示意图（也可实现4台服务器分别到2个RAID控制器之间的故障切换连接）
NetApp E2600的双控制器最多可以提供8个（每控制器4个）使用SFF-8088连接器的miniSAS（wide-port，其中各包含4条6Gb/s SAS连接）主机接口。在某种程度上，可以相当于将HDFS方案中连接到服务器SAS HBA卡外部端口的JBOD扩展柜“集中”起来。并增加了RAID硬盘冗余和缓存保护等RAID卡才具备的功能，同等容量带来的成本上升应该明显低于Isilon那样的集群NAS存储系统。从连接性的角度如此，那么要是从容量和性能的角度来看呢？这就是我们接下来要讨论的。
NetApp E5400定位？带宽/驱动器数量相匹配
NetApp网站上的E系列产品线规格对比（部分）
如上图，笔者将准备进一步展开的技术规格点标出了红框。
首先是60个驱动器。我们知道最近NetApp E2600支持的驱动器数量，已经从去年LSI Engenio 2600发布时的96个增加到192个。那么按照传统的眼光来看，支持驱动器较多的阵列除了容量之外，往往还能提供更高的IOPS和带宽性能（主要针对同一时代的产品而言，当然这里的E2600属于例外）。E5400的定位是否存在问题？
其实早在Engenio部门被NetApp收购之前，LSI就相对低调的推出了2600-HD这款产品（如今已成为E2600-60这一款子型号）。为什么这样说呢？因为LSI Engenio的主要业务都是来自IBM、戴尔等OEM客户，而2600-HD在NetApp收购Engenio之前却没有立即被这些厂商转销，而是被LSI加上StorNext、GPFS/Lustre这些文件系统等组成行业解决方案。
IBM上周刚刚推出了OEM自NetApp E2600-60的System Storage DCS3700存储系统，专门针对高性能计算和流媒体环境的应用需求。
有国外媒体误以为DCS3700对应的是E5400，估计是由于二者在机箱外观上较为接近，都是5个可以从前面装载的12硬盘位“抽屉”，并可以在保持活动访问的情况下添加驱动器。尽管DCS3700属于DAS/SAN块存储设备，但IBM却主要是为了搭配自己的GPFS（通用并行文件系统）来支持可以大规模扩展、分布式的企业级宽范围基于文件存储的应用。
NetApp E2600-60机箱（除了控制器之外）的特点与E5400大致相同，都是4U高密度可容纳60个3.5英寸驱动器，不过它的后端还能级联2个JBOD机箱最多扩展到180个驱动器。这里我们注意到一个问题，E2600-12（2U 12个3.5英寸驱动器）/ 24（2U 24个2.5英寸驱动器）/ 60的性能并不会完全随着驱动器数量的增加而线形提升，特别是带宽。笔者以前曾经介绍过，IBM DS3500/Engenio 2600在激活Turbo性能模式选项（在戴尔MD3200系列上称其为High Performance Tier，高性能层级）之后的最大持续读/写带宽分别为4,000MB/s和2,200MB/s，见下图。
上面的表格列出了DS3500和IBM其它型号低、中端存储产品的性能比较，中间红色的两列分别为DS3500的基本和打开了Turbo性能升级选件的型号。
LSI Engenio还曾使用10台2600-HD（不带扩展柜），组成了专门针对高性能计算的DenseStak（StorageStak）集群存储方案，最大持续磁盘IOPS和带宽分别达到27万和40GB/s。不过我们认为该方案也未能充分发挥出600个驱动器所能达到的带宽。以高清视频后期制作为代表的带宽密集型存储应用，通常使用大容量高性价比的3.5英寸7200rpm SATA/SAS驱动器，单块硬盘外圈读/写带宽早已超过100MB/s。如果以RAID 5（8+1）这样的典型情况为例，一个机箱中60个硬盘实现6,000MB/s左右的顺序读带宽理论上完全是可行的（顺序写还要受处理能力等因素影响，相对复杂些）。
NetApp如今推出的E5400，可以说就是这样一款专门为容量密度和高带宽定制的产品。上图中我们看到了E5400的吞吐量（MB/s）指标，以及仅支持2TB容量的NL-SAS（近线SAS）一种驱动器类型。尽管定位更高的E7900（对应IBM DS5300）可以实现更好一些的顺序读性能，但以其最多支持480个驱动器的设计，只配置60块硬盘时的性价比肯定没有E5400合适。
E5400使用了什么样的架构设计来实现“带宽/驱动器数量相匹配”呢？仍然沿用E2600、7900的PowerPC还是换成了Intel x86处理器？
E5400架构猜想：Xeon C5500 + Intel 5520 IOH？
NetApp E5400引起我们注意的其它规格，还包括最大24GB缓存和16个8Gb/s FC主机接口，也就是每控制器最多12GB（3条4GB内存？）和8个8Gb/s光纤通道。这让我们本能地想起集成3通道DDR3内存控制器的Intel Xeon 5500/5600，还有加入了存储特性的Xeon C5500/3500系列CPU。进一步分析，究竟是前者还是后者呢？别着急，尽管这仍属于猜测，但我们觉得距离真相已经越来越近了。
NetApp E5400技术规格（部分）
查看E5400的更多技术规格，可以发现它的控制器设计为带有自动I/O路径故障切换的Dual-Active（双活动，Active/Active）模式；另外，双控制器的数据缓存互为镜像并且提供电池备份（BBU）和离线保存到闪存的特性。这2点都与Engenio家族的E2600和E7900相同。既然先前我们已经判断E5400使用了x86平台，那么如果使用了单独的RoC/RAID卡及其本地缓存，被保护的“镜像”缓存容量写成24GB（系统内存）显然不合适。如此则表明E5400的RAID功能，很可能是通过带有XOR/P+Q硬件加速和异步内存刷新（ADR，专门用于缓存保护）的Xeon C系列处理器来实现的。见下图：
Intel在2010年春季北京IDF上介绍的至强C5500/C3500架构设计。上图右下方提到了CPU的封装为LGA1366，这样理解硬件上都是可以支持3通道内存的，那么上面的“1-3条内存通道”意味着什么呢？
接下来我们尝试进一步缩小范围。
在Xeon C5500/3500系列CPU的DataSheet中，除了下面3款LC3518、LS3528和Celeron P1053（赛扬，貌似不属于至强系列哈？）支持双通道内存之外，其余的都是3通道。我们曾分析过，IBM中端存储系统Storwize V7000使用的CPU应该是2.13GHz的Intel Xeon EC3539，具备3通道内存控制器而实际配置为双通道（2条4GB）DDR3 1066MHz内存。Intel在上表中似乎还有点笔误，不知读者发现没有？毕竟这样的细节技术文档没有一定需求的人很少去认真阅读。
下面，暂时先假设NetApp E5400使用的也是同一款——Xeon EC3539，在性能（主要是带宽）上能够满足需求吗？我们先参考一下IBM Storwize V7000的控制器结构图。
E5400的控制器与Storwize V7000相比。除了内存配置为3通道、容量不同之外；主机接口部分没有2个GbE（千兆以太网，灰色部分）iSCSI，也就是说相当于在PCIe x8总线连接一个FC控制器（红色）之外，左侧一排浅绿色的“前端 – 可插拔PCIe卡”部分连接另一个4端口8Gb/s光纤通道子卡（就像E2600选配的HIC主机接口子卡那样）。
至于后端的驱动器连接部分，尽管NetApp E5400不需要向外提供连接JBOD扩展柜的SAS端口，但仅凭一颗8端口SAS控制器加上36端口SAS扩展器的组合，也无法支持阵列内部的60个驱动器。增加SAS控制器芯片？别忘了还需要有一个PCIe x8连接到背板用于双控制器之间的NTB（非透明桥接，实现缓存镜像等数据交换），那么在此处48信道的PCIe Switch（交换）芯片作为I/O连接中心就有点捉襟见肘了。
虽然Intel 3420 PCH芯片（相当于x86架构中传统意义上的南桥）也可以提供8个PCIe Gen2 @2.5GT/s信道，但一方面它们只有PCI-E 1.0的带宽，还要受限于CPU to PCH之间的DMI连接（实际应为PCI-E 1.0 x4），使得这部分I/O相对不适合高速通信。通常用于像Storwize V7000那样的1Gb/s iSCSI以及管理网口等功能。
基于Xeon C5500/3500的平台加上Intel 5520 IOH（芯片组）提供更多的PCIe信道
Intel Xeon C5500/3500平台还有一种I/O增强的设计，即添加一颗Intel 5520 IOH芯片组专门用来提供更多的PCIe信道。Xeon C处理器通过专用的QPI高速通道连接IOH，这样就避免了Storwize V7000使用PCIe x16连接CPU和PCIe Switch造成的I/O信道“浪费”（对冲），以至于只有32个lane用于向外连接。而上图所示的方案，既释放了CPU自带的PCI Express 2.0 x16，再加上Intel 5520提供的36 lane PCI Express 2.0，这时PCIe信道数量就不再是问题了。
不过根据前面的表格，Xeon EC3539处理器没有提供QPI连接，这样它就无法支持5520 IOH和双处理器（DP）设计。那么在以上推测成立的前提下，我们只能将目光投向剩下的5款Xeon C5500系列。由于NetApp公开的资料相当有限，无法进一步判断E5400的每个控制器是否为双CPU配置，但它的处理能力不应低于Storwize V7000，因此双核心的Xeon EC5539可以基本排除？
我们再设想一下，如果是2个8端口6Gb/s SAS控制器芯片（如：LSISAS2008），分别向下连接36端口6Gb/s SAS扩展器（如：LSISAS2x36）。每组SAS Controller和Expander之间使用6条SAS Link（单链路理论带宽600MB/s）用于互相通信，而扩展器余下的30个SAS Link（2个Expander就是60）正好对应60个驱动器。
按照上面的推测，控制器前后端带宽都能比较好的发挥出来，而且单一控制器的顺序访问（至少是读）性能就可以达到6,000MB/s。那么还有别的疑问吗？当然，如果E5400单控制器设计性能没有这么高，是否也可以像E2600那样实现双控制器的负载均衡呢？
戴尔PowerVault MD3200/3200i的控制器结构图，左边是iSCSI主机接口的MD3200i，而右边为6Gbps SAS主机接口的MD3200（相当于SAS主机接口的NetApp E2600和IBM DS3500）
我们回想之前LSI Engenio存储系统的设计。以E2600为例，每个控制器的LSISAS2116 RoC（RAID-on-Chip，片上RAID）专门有一条被称为Alt Ctrl（功能控制）的6Gbps SAS x4链路，通过SBB 2.0背板与另一个控制器的LSISAS2x36扩展器相连，直接实现对所有驱动器（包括级联JBOD扩展柜中）的可访问性。
尽管我们无法确定“Alt Ctrl”与双控制器负载均衡之间的必然联系，不过可以大致分析出一点：如果NetApp E5400的也设计有Alt Ctrl数据通道，我们前面猜想的2个8端口6Gb/s SAS控制器很可能无法满足需要。这时可以考虑替换为16端口的LSISAS2116当作控制器来使用，就像LSISAS9200-16e/9201-16e外部端口6Gb/s SAS HBA卡那样。
总结在E5400身上的改变之处——控制器更换为Intel IA架构早在LSI Engenio被NetApp收购之前就已经有所透露，而且这几乎也是整个企业存储行业的大势所趋。E5400专门针对高容量密度和带宽型应用而定制，仍然没有像IBM Storwize V7000那样加入自动精简配置（Thin Provisioning）、自动分层存储、存储虚拟化等高级软件功能，这可以说是Engenio的不变之处。
最后一页，我们再来谈谈NetApp E2600的升级，当然也包括IBM相关产品的同步更新。又些什么变化和疑问呢？
E2600升级：192个驱动器、万兆iSCSI
在前文中，我们已经不可避免地谈到支持180个驱动器的NetApp E2600-60（原LSI Engenio 2600-HD），由于有它在前，我们对E2600的驱动器数量增加到192个并不感到多么意外。同时加入的新特性还包括可选4个10Gb iSCSI主机接口（每控制器2个），其实只是将2600的HIC（主机接口控制器）子卡更换为双端口万兆以太网控制器罢了，本来就有厂商提供可选2 x 10GbE或者4 x 1GbE部署的单芯片方案。
不过笔者曾经认为，支持192个驱动器对于2.5英寸24盘位的2600-24控制器/JBOD扩展柜来说相对不算复杂，将NetApp DE5600（JBOD）级连的数量从3个增加到7个就可以了；而支持12个3.5英寸驱动器的2600-12，则意味着DE1600需要从原来的7个增加到15个。这样可能会带来什么不良影响吗？
IBM System Storage DS3500低端磁盘阵列与NetApp E2600同步升级，戴尔则只推出了万兆iSCSI接口的PowerVault MD3600i/3620i（支持3.5/2.5英寸驱动器），暂时没有增加驱动器数量。上面截自IBM DS3500最新的Data Sheet文档，现在它也能最多支持到192个驱动器和15个EXP3512扩展柜（或者7个EXP3524）
最近升级之前的IBM DS3500（3.5英寸驱动器）满配连接示意图，一共8个盘柜，最上面的是控制器所在的主盘柜DS3512，其余7个是扩展柜EXP3512
在这个示意图中，我们看到厂商推荐左侧的控制器从上到下级连JBOD，而右侧控制器则先连接最底下的JBOD，而后再向上级连。这样做的好处是什么呢？
由于每台JBOD扩展柜的核心就是位于ESM（环境服务模块）上的LSISAS2x36——36端口6Gb/s SAS扩展器芯片，因此每增加一个JBOD级连就意味着数据流多经过一个SAS扩展器，通信延迟则会相应增大。那么上图中理想的拓扑情况就是：控制器柜下面的4个JBOD使用左边的链路，而另外4个JBOD（也就是靠近底下的）通过右侧控制器的扩展端口来连接。如果冗余链路的一侧由于故障而中断，通信路径和延迟就会受到影响，最坏的情况是一个RAID控制器损坏，只剩下左/右一边的级连数据路径可用。
尽管上图列举的是SAS 1.0规范（即3Gb/s SAS）中的不足，但“超过4个JBOS深度时I/O延时偏高”的问题如今依然存在，只是程度不同罢了。我的同事，CBSi企业解决方案中心首席分析师张广彬在“Storwize V7000剖析：走进存储系统的SVC”一文中就曾提到：“Storwize V7000的扩展能力是以盘柜为单元来计算的，两条SAS链路各自管理5个盘柜，加在一起是10个盘柜。如果都用24个2.5英寸驱动器的盘柜就达到支持驱动器数量的最大值240个；如果都用12个3.5英寸驱动器的盘柜则仅能支持120个驱动器。”
相比之下，如今NetApp E2600/IBM DS3500在配置192个3.5英寸驱动器时最多可能的JBOD级连数量达到了15个，那么从控制器到最远端JBOD的延迟大小可想而知。如果在这种情况下跨不同JBOD中的硬盘做RAID，或许达不到理想的性能吧？
有人说，这里的192个驱动器在投标时会增加有利因素（技术规格中的扩展性）。我们在此不想否定它在扩大容量（翻倍）方面的意义，但用户也不要指望性能总是随着驱动器数量一同提高。另外我们建议在购买和部署之前，还是应该参考一下厂商提供的“最佳实践”等技术文档吧？
