本篇文章探讨了JavaScript基础教程之在荆棘中挣扎前进的NetApp，希望阅读本篇文章以后大家有所收获，帮助大家对相关内容的理解更加深入。

"

NetApp最近推出了FAS3200和FAS6200新一代产品。这一代产品相对上一代FAS3100以及FAS6000有什么区别？发生变化的形态背后有何隐情？NetApp为何迟迟不推出真正Scale-Out的集群或者分布式NAS？NetApp在固态存储方面的行为为何如此另类？本文将会解开一个个谜团。

怪诞之一：昙花一现

FAS3100系列才出来没多久，就被FAS3200替了。我记得那时候，其他厂商同档的存储系统基本都已经用了DDR2 667的内存以及PCI-E的总线，但是那时FAS3000系列依然使用PCI-X总线以及DDR2 400内存。终于在09年FAS3100升级到了DDR2 667以及PCI-E总线，同时硬件也做了改动，把NVRAM集成到主板，并且使用背板来连接两边NVRAM，消除了物理线缆。但是好像为时已晚，在NetApp从内存和总线方面追赶上别人之后，PCIE2.0、SAS2.0、8G FC时代都到来了，所以NetApp决定痛改前非，一次到位，推出FASx200，用新CPU、新总线、新接口、新硬件打造新一代硬件平台，FAS3100只能是昙花一现了。对此NetApp一定非常难受，阵痛隐隐。

怪诞之二：形态回退，接口转变

FAS3100是把NVRAM集成到了主板，并且双控各自的NVRAM之间的连线已经被固化到背板中去了，通过这种手段降低接触不良等造成的故障。但是FASx200系列好像又回来了，还是通过外置接口和连线来连接两边的NVRAM，不过这次不用Infiniband了，而就用最普通的10GbE，看来NetApp这次也随波逐流了。之前用10Gb的Infiniband来作为两边NVRAM同步的链路，看好的就是其低延迟，Infiniband我印象中应该是每Frame. 512Bytes，具体不记得了，总之比一般FC与以太网的帧要短，这样，在传输小message的时候可以获得更低的延迟，有利于NVRAM之间的纤细日志的同步，但是我一直也想不明白的一件事，帧短了，再传大数据块时候的开销也就增加了，被更多的EOF，SOF等占用带宽，这样岂不是降低了效率么？所以Infiniband有用40Gb版本的，比如Isilon等，用高速率来弥补大数据块时的低效率。那么对于FAS，是否有必要用Infiniband，从这次NetApp的策略来看，不管是从技术角度还是产品、商务角度，用个10Gb的Infiniband相比以太网来讲确实有点得不偿失。

但是为何他又回到外置连线形态了呢？我就很纳闷，怎么回事？一会东一会西的。但是仔细一看才知道个中辛酸啊。欲知详情，往下看。

怪诞之三：大胆创新——IO扩展模块的出现

IO扩展模块，这东西说实话，在中端存储里面还没有哪个厂商这么搞，基本上都是“IO扩展卡”的方式，而不是一整个模块。在高端存储里则屡见不鲜，比如IBM的DS8000里的IO扩展柜。而如今NetApp在中端里用了IO扩展模块，我就在想，是创新，还是迫不得已？但是仔细想来，确实没有什么迫不得已的地方，为什么呢？我们来看看这两张图。

大家可以发现，NetApp这次在硬件方面做了很大的创新，即可以在同一个柜子中插入两个控制器，或者插入一个控制器和一个IO扩展模块，两种模式任选一种。而且我估计，如果初始购置时选择了一柜双控制器的模式，后期如果想扩充，那么可以做到不停业务扩充，再上一个柜子，移出其中一个控制器，插入IO扩展模块，不过这个动作也是非常繁琐和复杂的了。这样做可以极大降低初始购置成本，不用预留任何空槽位。但是这样做也是有代价的，不言而喻，双控制器可能会不在同一个柜子中，那么NVRAM背板连接模式就不可能了。可灵活扩展的IO模块与NVRAM背板连接，要哪个？在FASx200这一代产品，NetApp不得不将双控的NVRAM再次用外接连线的方式来连接。不过这里澄清一下，如果采用一柜双控的模式，也就是NetApp所谓的“CC”模式，即两个Controller，那么可以不用在外面连线，背板上自动导通连线，而外面的接口自动被屏蔽，但是如果采用CI模式，即Controller-IO扩展模块模式，那么双控之间就必须从外置接口连接了。

这是不是又很难受呢？可以想象到NetApp的相关设计人员当初做出这个决定之后，他们的产品团队、市场团队、销售团队，是否一定也经历了阵痛去接受这个事实？如何向用户和市场去交代？不过说实话，可扩展的IO模块，这确实是个巨大创新了。在硬件方面创新，这对于一个软件公司来讲是很不容易的，不知道本次产品是否依然由Xyratex供货，硬件设计究竟是由NetApp主导还是Xyratex主导，这个我无从考证，但是不管怎么样，不容易！

怪诞之四：USB接口

包括IBM的Storwize V7000以及NetApp这次的FASx200系列，都留了USB口。理论上讲，所有厂商基本上都会留有后门来管理整个存储系统，这些特殊的接口和命令，用户不会知道。但是管理口也可以开后门，没必要用USB，我推测USB口被引入存储系统，可能与x86以及Linux Based操作系统在阵列系统中越来越普及有关，有一个USB，后续对OS的升级等会方便很多，根据资料显示，这次FASx200系列确实可以从外置USB驱动器来启动，用于紧急修复损坏的OS。其内部其实也是用一块USB接口的U盘来存放OS内核影像的。

怪诞之五：SSD和PAM卡，疯狂的Cache帝！

很早的时候NetApp就对SSD抱有疑虑，我记得当时其他厂商已经在着手开发动态数据分级了，而NetApp却犹豫的很，最终推出一块叫做Performance Acceleration Module（PAM）的PCI-E接口卡，专用于FAS3100系列。一开始其上是插DDR SDRAM内存条的。WAFL虽然是个很有特色的文件系统，但是其所存在的问题也是不可小视的，也就是经典的Sequential Read After Random Write的问题，也就是本来逻辑上连续的块，被WAFL处理之后底层却变得不连续了，这样在连续地址读IO的情况下，底层却表现为随机IO的行为，从而影响性能。PAM卡的推出可能也有这方面原因。

那么究竟为何NetApp不使用SSD来解决性能问题，或者自己也开发自动分级存储模块呢？我猜测，这与其WAFL的原理有很大关系。SSD这东西，所有人看到它的表现，一定都是竖起大拇指的，但是我估摸着唯独NetApp对SSD具有那么一点点排斥心理，为何呢？

首先，SSD的出现，让WAFL的那一套写加速算法颜面尽失，包括全重定向写、尽力整条写等针对机械磁盘所作的大量优化，随着SSD的出现，一切都解决了，那么WAFL这一套势必在SSD面前就显得白费了，这一定让NetApp很难受的，其实NetApp一直都难受，即便是使用机械盘，WAFL依然面临着Sequential Read After Random Write（SRARW）问题，早就在研究新架构的WAFL了，比如知否可以支持Raid5而不是Raid4，是否可以不再重定向写了等等。但是对于WAFL这样一个复杂而庞大的架构来讲，牵一发会动全身，不是那么好改革的了。

第二，WAFL的重定向写措施，会迅速耗尽SSD上的空余空间，懂点SSD的人都知道，SSD自己内部会去记录哪些page存有数据，哪些没有，这么做是为了损耗平衡算法，SSD内部也会有大量的重定向写操作，其做法与WAFL类似，但是WAFL这么做是为了方便的快照与整条写，SSD这么做纯粹是为了损耗平衡，不管怎么样，这两者是重复和部分冲突了。

本文由职坐标整理发布，学习更多的相关知识，请关注职坐标IT知识库！