在荆棘中挣扎前进的NetApp
作者 冬瓜头 | 2010-12-30 07:24 | 类型 行业动感 | 28条用户评论 »
|
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这么做纯粹是为了损耗平衡，不管怎么样，这两者是重复和部分冲突了，另外，WAFL不断的写到空余位置，那么SSD上的“曾经写过多少”这个高水位线就会迅速达到顶峰，SSD内部空余空间迅速降低到最低值，严重影响SSD的性能，而WAFL的作用原理又不可能实时的将SSD中的“垃圾”块回收回来，因为WAFL从本质上讲可以认为是无时无刻不在产生垃圾（重定向写之后，以前的块便是空闲块了，但是SSD却无法感知文件系统层面的空闲块，依然认为是有用块），它根本来不及回收的，况且WAFL内部的两层FS之间已经为了忙活着回收空间而做了大量复杂流程了。如果说SSD让WAFL的优化变得价值全无，这一点还可以容忍，但是如果WAFL想用SSD而眼看着效果不好，那么就真的没治了。 第三，我们退一步讲，就算WAFL会很快耗尽SSD的空余空间到最低值（也就是SSD厂商隐藏的那部分为了保证性能而预留的空余空间，比如100GB的SSD其实是有128GB物理空间的），效果再不好，但是也比机械硬盘要快的，所以NetApp只能退而求其次将就着上SSD了。还有最重要的一点，别忘了，SSD目前的容量还太小，如果上SSD，会有两种用法，一种就是直接将SSD当做普通盘来用，做Raid，做Aggregate，做WAFL，然后做Volume，做Lun或者目录的Exports。但是这种做法适用的场景很少，比如一部分小容量的数据却要求极高的访问速度，那么没有问题，这种做法可以满足。但是如果遇到短尾型应用的数据访问场景，大量的数据却只有一部分为热点，那么此时你将所有数据都放到SSD上，显然是得不偿失，此时自然就需要有一种动态的细粒度的热点数据分级解决方案了，这也是目前几乎所有存储厂商都在搞的技术，而且主流厂商也都推出了各自的产品了。而我们回来看NetApp，她何尝不想推出自己的动态分级方案？她很难受，为什么呢？WAFL如果是老虎，那么NetApp可以说已经骑虎难下了。想在WAFL上引入动态分级子模块，不是那么容易的。动态分级子模块包含至少两个亚模块，一个是热点数据监控、统计模块，另一个是数据迁移模块。监控和统计子模块，可以作为一个旁路模块存在，不会对现有的任何FS架构产生太大影响，这个WAFL做起来没有问题，但是数据迁移亚模块，这对WAFL来讲，又很难受了，WAFL不按常理出牌，与其他传统FS不同，总是去重定向写，改一改就动全身，所以从技术上讲，实现动态分级还是太费劲，风险也很大，需要测试很长时间，所以我推测这也是NetApp迟迟没有推出动态分级的可能原因之一吧。 所以我估计，NetApp一开始就定下了基调，SSD目前来讲就作为大缓存的角色而存在。可以看到本次FASx200系列，最高规格的FAS6280已经可以使用8TB FLASH的PAM卡了，当然，需要插多块PAM卡来堆叠成这么高的容量，而且两个控制器上的PAM卡规格必须对称，成双成对出现，而不能够只插一组卡让全局使用。 但是后续如果NetApp真的推出了动态分级功能，那么势必等于抽了自己一嘴巴。除非有很好的说辞，至于说辞，编造起来比技术要容易的多了，这个我们就不必担心了。但是总归还是很难受的。在今年年初，NetApp的Tom Georgens提出“分级存储终将走向死亡”的论断，我认为，这句话绝对是正确的，不过时间是个问题，当SSD成本不断降低，技术不断提高，容量逐渐变大之后，这种过渡的动态分层肯定走向死亡，所以这句话是有退路的，就得看你怎么理解了。但是短期来看，分层是有必要的。PAM卡只对读加速，而不对写加速。其实缓存本身就是一种动态分层，所以这个论断显然带有强烈的主观色彩了。 怪诞之六：FlexShare与FlexCache的推广 2年之前这两个技术还都处于潜伏期，如今被NetApp推到水面高调示人了。同样，还有Multistor，为了应对云时代，这些之前似乎无关紧要的功能，如今却变得很有噱头。FlexShare之前基本没人用，它属于一个QoS模块，可以设定特定的资源在访问的时候能获取多大的优先级，在大规模云基础架构中，QoS显得颇为重要。FlexCache则是一种类似CDN的远程访问加速解决方案，这在一些IPTV或者视频编辑领域颇有作用。而MultiStor，则属于一种存储虚拟化的范畴，这个虚拟化不是指虚拟化其他厂商的存储空间，而是将一台物理设备虚拟成多台逻辑设备，类似虚拟机，这在存储系统中比较少见，尤其是中端存储，就更少见了，据我了解NetApp是第一家在中端存储实现这种虚拟化功能的厂商。这个功能被包装为更被云所认可的名词，也就是“Secure multi-tenancy”，安全多租户。这种虚拟化正是云梭需要的，而且被加入了“安全”二字，也更能往“云安全”上靠，噱头十足！所以说，这一点并不算怪诞，应该是见怪不怪了，其他厂商也都在这么搞噱头。 怪诞之七：NetApp的集群NAS呢？ Ibrix、3PAR、Isilon、Compellent等这些Scale-out架构的存储系统，该收的都被收了。NetApp也收过，他很早就收购的Spinaker，是一家做Single Namespace的文件系统的厂商，基于Spinaker而搞出来的NetApp GX系列，一直不给力。究其原因，很大程度上是因为GX只是一个Single Path Image模式的架构，类似于微软的DFS，将多个独立文件系统，从路径上加一次虚拟，仅此而已，多个文件系统（控制器机头）之间依然采用松耦合方式。他没有从骨子里表现为一个Single Filesystem Image的集群或者分布式文件系统，市场认同度不高。就WAFL的目前的架构来看，想做成骨子里的集群或者分布式文件系统，不是不可能，NetApp的技术还是很强的，但是需要伤筋动骨，兴师动众，需要革掉旧东西，一定会有阵痛。目前来讲，NetApp可能尚未考虑好究竟要怎么做。新推出的Ontap8.0操作系统，我认为基本上没有太大的变动。这一切都显示了，NetApp正在荆棘中痛苦的挣扎着、创新着前进。 综述—— NetApp的软件很有特色，这次连硬件也能玩出个花色来。这一点NetApp确实很具有创新思想。作为NAS存储的开山鼻祖，经历了20年的NetApp，一直在引领NAS潮流，包括众多独特的细节功能以及它的基于WAFL之上的统一存储的概念。但是时代在变，潮流在变。就拿统一存储来说，这个潮流前几年确实一直被推崇，但是随着云的出现，统一不一定非要在存储控制器中实现了，云上层的资源管理完全可以统一，底层存储在云中能折腾起的浪花会越来越小，离用户越来越远，最后会变成一片平静的海面。而在硬件规格大换代的潮流中，NetApp前期没能跟得上，这次在FASx200中终于随波逐流了，但是可喜的一点是在硬件形态方面依然做了创新。而在固态存储与动态分级潮流面前，NetApp显然已经落后了至少2年了，其PAM卡这个大缓存还有多少生命力，不好预测。在这个变革的时代，WAFL这个存在了20年的文件系统，是否也应该思变了呢？现在不变，更待何时，否则就只能在不断的追赶当中逐渐退去。 就在不久前，NetApp决定大力拓展中国市场，欲将中国市场的销售额超过日本，成为亚太区第一。我对此也产生了一些联想，国内的经济发展导致国内存储市场逐年被挖掘，而NetApp假设就算已经无法引领潮流，那么至少在国内NAS市场还是能有很大作为的。后续NetApp对中国市场会有什么动作，会加大宣传力度么，会高调示人么？让我们拭目以待吧。 | |
 (6个打分， 平均：5.00 / 5) |
雁过留声
“在荆棘中挣扎前进的NetApp”有28个回复
纯粹存储方面的文章貌似在这里看到的还不多。更多是网络，安全，芯片，系统，任务相关的。挺好，存储在未来十年应该会有很大增长。期待更多的好文。
好文！谈转载事项，如果愿意，请联系我。
zhou_yuan@cnw.com.cn
To：张弛
我的博客：
http://space.doit.com.cn/35700
写的相当不错。弯曲评论者storage方面比较淡薄。你来了，很好。希望坚持下去。我到给你你出荣誉出品写真集。。。
能否谈谈InfiniBand在数据中心里到底有无发展前途。。。？
To陈首席：
初来乍到，昨晚刚注册的。看到如此多的高人在一起探讨，倍感激动。在下只是个草根小鸟，只是凭借对存储的一股热情一直在研究，时不时抛出点歪论之类。首席还给我出了命题作文。不过对网络这块我仅了解最基本的概念，高级东西还要向大家学习。对Infiniband和10Gb以太网了解仅限于表象，对于其底层技术以及后续发展均没有感觉。所以只能硬着头皮臆测了，个人看法是Infiniband不会用于存储网络。目前唯一一家还用Infiniband的商用存储是Isilon，刚被EMC收购。其成本太高，而海量存储的趋势是容不下这么高成本的东西的。不成熟看法，请大家多指教。
to 冬瓜：
“分级存储”就像云计算决定是王道，因为PC本身就是“分级存储”的，看来Tom吃Ellison一样的亏。
2楼抢我头里了！一块转吧
To：老吴
同意。cpu L1/L2/L3cache-ram之间过渡良好，但是一下子到了机械盘，落差太大，需要有一种角色来插入，这就是固态永久存储介质。而目前存储业界正在争论SSD到底作为ram下面的二级cache还是作为机械盘上面的永久存储层级。目前看来除了NetApp和Sun之外，其他厂商都选择了后者。
To陈首席：
刚才只发表了IB用于存储网络的看法，没注意您提的是用在数据中心里。IB如果作为单纯的数据承载通道，真的看不到前景。当初好像IB和NGIO、Future IO、RDMA是一家子的，想把计算机总线从身体里长到外面来，但是一段时间之后不得不说，他们失败了，或者说潜伏起来了。如今MR-IOV又出来折腾开了，PCI-E速率脚步一个劲往上涨，也开始按耐不住要往外长了，MRIOV好像没有IB那么宏伟的目标，先给自己设下了个眼前的一步，就是多台主机通过外置PCIE交换机共享访问多个CNA，这算是总线扩充的第一步吧。从更high的角度来看，计算机总线往外长，是好事情，可以让更多节点之间更方便的组成集群，为将来的分布式操作系统创建良好的根基，最后，我乱猜一下，一个数据中心内部就一个大操作系统，这个操作系统并不是指微软System Center或者Novell Cloud Manager之类，而是骨子里的分布式操作系统，类似分布式并行文件系统。IB倒下了，PCI-E踩着它继续向前冲！PCI-E比IB幸运，因为前者赶上了IT基础架构大变革的时代，也就是云时代，而后者在当时就显得太过超前了，成本也太高了。能不能成功，在此一举了！
不知道思科会不会收购NetAPP？
貌似思科就缺存储了。
NetApp比较贵，Cisco现在和他们在合作，应该用不着收购的
另外，目前仅剩的一家分布式并行NAS，Panasas，可能会沦为下一个被收购的对象，其投资人把利润都抽走了，不再继续投资。
谢谢冬瓜头。非常清晰的思维和优秀的观点。希望你能在这里把Storage这一块带起来，把自己的知识共享出来。并在这里交上大量的朋友。
陈首席过奖。非常希望在这里能够高攀各位，向大家吸收更多养分。今后有新存储观点都会发到这里发酵。另外也欢迎大家到鄙人博客浏览并留言：
http://space.doit.com.cn/35700
如果弯曲评论有博客，我希望能开个镜像博客。
一点外行疑问：
一般网络设计，在LAN包括数据中心，带宽设计是在redundancy下都不存在阻塞点的，那么存贮网络要求的可靠性是因为网络不可靠，还是应用协议本身的不可靠？从各位专业人士的论述看，应该是用FC/OE解决网络可靠性对存贮的影响问题，而这和上面的网络设计原则又相悖。如果丢包不是问题了，那么可理解为时延问题，但在没有带宽阻塞情况下的GE/10GE网络的时延，很难大于CPU任务处理的时延吧？OK，那么理解为存贮协议要求不同的协议有不同的QOS要求，那么此时，如果存贮设备本身能映射DSCP/802.1P等，难道这种分类以及对应的路由交换设备的PQ/WFQ等不能满足存贮的要求？基于存贮转发的设备的时延，在目前已经是基于硬件的转发情况下，更多是存贮带来的时延，而存贮的原因是因为转发有拥塞，而在比如90%的负荷下，目前的网络设备基本上时延是ns级别。或者说存贮协议用大多数据报文是9K字节，而部分报文，比如协议是100字节级别，所以在混合传输时需要特殊处理？
关于企业在扩展领域中主要是依托优势地位的主业的方法，是企业界通用的方法，在吴军的浪潮之巅有很好的描述
To 理客：
不是很理解理客的论点。我的浅薄理解就是存储网络的可靠性就是链路层可靠性加上层协议逻辑的可靠性。FCoE的目的好像并不是解决可靠性问题，DCE/CEE只是为了给FC躺到Eth上铺铺床单，因为传统FC上半层舒服惯了。说道存储的QoS，这一块确实之前不太受到厂商的重视，在虚拟化和云架构变革之后，存储的QoS势必会逐渐引起重视，不仅Vsphere里的SIOC，存储端也需要给点力。报文方面我就不敢妄加评论了，一点看法就是存储网络底层在处理这种9K到1K落差的帧的时候，需要考虑饿死问题。
感谢冬瓜兄的好文。过去经常拜读再dostor论坛的帖子。
关于在NAS产品中如何应用SSD，除了您提到的两种途径（用做缓存，基于访问频率的分级存储），还可以至少有另外一种玩法，就是基于数据块类型的分级存储（比如将元数据放在SSD上，一般用户数据放在HDD上）。这是NAS比较有优势的地方，SAN就没办法直到数据快的类型，所以不能这么搞。
对于您提到的sequential read after random write 的问题，只要文件系统支持快照，最后都会导致fragmentation，从而导致sequential read 变成了random read。这不是NetApp独有的问题，只不过WAFL让问题更严重。
冬瓜兄提到的写加速优化对硬盘有用，但是对SSD确实没什么用处。但是别忘了，SSD主要是用来帮助提高random read的性能，对于sequential read, 它的性能和硬盘在一个数量级上。我个人认为SSD和WAFL并不矛盾，用好了还是会提升系统的性能的。
感谢zchshao的信息。关于元数据放SSD实际数据放HDD这种做法，实不相瞒，当时在N的时候曾经作为一个想法提出过，那时候PAM卡还没发布，但是已经搞出来了。哪家有这么玩能否透露一下。其实SAN一样可以这么搞，现在SAN底层的Lun数据排布已经逐渐在变了，比如xiv、infotrend、Equalogic（Dell P4000）等等Scale-Out模式的SAN，他们的元数据量也开始逐渐增多的。但是SSD这么用也有局限性，因为这么搞不能加速用户数据读写。
是的，凡是文件系统都有这个问题。不过WAFL把Lun也当做一个文件，这样的话。。。导致性能很难预测。
SSD与WAFL的一个最大的矛盾就是WAFL会迅速耗尽SSD的剩余空间。早期的SSD当剩余空间降低之后性能会降低40%以上，而目前诸如STEC等SSD好像没这么高的下降比例了。SSD是瘦死骆驼比马大，肯定会提升性能的，但是WAFL下的SSD恐怕是很难与其他系统下匹敌，我猜测，N肯定是测试过，不敢用。后来就转投PAM了。这就像EMC从来不测SPC1一样，其实他们内部测过，成绩很差。
to 冬瓜头：
您对Netapp研究颇深啊，受教了。众所周知，Netapp的智能cache技术，在NAS领域是很强的。我想补充一下Netapp的cache技术的一些问题，还望赐教。
总的来说，Netapp产品体系的读cache分3层，第一级，内存cache，就是缓存在主存中的数据；第二级，flashcache，也就是对应那个PAM卡（有个PCS的软件来分析数据决定加不加这卡），缓存从主存中刷出来的数据；第三级flexcache（机械磁盘，不知道用没有ssd，ssd可能成本太高），进一步缓存PAM刷出来数据，或者从远端server预取过来的数据。怎样预取，怎么替换，缓存哪些上一级刷出来的数据，Netapp有自己的算法来根据数据属性和数据访问模式决定，比如说，元数据必须高优先级缓存，小的随机读数据高优先级缓存。
Netapp的写缓存，可以对应到NVRAM（插了电池的内存条），不过写缓存比较复杂和他DataONTAP系统，WAFL联系紧密。简单的说，就是缓存写操作数据，加速写操作，为了保证数据的一致性，写缓存会每隔几秒把NVRAM缓存数据刷回持久存储，相当于把一个checkpoint刷回持久存储，当掉电事故发生，NVRAM故障等，可以立即回滚到最近checkpoint，保证文件系统的始终是一致的，可用的。
一个具体应用案例，就是阿凡达渲染墙，
http://www.netapp.com/cn/communities/tech-ontap/tot-1008-bringing-avatar-to-life-zh.html
内网不让发送大量文字，只好分段发送了。
Part1：
是的，20年的发展不是盖的。另外他后台有很多性能监控和统计手段，还有很多隐藏命令可以看到最细节的信息，当然这些基本上都是研发人员用的了。如果将Flexcache、NVRAM、RAM、PAM穿起来说的话，先是Flexcache，透点干货，Flexcache其实没有什么特别算法，就是按照一定智能，将数据按照一定的粒度从一台nas读出到另一台nas（也就是flexcache设备）中存放，这些数据会被存储在flexcache设备本地用以加速广域网读写。从本质上讲，flexcache相当于能对数据热点有更给力的预测，类似动态数据分级，而不像是实时cache算法那样，LRU或者各种实时的read ahead，前者是慢工出细活，后者是赶工上架。其实Flexcache更类似于CDN。阿凡达里属于本地局域网内加速，那么此时更是考验Flexcache热点监控和预读的算法效率的时刻。再透一点，Flexcache其实就是使用NFS协议从后端存储中读数据的，数据过期通知这块我记不清了，传统NFS是靠Client端使用Getattr（）来主动探查，而Flexcache好像做了修改，让Server端主动推送信息，这个不太确定，后面有机会可以再回去看看。
Part2
再说说NVRAM，NVRAM其实就是存放WAFL操作日志的，类似数据库的日志，利用这种方法来加速写操作，可以看到NVRAM本身并不大，每到四分之一满（一半用来镜像对端的日志，另一半的一半满的时候就刷盘）就触发刷盘操作，所以NetApp的等效写缓存就相当于NVRAM容量除以4，但是实际体现出来的性能确实还不错的。WAFL之所以敢用这么小的NVRAM，是因为WAFL的写优化，这就不扩开讲了，架构师一定是算好了的，后端刷盘时候的速率与NVRAM drain的速率以及前端数据进入的速率以及成本之间，有个平衡点。由于WAFL从来覆写原来的数据，所以它做error recovery非常便捷，就是checkpoint手段，回滚就可以了，然后再将NVRAM中的脏日志重放。 说完了NVRAM，路径中下一个就是RAM了，系统会不停的从NVRAM中将每一笔操作提取并准备相应的IO资源以用来刷盘，这个加工厂就是RAM，当每次checkpoint触发的时候，是系统最忙的时候了。
Part3：
最后一层就是PAM了，相当于将RAM扩充了，只做读缓存，算法估计也没有什么大改变，估计是针对大缓存做了一些优化。
冬瓜头应该对存储蛮懂了，你也写了两本关于存储的书。
我这里就想请教一下关于SSD方面的东西：
第一种，SSD目前我看到的趋势是大家很想作为分层存储的一种介质，从速度上来看内存>SSD>机械硬盘。但是这种做法更多的表现为读缓存，比如Sun（oracle）目前的做法就是这样，具体可以看Sun的7400系列存储产品。包括netapp的缓存卡，其实也只是读的缓存。这种做法，为何很少用于写？我想更多的人希望是存储能够快速的写入大量小文件。
其次，就是EMC和fusionIO直接用SSD作为存储，好像主要用于数据库。但是，他们所使用的SSD都很昂贵，是否可以用普通的企业级SSD作为这类DB的写入设备？如用OCZ的SLC企业级SSD-OCZ Vertex 2 EX Series。
To guanghui：
感谢参与讨论。首先目前更多的确实是作为Tier，比如最早的Compellent，后来的3PAR、EMC、IBM、Dell/Equalogic、HDS，都纷纷有各自对应的动态分级产品和方案。唯一2家用作缓存的就是Sun和NetApp，Oracle新出的Exalogic产品内就有宣传这种SSD Cache。NetApp更不用说，最大8TB，Cache帝，呵呵。 为何不连写也加速？我只能给出推断，并不能代表厂家的实际。我是这么考虑的：第一，用SSD只读Cache的话，不用考虑安全性问题（坏一块照样用，用作写的话一定要做Raid一类的保护措施了，增加了成本）；第二，不用考虑定时刷盘的问题（SSD Cache在OS内核中的表现应该更是一个块设备，IO路径中插入一层逻辑截获读IO请求重定向，如果是写也加速，那么就导致软件更加复杂，需要）；第三就是考虑写性能和寿命问题，虽然读加速，但是猜测，它一样要写的，比如SSD中的数据对应在HDD上的副本一旦被更新，那么SSD中的数据就要随着更新，其实SSD在随机写方面性能会骤降，而且在读写混合的时候，由于SSD内部代码优化的问题，目前有的产品都会出现甚至不如单写时的性能。所以，尽量避免写。再就是寿命考虑，尽量避免写。
对于FusionIO这种纯SSD产品，我的看法就是它既然选择了这条路，那么就要做到高精尖，性能第一。EMC我不知道它也有这种纯SSD产品？应该没有把，都是配在阵列里用它的FASTv2的动态分级方案的。
我印象中EMC好像有用到SSD，我对它不了解，可能记错了，应该是你说的动态分级方案，采用的是STEC的产品吧。
Sun用到SSD的方式，一个给slog用，这个相当于Netapp的NVRAM的作用。另外一个给L2ARC，就是读缓存，它们可以同时存在，L2ARC也就是netapp的那种缓存卡PAM。
谢谢冬瓜头的解答!
EMC用的STEC，400GB版本的，但是出货不利，导致STEC收入下降。这不上周STEC宣布正式与HP达成合作，在HP阵列里配套SSD了，也是400GB的。EMC、HP一块傍，呵呵。
slog是transaction log么？ L2ARC是什么意思呢，Level2 archiving？数据库方面不太懂，望指教指教，谢谢！
slog和L2ARC都不是数据库的东西，其实是sun的zfs文件系统的东西。slog是zfs的zil(ZFS Intent log)用，L2ARC（Level Two Adaptive Replacement Cache），用SSD。既然有L2就应该还有一个L1ARC,这个就是使用内存。
因为在sun看来，内存毕竟容量有限，现在一般配置32G到144G之间，而SSD可以做到好几个T，GB花费更低。
哦，zfs和wafl底层类似。还有一家类似的是Bluearc，纯FPGA做NAS的，其内部文件系统逻辑也类似WAFL，很多概念上别无二致，一直也搞不清楚怎么回事。