EMC与NetApp NAS对比(1)：易用性天上人间
概述 由于工作原因，本人管理着国内大型互联网公司的存储设备，一直以来公司都使用 NetApp的NAS产品，接触了NetApp的NAS有5年了，而后期由于商务上的原因，也引入了几台EMC的 NAS，两者并存一年使用下来两相对比，辛酸苦辣不足为外人道也。 为了让兄弟公司的弟兄们能够清楚了解...显示全部查看其它 4 个回答黑色代码的回答
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：★★★
浏览2800