EMC与NetApp NAS对比(1)：易用性天上人间
概述
由于工作原因，本人管理着国内大型互联网公司的存储设备，一直以来公司都使用 NetApp的NAS产品，接触了NetApp的NAS有5年了，而后期由于商务上的原因，也引入了几台EMC的 NAS，两者并存一年使用下来两相对比，辛酸苦辣不足为外人道也。
为了让兄弟公司的弟兄们能够清楚了解两者之间的差异，在设备选型时不至于被厂商的销售忽悠，特写此文揭露两家NAS产品的真面目。本文将会好话少坏话多，把厂商试图隐藏的最最丑恶的角落展示在舞台中央。
1. NAS结构对比
为了能够清楚地说明两者之间的差异，先画一个草图来辅助说明它们的结构：
· 左边的NetApp FAS产品，其控制器完全承担了所有工作，包括RAID、文件系统、网络IO、HA等等，EMC的SE会鄙视其为“PC架构”，但不可否认的是，它是一个完整的、一体的产品。
· 右边的EMC NS产品，实质上是CLARiiON的软硬件+PC(EMC叫DataMover)+DART，CLARiiON处理RAID，PC处理文件系统和网络 IO以及HA，由一个或二个Control Station来协调配置。
根据以上结构示意图，接下来讲讲他们两家有什么差异。
2. 易用性：天上人间
这方面可以给NetApp 打90分，而EMC只能得60分(分数为主观判断，读者可以根据描述自行斟酌)。
由于NetApp的Data ONTAP操作系统是与设备一体化的，所有的功能设置在一个框架下完成，可以说一个熟练的管理员可以在5分钟内将一套FAS设置完毕投入使用。
而EMC的NAS产品更象一个整合拼凑的东西，必须通过Control Station分别给CLARiiON的FLARE和DataMover的DART发送相应指令才能完成设置。这就造成了易用性上的问题，虽说也是一个界面下完成工作，但这就引入了很多局限性。例如其设置向导仅支持预定义好的几种RAID，例如4+1的RAID 5，如果你想要5+1的呢？对不起不支持。如果非要这么做也是可以通过MVM实现的，但向导不能用了，你得自己定义好RAID组、划好LUN、输出给 DataMover… 预留两天时间吧。
另外在Control Station上遇到过下列问题：
· JAVA进程死掉，无法登入，只能重启Control Station ——EMC无法解决
· 在Control Station上执行了划分一个文件系统的操作后，后台会处理一段时间，在这段时间内是无法进行设置NFS export权限之类的配置操作的。曾经在FC盘的Pool中划了个15TB的文件系统，1个小时内无法操作(SATA盘这个时间是1.5小时)，如果这段时间内你遇到个需要对另一个文件系统增加export权限的需求，那over了，等吧。——EMC回复无法解决此问题。
· 在文件系统内的文件数量达到一个比较大的量之后，Control Station的管理界面中就看不到这个文件系统的一些信息了。——EMC的解释是数值超过了它的软件中字段上限，溢出故无法查看了。
· 配置关联性差，删除一个卷，用命令行server_export居然还可以看到这个卷的export条目，需要手工去删除，而NetApp是随着卷删除关联的配置自动删除的。
易用性方面EMC唯一比NetApp强的地方：Control Station可以支持多个用户同时登录，而NetApp在同一时刻仅支持一个用户登录。
所以，易用性方面
NetApp：★★★★☆ EMC：★★★
由于工作原因，本人管理着国内大型互联网公司的存储设备，一直以来公司都使用 NetApp的NAS产品，接触了NetApp的NAS有5年了，而后期由于商务上的原因，也引入了几台EMC的 NAS，两者并存一年使用下来两相对比，辛酸苦辣不足为外人道也。
为了让兄弟公司的弟兄们能够清楚了解两者之间的差异，在设备选型时不至于被厂商的销售忽悠，特写此文揭露两家NAS产品的真面目。本文将会好话少坏话多，把厂商试图隐藏的最最丑恶的角落展示在舞台中央。
1. NAS结构对比
为了能够清楚地说明两者之间的差异，先画一个草图来辅助说明它们的结构：
· 左边的NetApp FAS产品，其控制器完全承担了所有工作，包括RAID、文件系统、网络IO、HA等等，EMC的SE会鄙视其为“PC架构”，但不可否认的是，它是一个完整的、一体的产品。
· 右边的EMC NS产品，实质上是CLARiiON的软硬件+PC(EMC叫DataMover)+DART，CLARiiON处理RAID，PC处理文件系统和网络 IO以及HA，由一个或二个Control Station来协调配置。
根据以上结构示意图，接下来讲讲他们两家有什么差异。
2. 易用性：天上人间
这方面可以给NetApp 打90分，而EMC只能得60分(分数为主观判断，读者可以根据描述自行斟酌)。
由于NetApp的Data ONTAP操作系统是与设备一体化的，所有的功能设置在一个框架下完成，可以说一个熟练的管理员可以在5分钟内将一套FAS设置完毕投入使用。
而EMC的NAS产品更象一个整合拼凑的东西，必须通过Control Station分别给CLARiiON的FLARE和DataMover的DART发送相应指令才能完成设置。这就造成了易用性上的问题，虽说也是一个界面下完成工作，但这就引入了很多局限性。例如其设置向导仅支持预定义好的几种RAID，例如4+1的RAID 5，如果你想要5+1的呢？对不起不支持。如果非要这么做也是可以通过MVM实现的，但向导不能用了，你得自己定义好RAID组、划好LUN、输出给 DataMover… 预留两天时间吧。
另外在Control Station上遇到过下列问题：
· JAVA进程死掉，无法登入，只能重启Control Station ——EMC无法解决
· 在Control Station上执行了划分一个文件系统的操作后，后台会处理一段时间，在这段时间内是无法进行设置NFS export权限之类的配置操作的。曾经在FC盘的Pool中划了个15TB的文件系统，1个小时内无法操作(SATA盘这个时间是1.5小时)，如果这段时间内你遇到个需要对另一个文件系统增加export权限的需求，那over了，等吧。——EMC回复无法解决此问题。
· 在文件系统内的文件数量达到一个比较大的量之后，Control Station的管理界面中就看不到这个文件系统的一些信息了。——EMC的解释是数值超过了它的软件中字段上限，溢出故无法查看了。
· 配置关联性差，删除一个卷，用命令行server_export居然还可以看到这个卷的export条目，需要手工去删除，而NetApp是随着卷删除关联的配置自动删除的。
易用性方面EMC唯一比NetApp强的地方：Control Station可以支持多个用户同时登录，而NetApp在同一时刻仅支持一个用户登录。
所以，易用性方面
NetApp：★★★★☆ EMC：★★★
5同行回答
EMC与NetApp NAS对比(3)：数据保护见仁见智
5. 可扩展性
这里不谈论支持多少块硬盘这样的问题，仅讨论要做扩容操作时的简易程度。NetApp在扩容的操作上比EMC简便，但相差并不是非常大。例如NetApp加磁盘与加pool是一个过程，而EMC则需要创建RAID-LUN，再把LUN加入pool。
另外建文件系统时NetApp可以说是“瞬时”完成，但EMC新建一个文件系统如第一节的易用性描述所说，视文件系统大小会有一段时间控制台操作无效。
文件系统大小两者都可以按需要增加，不必一次划分固定大小，但是NetApp的文件系统如果删除了部分数据可以缩减大小回收空间，而EMC的NAS要回收空间就只能迁移数据再整体删除了。
这里着重说一说inode，两者的文件系统都有inode上限，但EMC创建文件系统时指定的block大小就决定了文件系统(最大16TB) 能支持的inode数量，不能在使用中改动，而且默认是8KB，对大量小文件的使用场景如果刚开始没想到这一层那就是个餐具了;NetApp可以在任何时候用maxfile命令增加文件系统inode，EMC SE的说法是“我们事先规划好了也一样”，但功能方面确实是NetApp占优。
可扩展性的结果也出来了，NetApp不给五星的理由是不能突破16TB的限制，虽然有Data ONTAP 8G，但光打雷不下雨。
NetApp：★★★★ EMC：★★★
6. 数据保护：见仁见智
6.1. 复制
EMC的复制工具叫replicator，是一个基于文件的复制工具，如果使用场景是数据库或视频之类的大文件，没有任何问题，但遇上一个文件系统中有数亿个只有几KB的小文件时效率可想而知了。
NetApp的复制工具叫SnapMirror，它在处理Qtree(NetApp概念，卷根目录下的子目录，需用NetApp OS创建)的复制时是基于文件传输的，先扫描inode，传送inode变化信息，再传送变化的文件，同样只适用于大文件场景不适合海量小文件场景;但是 SnapMirror在处理卷的复制时是基于block的，适合任意文件类型的传输，效率非常高，可以将千兆网卡跑满，但它仅支持整卷复制而不支持目录级复制。
这两者一对比，结论很明显：
NetApp：★★★★ EMC：★★★
6.2. 快照
EMC 的快照是 copy-on-write 方式，有一块固定的空间用于存放快照数据，与主卷是分离的，在数据变更时将旧数据复制到快照空间，再将新数据覆盖旧数据。
NetApp 的快照在数据变更时不移动旧数据，而是将新数据写到新位置，然后将引用数据的指针指向新位置。两者的特点分析：
EMC的快照不对原始卷产生影响，文件系统的连续性得到保证;而NetApp的快照会使原始卷数据分布越来越散乱;
EMC的快照生成时会影响性能，因为必须先把旧数据copy到快照空间，写入会延时，一般EMC工程师会建议快照不要超过多少多少，而 NetApp的快照生成时不会影响性能，也不会使读写延迟，快照数据是瞬时生成的;
EMC的快照空间是独立的固定空间，可以设置在低等级的磁盘上，而NetApp的快照空间与主卷是在一起的，如果希望实现类似功能则需要购买 SnapVault的license;
NetApp如果对GB级大文件使用场景的文件系统做多份快照，然后一次性删除数百GB的大文件时，会导致系统CPU利用率高，这是WAFL文件系统的特性决定的，得处理大量文件指针修改，而小文件使用场景没有遇到类似问题。而反观EMC，它的快照原理决定了它不会遇到这种情况。
快照功能两者也是互有得失，主要看使用者的场景更适合哪种快照了。
NetApp：★★★★ EMC：★★★★
7. 杂项
NetApp可以方便地升级，如FAS3140不想用了，买个3240的控制器换了就OK了，数据不会丢失。
NetApp的RAID信息是写在磁盘上的，它支持磁盘漫游，盘序再乱也没关系，而EMC的盘序要是插乱了就哭吧。
EMC在RAID重建时是将数据copy到spare盘，换上新盘后又将数据从spare盘copy回来，换句话说spare盘永远是 spare盘，NetApp数据copy完了spare盘就成为数据盘了，换上的新盘成为spare，个人觉得这种方式好。
EMC支持将多个卷“伪装”成一个卷输出，每个成员卷表现为一个目录，但每个目录仍然不能超过16TB，而NetApp的Data ONTAP 7G没有这样的能力，强大的8G又未成熟。
EMC的NS拆了就是台CX，NetApp的FAS拆了就拆了，离开了机头就just disk了。
NetApp一个目录下最多可以有99998个子目录，EMC的一个目录下最多有65533 个子目录，应用规划数据目录结构时要注意。
EMC不支持snmpget方式的监控，只能以trap方式打到trap-server上，但是信息又不是那么完整，例如文件系统inode耗尽居然不认为是文件系统的错误，不发trap出来，因此带来了个故障。——经EMC二线人工修改某配置文件将inode报告强制输出解决，请后来者留意。
这节就不评判了，用者知晓就可以了。
说在最后
说了这么多，个人认为EMC的NAS确实不如NetApp，这其中归根结底的原因：FAS是NetApp安身立命的根本，而NS只是EMC买过来的产品，也没花大力气去整合改进，这个产品的能力根本与EMC在存储界的地位不相符。
可能有人会说既然EMC NAS这么“差劲”，为什么市场占有率那么高呢？个人认为这里有两个原因：其一，技术不是全部，习惯的力量、品牌的影响力、市场手段都是影响因素;其二，相信很多EMC NAS用户没有遇到这么多切肤之痛、没有这么详尽的比对。看起来写这篇文章是褒N黑E的，我没拿N的钱，和N的销售关系也不佳，没有必要为N黑E，这些内容确实是在使用EMC NAS的过程中遇到了种种问题而总结出来的，拿出来也是为了后来人不要再碰到这些问题，也欢迎有人指出这里没有涉及到的NetApp NAS的缺点，有可能对大家的工作都有所帮助。收起
5. 可扩展性
这里不谈论支持多少块硬盘这样的问题，仅讨论要做扩容操作时的简易程度。NetApp在扩容的操作上比EMC简便，但相差并不是非常大。例如NetApp加磁盘与加pool是一个过程，而EMC则需要创建RAID-LUN，再把LUN加入pool。
另外建文件系统时NetApp可以说是“瞬时”完成，但EMC新建一个文件系统如第一节的易用性描述所说，视文件系统大小会有一段时间控制台操作无效。
文件系统大小两者都可以按需要增加，不必一次划分固定大小，但是NetApp的文件系统如果删除了部分数据可以缩减大小回收空间，而EMC的NAS要回收空间就只能迁移数据再整体删除了。
这里着重说一说inode，两者的文件系统都有inode上限，但EMC创建文件系统时指定的block大小就决定了文件系统(最大16TB) 能支持的inode数量，不能在使用中改动，而且默认是8KB，对大量小文件的使用场景如果刚开始没想到这一层那就是个餐具了;NetApp可以在任何时候用maxfile命令增加文件系统inode，EMC SE的说法是“我们事先规划好了也一样”，但功能方面确实是NetApp占优。
可扩展性的结果也出来了，NetApp不给五星的理由是不能突破16TB的限制，虽然有Data ONTAP 8G，但光打雷不下雨。
NetApp：★★★★ EMC：★★★
6. 数据保护：见仁见智
6.1. 复制
EMC的复制工具叫replicator，是一个基于文件的复制工具，如果使用场景是数据库或视频之类的大文件，没有任何问题，但遇上一个文件系统中有数亿个只有几KB的小文件时效率可想而知了。
NetApp的复制工具叫SnapMirror，它在处理Qtree(NetApp概念，卷根目录下的子目录，需用NetApp OS创建)的复制时是基于文件传输的，先扫描inode，传送inode变化信息，再传送变化的文件，同样只适用于大文件场景不适合海量小文件场景;但是 SnapMirror在处理卷的复制时是基于block的，适合任意文件类型的传输，效率非常高，可以将千兆网卡跑满，但它仅支持整卷复制而不支持目录级复制。
这两者一对比，结论很明显：
NetApp：★★★★ EMC：★★★
6.2. 快照
EMC 的快照是 copy-on-write 方式，有一块固定的空间用于存放快照数据，与主卷是分离的，在数据变更时将旧数据复制到快照空间，再将新数据覆盖旧数据。
NetApp 的快照在数据变更时不移动旧数据，而是将新数据写到新位置，然后将引用数据的指针指向新位置。两者的特点分析：
EMC的快照不对原始卷产生影响，文件系统的连续性得到保证;而NetApp的快照会使原始卷数据分布越来越散乱;
EMC的快照生成时会影响性能，因为必须先把旧数据copy到快照空间，写入会延时，一般EMC工程师会建议快照不要超过多少多少，而 NetApp的快照生成时不会影响性能，也不会使读写延迟，快照数据是瞬时生成的;
EMC的快照空间是独立的固定空间，可以设置在低等级的磁盘上，而NetApp的快照空间与主卷是在一起的，如果希望实现类似功能则需要购买 SnapVault的license;
NetApp如果对GB级大文件使用场景的文件系统做多份快照，然后一次性删除数百GB的大文件时，会导致系统CPU利用率高，这是WAFL文件系统的特性决定的，得处理大量文件指针修改，而小文件使用场景没有遇到类似问题。而反观EMC，它的快照原理决定了它不会遇到这种情况。
快照功能两者也是互有得失，主要看使用者的场景更适合哪种快照了。
NetApp：★★★★ EMC：★★★★
7. 杂项
NetApp可以方便地升级，如FAS3140不想用了，买个3240的控制器换了就OK了，数据不会丢失。
NetApp的RAID信息是写在磁盘上的，它支持磁盘漫游，盘序再乱也没关系，而EMC的盘序要是插乱了就哭吧。
EMC在RAID重建时是将数据copy到spare盘，换上新盘后又将数据从spare盘copy回来，换句话说spare盘永远是 spare盘，NetApp数据copy完了spare盘就成为数据盘了，换上的新盘成为spare，个人觉得这种方式好。
EMC支持将多个卷“伪装”成一个卷输出，每个成员卷表现为一个目录，但每个目录仍然不能超过16TB，而NetApp的Data ONTAP 7G没有这样的能力，强大的8G又未成熟。
EMC的NS拆了就是台CX，NetApp的FAS拆了就拆了，离开了机头就just disk了。
NetApp一个目录下最多可以有99998个子目录，EMC的一个目录下最多有65533 个子目录，应用规划数据目录结构时要注意。
EMC不支持snmpget方式的监控，只能以trap方式打到trap-server上，但是信息又不是那么完整，例如文件系统inode耗尽居然不认为是文件系统的错误，不发trap出来，因此带来了个故障。——经EMC二线人工修改某配置文件将inode报告强制输出解决，请后来者留意。
这节就不评判了，用者知晓就可以了。
说在最后
说了这么多，个人认为EMC的NAS确实不如NetApp，这其中归根结底的原因：FAS是NetApp安身立命的根本，而NS只是EMC买过来的产品，也没花大力气去整合改进，这个产品的能力根本与EMC在存储界的地位不相符。
可能有人会说既然EMC NAS这么“差劲”，为什么市场占有率那么高呢？个人认为这里有两个原因：其一，技术不是全部，习惯的力量、品牌的影响力、市场手段都是影响因素;其二，相信很多EMC NAS用户没有遇到这么多切肤之痛、没有这么详尽的比对。看起来写这篇文章是褒N黑E的，我没拿N的钱，和N的销售关系也不佳，没有必要为N黑E，这些内容确实是在使用EMC NAS的过程中遇到了种种问题而总结出来的，拿出来也是为了后来人不要再碰到这些问题，也欢迎有人指出这里没有涉及到的NetApp NAS的缺点，有可能对大家的工作都有所帮助。收起
这个好，看过收起
浏览2631
看到几个字，天上人间，我就进来了收起
浏览2591
EMC与NetApp NAS对比(2)：性能-真实的谎言 3. 性能：真实的谎言 这里不介绍性能的具体的数字，SPEC网站上有SFS97、SFS2008的测试值，可以自行去查看。这里要说明的是网站上、销售嘴里告诉你的性能指标背后的含义。 EMC的销售会这样说：我们的 NS系列产品性能指标比NetApp...EMC与NetApp NAS对比(2)：性能-真实的谎言
3. 性能：真实的谎言
这里不介绍性能的具体的数字，SPEC网站上有SFS97、SFS2008的测试值，可以自行去查看。这里要说明的是网站上、销售嘴里告诉你的性能指标背后的含义。
EMC的销售会这样说：我们的 NS系列产品性能指标比NetApp同等档次产品的性能要高，你看我们的值是…… 某些兄弟可能会想到测试的设备配置是否相当、盘数量是否一致等等，没错了。但藏在这背后的还有一件事值得留意：这些性能测试值是个和值，还要参考多少个 “机头”参与了测试。如果一个业务需要一个能满足特定负荷的共享文件系统，那么一定要考虑单个“机头”是否能够满足这些性能指标，不能被整机测试成绩欺骗。因为不管EMC还是NetApp，它们的多个blade或者两个控制器是不可以共享一个卷输出同一个文件系统的。
参考第一节的设备结构，EMC NAS后端是一台CLARiiON设备(或者DMX)，在NS960与FAS3170竞争时，EMC SE会说NS960有32GB的cache，每个DataMover有8GB的Cache，而NetApp每控制器16GB总共也就32GB Cache，并且CX960的32GB Cache还可以供多个DM共享提升性能。——听起来很有道理，Cache是多一些，但是这里面有两点要记住：
1. Cache差异并不是(8*n+32)GB与32GB那么大，大家知道CLARiiON的Cache也是系统占用+镜像写缓存+读缓存的，32GB只是个数字，能等效为20GB很不错了，DM上的8GB也不全是数据缓存，当然NetApp的32GB也不是全部为数据缓存，这里只是说明差异没有那么大;
2. 成也萧何，败也萧何，EMC引以为豪的所谓“共享”缓存，在后端存储遇到RAID故障、电源故障等需要Disable写缓存时是个杯具，所有的DataMover全部萎靡，而NetApp不会有这个问题，两个控制器间不会互相影响;分享一个真实案例：在NS960上，配置了FC磁盘(蓝色)的pool作为业务使用，等量SATA磁盘(绿色)的pool作为业务数据的备份copy，用Replicator进行数据复制，如下图所示：
当SATA盘遇到磁盘损坏时，DM2提供的FC磁盘组成的业务卷出现读写缓慢现象，追查原因，SATA盘rebuild比较慢，且 rebuild时磁盘繁忙，而Replicator的数据又开始传输，数据挤占了EMC自以为是有益的“共享”Cache，导致本不应受影响的业务卷出现 IO缓慢，最终是停掉Replicator了事。
打标时，EMC SE会指责NetApp的双控制器如果要实现Active-Active，则每个控制器只能用一半性能，否则故障接管时会吃不消，这个好理解，我们也认可 ——但如果EMC的NS它如果只配两片DM你就要小心了，NS的A/A模式是不会互相接管的，至少要配第三片DM作为Spare，这个DM不能分配任何工作，只是由它来接管A/A中间的任一个。
NetApp另一个为人诟病的性能问题是WAFL碎片化，初始安装的NetApp性能确实非同一般，EMC的人承认比不过它，但文件系统用到 80%以上时，WAFL的随处写就受限制了，不能随心所欲写了，性能就会有所下降;并且WAFL的设计方法就决定了它的文件系统宏观上的分布一定是越用越乱的;而EMC的NAS文件系统不存在这个问题。
所以，性能方面是各有千秋了，需要管理员想清楚自己要什么
NetApp：★★★☆ EMC：★★★☆
4. 高可用性
EMC NAS在一个DataMover故障时切换到另一个DM需要耗时1分钟左右，故障恢复时切换回来同样需要1分钟左右(实测值);而NetApp通过IB(新一代产品是10GbE)保持两个控制器间数据通讯，加上具电池保护的NVRAM日志，在故障时可以快速获取必要的数据然后重建服务，切换能够在数秒钟内完成，当然故障恢复后回切是按照停服务-启动OS-提供服务的流程走的，耗时也要1分钟左右。
而在EMC NAS模拟链路故障的拔光纤测试中，拔一条光纤路径顺利切换，CPU负载无变化;拔除全部的两条光纤，DataMover的CPU负载上升至 40%，5分钟后切换至备用DM，NetApp无测试记录，待以后补充。
模拟网络故障的拔网线测试中，EMC NAS在Fail-Safe模式下拔除一条网线切换需8-10秒，NetApp NAS在active-standby模式下排除一条网线切换耗时1秒。
EMC NAS使用的UxFS文件系统可靠性不如WAFL文件系统，在必要的时候必须执行fsck来扫描文件系统错误，而WAFL是时时刻刻保持一致性的文件系统，电池保护的NVRAM记录日志供故障恢复时“重演”，所以它根本不需要类似fsck的操作。
说到这里，很明显了，高可用方面
NetApp：★★★★ EMC：★★★收起
3. 性能：真实的谎言
这里不介绍性能的具体的数字，SPEC网站上有SFS97、SFS2008的测试值，可以自行去查看。这里要说明的是网站上、销售嘴里告诉你的性能指标背后的含义。
EMC的销售会这样说：我们的 NS系列产品性能指标比NetApp同等档次产品的性能要高，你看我们的值是…… 某些兄弟可能会想到测试的设备配置是否相当、盘数量是否一致等等，没错了。但藏在这背后的还有一件事值得留意：这些性能测试值是个和值，还要参考多少个 “机头”参与了测试。如果一个业务需要一个能满足特定负荷的共享文件系统，那么一定要考虑单个“机头”是否能够满足这些性能指标，不能被整机测试成绩欺骗。因为不管EMC还是NetApp，它们的多个blade或者两个控制器是不可以共享一个卷输出同一个文件系统的。
参考第一节的设备结构，EMC NAS后端是一台CLARiiON设备(或者DMX)，在NS960与FAS3170竞争时，EMC SE会说NS960有32GB的cache，每个DataMover有8GB的Cache，而NetApp每控制器16GB总共也就32GB Cache，并且CX960的32GB Cache还可以供多个DM共享提升性能。——听起来很有道理，Cache是多一些，但是这里面有两点要记住：
1. Cache差异并不是(8*n+32)GB与32GB那么大，大家知道CLARiiON的Cache也是系统占用+镜像写缓存+读缓存的，32GB只是个数字，能等效为20GB很不错了，DM上的8GB也不全是数据缓存，当然NetApp的32GB也不是全部为数据缓存，这里只是说明差异没有那么大;
2. 成也萧何，败也萧何，EMC引以为豪的所谓“共享”缓存，在后端存储遇到RAID故障、电源故障等需要Disable写缓存时是个杯具，所有的DataMover全部萎靡，而NetApp不会有这个问题，两个控制器间不会互相影响;分享一个真实案例：在NS960上，配置了FC磁盘(蓝色)的pool作为业务使用，等量SATA磁盘(绿色)的pool作为业务数据的备份copy，用Replicator进行数据复制，如下图所示：
当SATA盘遇到磁盘损坏时，DM2提供的FC磁盘组成的业务卷出现读写缓慢现象，追查原因，SATA盘rebuild比较慢，且 rebuild时磁盘繁忙，而Replicator的数据又开始传输，数据挤占了EMC自以为是有益的“共享”Cache，导致本不应受影响的业务卷出现 IO缓慢，最终是停掉Replicator了事。
打标时，EMC SE会指责NetApp的双控制器如果要实现Active-Active，则每个控制器只能用一半性能，否则故障接管时会吃不消，这个好理解，我们也认可 ——但如果EMC的NS它如果只配两片DM你就要小心了，NS的A/A模式是不会互相接管的，至少要配第三片DM作为Spare，这个DM不能分配任何工作，只是由它来接管A/A中间的任一个。
NetApp另一个为人诟病的性能问题是WAFL碎片化，初始安装的NetApp性能确实非同一般，EMC的人承认比不过它，但文件系统用到 80%以上时，WAFL的随处写就受限制了，不能随心所欲写了，性能就会有所下降;并且WAFL的设计方法就决定了它的文件系统宏观上的分布一定是越用越乱的;而EMC的NAS文件系统不存在这个问题。
所以，性能方面是各有千秋了，需要管理员想清楚自己要什么
NetApp：★★★☆ EMC：★★★☆
4. 高可用性
EMC NAS在一个DataMover故障时切换到另一个DM需要耗时1分钟左右，故障恢复时切换回来同样需要1分钟左右(实测值);而NetApp通过IB(新一代产品是10GbE)保持两个控制器间数据通讯，加上具电池保护的NVRAM日志，在故障时可以快速获取必要的数据然后重建服务，切换能够在数秒钟内完成，当然故障恢复后回切是按照停服务-启动OS-提供服务的流程走的，耗时也要1分钟左右。
而在EMC NAS模拟链路故障的拔光纤测试中，拔一条光纤路径顺利切换，CPU负载无变化;拔除全部的两条光纤，DataMover的CPU负载上升至 40%，5分钟后切换至备用DM，NetApp无测试记录，待以后补充。
模拟网络故障的拔网线测试中，EMC NAS在Fail-Safe模式下拔除一条网线切换需8-10秒，NetApp NAS在active-standby模式下排除一条网线切换耗时1秒。
EMC NAS使用的UxFS文件系统可靠性不如WAFL文件系统，在必要的时候必须执行fsck来扫描文件系统错误，而WAFL是时时刻刻保持一致性的文件系统，电池保护的NVRAM记录日志供故障恢复时“重演”，所以它根本不需要类似fsck的操作。
说到这里，很明显了，高可用方面
NetApp：★★★★ EMC：★★★收起
浏览2801