skilljiang

在网上读了一篇关于NETAPP WAFL和RAID4 的文章，觉得还是不错的，先转载一下：

Netapp公司创建时间不算长，1992年才创建，但是netapp还是写下了一系列的神话，包括现在IBM的nas系统，都是OEM的netapp的产品。那么，netapp的优势在哪里呢？我在这里分析一下它的特点，WAFL与RAID4+。
WAFL文件系统是netapp自己设计的，运行在netapp专用操作系统DATA ONTAP上的一个文件系统，WAFL是“Write Anywhere File Layout”的意思，即“任意位置写入文件布局”的缩写。正因为有WAFL的这个特点，所以才有了RAID4+，一个改进型的raid4，使得没有校验瓶颈存在，而且能随意扩充硬盘的raid方式。
如果说传统的存储方式中，如果修改一个数据块，我们必须先定位到那个数据块，然后再修改，在我的前面写的raid5内部分析中，我们也看到了，如果修改一个单独的数据，我们必须先读出这个数据与校验，然后修改数据，计算校验，最后写入到同样的位置，这些特点，不仅仅是raid决定的，而且也是运行在raid之上的文件系统决定的。
在WAFL中，如果它也修改一个数据，他可能不管以前的数据的位置，直接把新数据与新校验写到新的位置，之后更改指针，告诉文件系统说，新的数据在这里，而不是原来那里了。这么做还有一个最大的好处就是，新的数据可能等到足够多以后，可以凑齐raid的一个条带以后，一起写进去，就可以大大的提高写的速度。
raid4+就在WAFL的配合下诞生了，传统的raid4是把所有的校验写在一块单独的硬盘上的，如果数据修改量很大，那么这个单独的硬盘就变成了性能瓶颈，而raid4+可以最大可能的把一个条带的数据，一次性的写入，所以，使得校验盘与其它的盘基本相当的写入量，而没有瓶颈出现。而且，当这个raid组想增加硬盘的时候，只是简单的放入新的硬盘即可，任意位置写的规则可以保证新的硬盘马上就被使用起来。

WAFL与raid4+为了尽量保证把数据合并后一次性写入，就必须依赖cache，在cache中才可以等到一定数量的数据之后再一起分批写入，而且，本身WAFL的日志也是记录在cache中的，也包括WAFL的inode的指针操作，也都是在cache中完成。所以，netapp也必须依赖电池或者ups对cache实施保护。

我们先看一个传统的raid4与改良型的raid4之间写的差别，如图，在传统型的raid4中，如果改写我如图的数据，每个数据需要读一次，校验盘可能会写6次，每个数据写一个，涉及到6个条带。但是，在改良型的raid4中，读已经不存在了，而且写的话，最小的可能性，只需要写2个条带，8个写io，一次性写入即可，至于指针，则由WAFL文件系统在cache中完成。
注意，这里为什么说最小可能写2个条带，因为写的时候还需要根据磁盘空间剩余情况，cache的利用情况来综合决定的，有可能也会涉及到3-4个条带，但是，可以肯定的是，算法尽量保证最少的磁盘写次数。

我们上面分析了改良型的raid4的写，那么我们再分析一下它的raid组增加磁盘的过程，在一般的raid组中，想要给raid组增加一个磁盘，是非常困难的，因为数据以前就分布好了，除非再强行改变分布，但是，netapp不一样，它的文件系统本来就是任意写，所以很容易把新加的磁盘给用上。

那么说了这么多，netapp的WAFL与raid4+的优势已经很清楚了：

1、尽量保证数据一次性的写入，减少磁盘争用，提高写速度
2、因为任意写的特点，使得snapshot变得非常简单，而且，就算你不做snapshot，系统本身也一直在不停的产生snapshot，因为这样可以大大减少文件系统的恢复时间。

那么，有缺点吗？肯定有的，这个世界总是没有完美的东西存在的
1、因为任意写，为了保证每次都能操作一个条带，那么，系统希望尽量有充足的空闲空间，如使用率不要超过80%，否则，因为空闲空间太少而不能保证每次都写一个条带
2、因为任意写，可能会使本来连续的空间，分布在存储的任意位置，如数据库应用中，本来连续的表，在存储中多次修改以后，就不连续了，使得全表扫描或者备份变得很慢。
来源： www.ixdba.com  作者： piner

skilljiang

从这篇文章中可以看出，为什么netapp一直说自己的snapshot好，的确是因为他没有进行数据的搬移动作，因此可以做到秒级。
但是缺点也很明显，就是空间使用率一旦超过一定比例，性能会有明显下降。
呵呵~~，WAFL是把双刃剑，大家有地选择。

冬瓜头

电池保护的不是cache ram，而是nvram。这点上楼主好像理解错了。
另外，文件系统被写快满的时候，任何一个文件系统都会变慢，不仅仅是wafl。但是由于lun也要经过wafl，所以造成了即使是写LUN也要考虑vol不能太满，这确实是一个有待解决的问题。矛盾确实存在，底层raid4，上层就得需要wafl的优化，如果不通过wafl而直接映射裸LUN，那么性能又得不到保证。

skilljiang

谢谢矮冬瓜的提醒。

Frank

引用:

原帖由 冬瓜头 于 2008-4-7 16:54 发表
电池保护的不是cache ram，而是nvram。这点上楼主好像理解错了。
另外，文件系统被写快满的时候，任何一个文件系统都会变慢，不仅仅是wafl。但是由于lun也要经过wafl，所以造成了即使是写LUN也要考虑vol不能太满，这 ...

1）Cache有保护么？ 双控制器cache是否有写镜像之类的技术实现？
2）文件系统被写快满的时候，任何一个文件系统都会变慢。。。。这个是为何？能否详细解释一下。
3）还是oracle角度，如果建立在裸设备上，那么“不仅仅是wafl。但是由于lun也要经过wafl”，是否会影响到裸设备性能。
4）“即使是写LUN也要考虑vol不能太满，这确实是一个有待解决的问题”，不明白，请在详细说说

谢谢！！

Frank

多少明白了些,natapp cache没有电池保护的原因，后面3个问题麻烦回一下，谢谢

冬瓜头

1）Cache有保护么？ 双控制器cache是否有写镜像之类的技术实现？
2）文件系统被写快满的时候，任何一个文件系统都会变慢。。。。这个是为何？能否详细解释一下。
3）还是oracle角度，如果建立在裸设备上，那么“不仅仅是wafl。但是由于lun也要经过wafl”，是否会影响到裸设备性能。
4）“即使是写LUN也要考虑vol不能太满，这确实是一个有待解决的问题”，不明白，请在详细说说


1.ram cache没有，因为操作都记录在nvlog中了，所以保护nvram而不是cache ram
2.windows来说，ntfs，当装了软件太多，剩余空间太小的时候，系统就会变慢，因为索引结构变的庞大，查找变慢。碎片增多等。
3.性能影响不大，其他厂家其实也是通过一个虚拟管理层，从这方面来说，没有多少区别。这一层是必须的，除非说只用一块硬盘做个lun。
4.这个和第二个问题一样。

aloe

""如果它也修改一个数据，他可能不管以前的数据的位置，直接把新数据与新校验写到新的位置，之后更改指针，告诉文件系统说，新的数据在这里，而不是原来那里了。""
  那RAID4+ 数据修改中, 那以前的数据如何处理的?   如果不删除,数据积累下去,占用空间过大!  

冬瓜头

引用:

原帖由 aloe 于 2008-4-8 10:55 发表
""如果它也修改一个数据，他可能不管以前的数据的位置，直接把新数据与新校验写到新的位置，之后更改指针，告诉文件系统说，新的数据在这里，而不是原来那里了。""
  那RAID4+ 数据修改中, 那以前的数据如何处理的? ...

当指针修改之后，以前映射的数据块便被认为是空闲的了。