浅析单一冗余校验RAID缺陷--云存储环境下IP存储设备组建策略

前面的话
摘要
一、当前常见阵列组建模式及云存储环境下IP存储设备特点
- 1、只求容量及读写性能的RAID0：
- 2、为了数据安全宁可牺牲容量的RAID1：
- 3、普及率最高的平衡RAID模式RAID5：
- 4、RAID5的升级版，数据安全性更高的RAID6：
- 5、RAID0和RAID1的结合体RAID10（RAID01）：
二、主流raid5阵列可靠性分析
三、经济可靠的IP存储设备阵列选择
- 1、抛弃RAID5！
- 2、不考虑RAID0/RAID1/RAID10。
- 3、RAID6风险不可控。
- 4、zfs+raidz的优势。
四、基于zfs文件系统的raidz阵列灾难救援
- 场景一：损坏一块硬盘也不担心重建失败。
- 场景二、系统崩溃换一块U盘继续提供服务。
五、raidz阵列高效存储技术实验
- 1、数据压缩
- 2、数据消重
- 3、精简配置
- 4、云存储
六、我院现行各类存储系统改进建议
- 1、集中存储
- 2、自建阵列的服务器
- 3、备份用小型nas
- 4、冷备份
- 5、改造一台支持数据消重的ip存储设备
- 6、异地备份
- 7、给个人用户的建议。

前面的话

这篇文章大概完成于7年前（大概2012年），为给一本内部期刊投稿写的，没在网络上发表过。最近刚好有朋友问我自己搭的NAS用的怎么样，他也想搭一个，我才把这篇文章翻出来，先推荐给他看看，顺便也发到CSDN吧。家里FreeNas已经用了7年多，经过了时间的考验，值得信赖，推荐给大家。

摘要

笔者自拥有第一台个人电脑算起，至今已有20多个年头，（转帖备注：清楚地记得是386sx,4M内存*2，210M硬盘，5.25软驱，单显。回想第一次摸电脑，摸的竟然是苹果，你敢信？那时1991年。）期间经历过无数次数据崩溃，深知硬件有价，数据无价。硬盘做为数据的主要载体，20多年来其地位仍无法被其它技术取代。在摩尔定律的指导下，硬盘容量越来越大、价格越来越便宜，可是其可靠性是否也随容量增长了呢？以笔者多年与硬盘打交道的经验看来，硬盘的可靠性与容量是成反比的。本文旨在提出一个经济可靠的大容量IP存储设备的组建方案，并将据此方案组装的IP存储设备纳入到学院正在建设的私有云环境中。（其实同时也是为了自己搭建家用Nas收集资料）
本文首先介绍了当前常见RAID组建模式及云存储环境下IP存储设备特点；在展开分析主流RAID5阵列的可靠性过程中，简单涉及硬盘存储原理，并对关键专有名词进行解读，另有大量的专业用语为了节约篇幅不再赘述，读者可以通过网络方便的查阅；本文宗旨即是提出一个经济可靠的IP存储设备的组建方案，经过前面的铺垫，后面紧接着给出一套当前技术条件下的大容量IP存储设备组建方案，即基于zfs文件系统的raidz阵列系列；为了模拟现实中常见的硬盘单点故障发生时，raidz阵列容灾效果，本文还记录了在实验环境中raidz阵列灾难实验过程；最后根据我院现有各类存储应用特点，量身定制改进方案。raidz阵列中云存储、数据消重、数据压缩、精简配置等高效存储技术的测试过程本文也使用了一定篇幅予以介绍。
为了更好的创作本文，同时也为了文章使用的数据更有说服力，笔者专门采购一批新硬件，搭建起一个简单的Nas系统。本着节能减排、绿色环保的理念，实验中使用了华硕E45M1-M PRO主板集成AMD E450 APU、8G DDR3内存、4块西部数据2TB绿盘、长城0分贝无风扇电源搭建了测试环境，希望给读者传递准确的实验结论，为学院的云存储发展大计献策。同时，本文对所有工作生活离不开计算机，又比较关注自己数据安全的普通用户也有一定的指导意义。（自掏腰包买的哈，收集完实验数据就搬回家，用到现在。）

一、当前常见阵列组建模式及云存储环境下IP存储设备特点

磁盘阵列（Redundant Arrays of Inexpensive Disks，RAID），直译其字面意思：“价格便宜又具有冗余能力的一组磁盘”。原理是利用数组方式来组建磁盘组，配合数据分散排列的设计，提升数据的安全性或提高读写效率。磁盘阵列是由很多价格较便宜的磁盘，组合成一个容量巨大的磁盘组，利用个别磁盘提供数据所产生叠加效果提升整个磁盘系统性能。这项技术能将数据切割成许多区段，分别存放在各个磁盘上。磁盘阵列还能利用冗余校验技术，在阵列中任何一块磁盘故障时，仍可读出数据，在阵列重建时，将计算后的数据存储在新加入的磁盘中。
RAID模式有很多种，最常见的有RAID0、RAID1、RAID5、RAID6、RAID10几种，不同工作模式有很大差异，下面先简单为大家介绍一下它们之间的区别。

1、只求容量及读写性能的RAID0：

搭建RAID0的N块硬盘共同工作，读写数据时，数据平均分成N等份，每个硬盘读写总数据量的1/N，虽然每块硬盘的读写速度没有提升，但N块硬盘可以同时读写，该阵列的理论读写速度比单独的硬盘快N倍，同时阵列的容量也是组成RAID0中容量最小硬盘的单盘容量的N倍。RAID0的缺点就是组成阵列的所有硬盘中，只要有一块损坏，整个阵列就会失败且无法恢复数据。因此特别适合需要高速读写但不需要长期保存数据的需求，比如大型游戏玩家，只追求高速读写体验，不太在意数据安全，一旦阵列出了问题，大不了重装系统和游戏就可以了，也有部分图形工作站采用RAID0阵列，对他们比较重要的数据都存储在支持iSCSI、cifs等协议的IP存储设备上，本地硬盘只用来安装操作系统或图形处理软件，阵列失败对此类用户的损失不大。（当然现在都SSD时代了，SSD组RAID0，同样适用）

2、为了数据安全宁可牺牲容量的RAID1：

如果说RAID0是把所有鸡蛋都放在一个篮子里，那么RAID1就是N个篮子，所有数据都完整的保存在每块硬盘上，共保存了N份， RAID1对数据的读写性能没有任何提升，整个阵列的容量也没有因为组建RAID而提高，N块硬盘组建的阵列总容量等于阵列中最小硬盘的单盘容量。它的最大优点就是数据安全，阵列中只要有一块硬盘是完好的，整个阵列的数据就是安全的。缺点也显而易见，RAID1硬盘空间浪费严重，读写性能只能接近单盘，比较适合极重要数据的保存，由于读写性能不占优势，通常不会单独使用，大多数情况下，RAID1阵列做为整个存储系统的一个分区，存放读写不频繁但非常重要的数据库、用户数据备份等。在实际应用中使用更多的是RAID 1+0，就是将上述两种模式混合使用，既能提升速度和容量，又能保证数据安全，不过投入也成倍提高。

3、普及率最高的平衡RAID模式RAID5：

想要RAID0的速度，又想要RAID1的安全，鱼和熊掌都想要，有没有这样的RAID模式呢？RAID5就是读写性能与数据安全平衡的产物，组建RAID5至少要3块硬盘，每份数据（N-1）等分，存储在任意（N-1）块硬盘上，另有一份异或运算后得到的冗余校验信息存储在剩下的那块硬盘上，阵列总容量等于阵列中最小硬盘的单盘容量乘以（N-1），RAID5的读取速度接近RAID0，写入时虽然要经过一定的运算，但速度大大高于单盘，在安全性上，可以保证整个阵列中，只有一块硬盘损坏的情况下可以恢复出数据，因此普及率最高，大多数服务器安装时的默认RAID组建模式就是RAID5，是专业用户的折中选择。

4、RAID5的升级版，数据安全性更高的RAID6：

在RAID5的基础上，某些专业存储设备制造厂商开发出双重冗余校验的RAID模式，RAID6。在读写效率上，RAID6均低于RAID5，容量上要占用2倍单盘容量的校验空间，因此阵列总容量等于阵列中最小硬盘的单盘容量乘以（N-2），在安全性上，可以保证整个阵列中，有2块硬盘同时损坏的情况下可以恢复出数据。虽然RAID6在一定程度上提高了数据安全性，但由于其性能不占优势，阵列可用容量低于RAID5，第二重冗余校验算法没有通用标准，由各厂商自行设计，一般还要采购价格不菲的阵列卡，因此RAID6的普及率不高，只在少数专业存储设备上使用。

5、RAID0和RAID1的结合体RAID10（RAID01）：

以4块盘为例，RAID10是指每2块盘组建RAID1阵列，再把2组RAID1组建成RAID0，RAID01正好相反，每2块盘组建RAID0阵列，再把2组RAID0组建成RAID1，同样是RAID0和RAID1的组合，在发生故障时，RAID10的数据安全性比RAID01高33%，并且两种组建方式都利用了RAID 0极高的读写速度和RAID 1较高的数据冗余能力，在读写性能上没有差别，RAID10更高的安全性使它成为了一种性能及安全性都比较高的RAID模式，而RAID01阵列很少有人组建。但RAID 10对硬盘容量的利用率比较低，只有50%。RAID 10能提供比RAID 5更好的性能。缺点是这种RAID结合的模式可扩展性不好，价格也比较昂贵，因此RAID10阵列模式未被广泛应用。

在云存储环境下，对加入私有云的IP存储设备有什么特殊要求呢？本文讨论的IP存储设备并非在生产环境中为服务器提供集中存储的nas设备，而是侧重于为日常办公、备份数据文档提供服务的存储设备。一般来说，应该具体以下几方面：

最基本的读写速度要有保证，最高写速度不低于40MB/s，最高读速度不低于60MB/s，日后有扩展需要时，可以配合交换机的链路聚合技术进行带宽升级；
最大限度提高硬盘空间利用率，组建可靠的冗余阵列，保证数据安全性；
在给各部门业务人员提供数据共享服务时，通常繁忙时段在8小时工作时间内，其它时间访问较少，要在无人访问时可以自动进入待机状态，绿色环保、低碳节能；
支持iSCSI/cifs/nfs/ftp等协议，可以支持用户通过iSCSI发起程序、共享映射、ftp工具方便的实现数据异地备份。

二、主流raid5阵列可靠性分析

RAID 5旨在从单次数据故障中恢复数据，通过添加一个冗余校验盘（一份数据条带的冗余校验数据可能存在于任何一块硬盘），作为对等数据 XOR 计算，从而实现数据恢复功能。

学院在考虑使用一种云计算模式作为存储网络架构的一部分，大多数情况下，数据复制的私有云计算要使用低成本的硬件。由于笔者接触过的多种存储环境并考虑到厂商公布的硬盘故障率，本人比较担忧使用这种方法的可靠性。因此，这部分篇幅要做的就是一步一步地分析在大多数云计算中使用低成本硬件的特性。

在RAID5大行其道之时，硬盘的容量基本不超过100GB。那时做RAID5的磁盘容量都不大，比如72GB，当时可不曾听说大量的RAID5失败的案例，随着硬盘容量越来越大，RAID5失败的灾难越来越多，到底是为什么呢？

我相信很多人在日常生活中也都遇到过硬盘卡壳、掉链子的情况。当然，重要的数据都应该有备份，但是我们显然应该采取各种各样的手段来阻止没有及时备份的那一小部分数据的丢失。硬盘很便宜，它会坏掉！实践经验会这样告诉你，不管这个硬盘是来自什么厂商，也不管它是SATA、SCSI、SAS或者是传统的IDE接口，它出现故障只是时间早晚的问题，这是无可辩驳的真理。那么正常情况下一块硬盘使用多久会坏掉？什么情况下坏掉的硬盘会导致阵列失败？对于第一个问题，我们先看看表1中硬盘厂商给出的数据：

表一厂商给出的各接口类型硬盘参数

由表中数据可知，两种接口硬盘的无故障运行时间（MTBF，Mean time between failures）是极其接近的，差别至少还在一个数量级内，只不过便宜的SATA硬盘要比昂贵的SCSI硬盘误码率（BER，Bit Error Rate）要高得多。也就是说，出现某个扇区无法读取的情况，SATA要比SCSI严重得多，要高出一到两个数量级。

从理论角度说，每个硬盘的MTBF大约为50万至150万小时，也就是57至170年会发生一次硬盘损坏。实际使用肯定不能达到这种理想的情况，在正常的散热和机械条件下，都会造成硬盘工作的时间大幅减少。考虑到每个硬盘的寿命不同，阵列中的任何硬盘都可能出现问题，从统计学角度说，阵列中N个硬盘发生故障的机率比单个硬盘发生故障的机率要大N倍。结合上述因素，如果阵列中的硬盘数量合理，且这些硬盘的MTBF较短，那么在阵列的预期使用寿命过程中，就极有可能发生硬盘故障，举例来说，学院所有组建阵列的硬盘如果有57块，很可能每隔1年就会发生一次故障。我们都知道RAID 5只允许一块硬盘损坏，那么两块硬盘同时损坏的概率有多大呢？这里的“同时”是指一块硬盘尚未完全修复时阵列中的另一块硬盘也坏掉了。如果说RAID 5 阵列的MTBF相当于单个硬盘MTBF的平方，那么这种概率为每隔〖10〗^15
个小时发生一次，也就是1万多年才出现一次，因此不管工作条件如何，发生这种情况的概率是极低的。仅仅表示数学理论角度是有这种概率，在现实情况中我们并不要求考虑这一问题。不过，时常听说发生两块硬盘同时损坏的情况，我们没遇到，可能是运气好，谷歌一下，此类案例数不胜数，比较出名的大亚湾核电站使用五块SAS硬盘组建成RAID5，安装ESXI3.5虚拟机操作系统，在上面运行着三套操作系统，由于其中一块硬盘损坏，另外一块硬盘出现坏道，导致文件系统结构性损坏，无法识别VMFS文件系统。实际上两块硬盘同时损坏的原因与MTBF基本没有任何关系。这里要特别解释一个一般人不常接触到的参数：BER，它是描述硬盘性能的一个非常重要的参数,是衡量硬盘出错可能性的一个参数。这个参数代表写入硬盘的数据，在读取时遇到不可修复的读错误的概率。这个概率一般来说是指每读取多少bit后会出现一次读取错误。SATA硬盘读取〖10〗^14bit后会出现一次读取错误，按照笔者的计算，换算成以TB计的无误码数据量，6块2TB的SATA硬盘组建的RAID5，当某一块硬盘因MTBF原因损坏时，其它硬盘出现BER的概率将达到91%，因此在这种情况下重建RAID5的结果是：基本无法重建。

说到91%，上面这个数据还是显得有些不可信。以我们日常使用经验来说，怎么没有听说过这么高的BER？事实上，这里的91%是根据硬件厂商公开数据推算的，还有些我们心知肚明的因素，导致我们买到的硬盘参数可能还达不到表1中给出的数据，正如家里使用的宽带，永远达不到接入商标称的速度一样。（现在带宽不错了哈，开的200M，实测255M）造成理想与现实巨大反差的原因，大概是这样子的：
1、我们日常使用硬盘都不会组建RAID。虽然现在硬盘容量也变得很大，但是这个数以T计的硬盘上面大多数数据都很少去读取它。因此从概率上讲，坏扇区出现在那些尘封的电影和音乐上的可能性大很多；对于组建RAID5的用户，对整个硬盘进行完整读取的操作只有在重建时发生。大多数情况下，坏扇区仍可能潜伏在从不读取的文件中。
2、虽然你丢了一些扇区，一般情况下也没太大关系。还是以影音文件为例，大多数的压缩算法都从设计上允许有一些这样或者那样的误码。丢了几个扇区的数据，也许对你来说就是电影里肉眼都无法识别、一闪即过的暗点而已，你不会知道是硬盘作祟。为了证实硬盘存在BER，笔者通过某大型B2C网站采购了一批新硬件，看一下91%是不是真的可信？

全新硬件搭建的实验环境

笔者使用图一所示硬件，在U盘上安装FreeBSD操作系统，用4块硬盘组建raidz软阵列（raidz是zfs文件系统的叫法，相当于ntfs/ext下的RAID5）。这里用raidz的原因是raidz有数据巡检功能，又能直观地看到数据巡检的结果。一般插在主板PCI/PCIX/PCIE接口上的硬件阵列卡或者主板集成的RAID5，根本就没这项功能。企业级的数据存储，也只有到盘阵级别（比如IBM DS3000/4000/5000/N3300）才有这类功能，但是看不到检查的结果，只能在日志里看到某个硬盘CRC失败，然后跳红灯掉出来，阵列柜报警通知你换硬盘。用户不会知道这个硬盘到底是彻底坏了，还是有读取错误，还是有坏道，两眼一抹黑。

zfs的好处之一就在这里了：在命令行输入 zpool scrub Nas （Nas就是笔者创建的zpool的名字），它就开始忠实地开始巡检整个阵列，读取上面的每个字节数据，并与当初写入时的md5值进行比较，发现错误的话就报告，并尝试用冗余数据修复。这个过程是后台进行的，并且用户可以直观地看到巡检的进度、速度、所需时间以及结果。

上图是巡检过程

上图是巡检结果

为了这次测试，笔者花了一星期时间用各种各样的数据把阵列几乎塞满。首先解释一下上面的数据的意思。图二scan行，表示2012年10月25日晚20:31分开始巡检工作，目前仍在巡检中，该zpool总容量7.13T，巡检完成7.09T，巡检速度180M/s，大约还需要3分钟完成，巡检进度99.46%，已修复17G数据。图三scan行，表示上次巡检完成于2012年10月26日早8:03分，共修复了17G数据，花费11小时32分，没有不可修复的错误。图二config行是4个硬盘的编号和状态，请读者注意的是第3块硬盘的最后一列，也就是提示repairing括号前的CKSUM数据。看到没有，这块硬盘出现了398K的读取错误，配合scan行的扫描结果，笔者猜测受损的很可能是一份17G大小的数据库备份文件，不过经过巡检，已经成功的通过冗余数据修复。不要小看这398K，如果没有经过巡检，在RAID5阵列的某块硬盘由于MTBF原因坏掉时，就算用一个全新的硬盘替换坏掉的硬盘，也无法顺利重建RAID5。对于市面上常见的阵列卡，直接的后果就是在用热备盘重建时，或者尚未开始重建仅因没有及时发现硬盘坏掉，又或者手头、仓库没有备用盘，新硬盘在采购途中等等原因，RAID5要带病运行时，需要读取的数据偏偏又很不凑巧存放在那个BER扇区，于是BER扇区所在的硬盘再次跳红灯掉出来，所有数据将不可恢复！

单一冗余校验RAID缺陷就在这里了，请读者注意，实验硬件全部是新的；硬盘中的数据才刚刚写进去，最早的数据也仅仅写入一个星期。同时总读取流量不会超过15T（写入的同时马上会读取一次约7T，巡检时完整读取一次约7T，其它测速实验读取流量大约不足0.5T），印证了表1。这是RAID5的缺陷，不是运气问题，从BER 角度说，硬盘其实已经损坏了，只是我们没发现而已。当某个硬盘因为MTBF原因整个坏掉，有问题的BER扇区开始跳出来作梗，于是RAID5就不可重建了。

笔者总结一下避免RAID5无法重建的经验：

使用小容量的硬盘做RAID5，遇到BER扇区的概率小；比如用100G硬盘做RAID5就比用1TB的安全；
使用少数的硬盘做RAID5，遇到BER扇区的概率小；比如用3个盘做的RAID5，比6个盘做的RAID5安全；
使用企业级硬盘做RAID5，遇到BER扇区的概率小；比如用SCSI/FC/SAS盘比用IDE/SATA的RAID5安全；
RAID5里面存放的数据尽量少，遇到BER扇区的概率小；比如存了100G数据的RAID5比存了1TB数据的RAID5安全；
选择带有强制上线功能的高端阵列卡，某些卡重建时只读取存过数据的扇区，遇到BER扇区的概率小，某些卡则不管三七二十一要读完整个盘。带强制上线功能的阵列卡，可以在遇到BER扇区时，跳过损坏文件继续在缺盘的情况下运行RAID5，方便用户备份重要数据。
由于RAID5以最小的冗余代价（一块硬盘）换取成几何级数增加的安全系数（MTBF的平方），同时读写性能又有成倍的提升，所以一定要用单一冗余校验组建RAID的话，建议采用其它技术加以规避减轻风险；比如定期巡检硬盘以避免由于另一块硬盘的故障造成同一条带上的数据发生双重故障。

三、经济可靠的IP存储设备阵列选择

1、抛弃RAID5！

在GB存储时代，RAID5是相对可靠的，即使用SATA组建，问题也不大，3块200G的硬盘组建RAID5，在MTBF引起硬盘单点故障时，其它2块硬盘出现BER的概率只有3.6%，3.6%已经很不错了，因为在硬盘故障之后，才需要去恢复RAID。两个概率是要相乘的。
进入TB存储时代，SAS/SCSI组建的RAID5仍有一定的安全系数，主流SAS硬盘容量也不过300G，但组建云存储时，SAS硬盘高昂的价格很难被大家接受。假设我们有6个SATA硬盘组成阵列，每个硬盘容量为2TB，BER为读取〖10〗^14bit出错一次，那么计算如下：
(9×12×1Tbit)/(〖10〗^14 bit)，得出每1.08次重建就会出一次严重问题，这就要引起我们的高度重视了。我们
这里所谈的是12TB容量的阵列，这是当前技术可以轻松达到的水平。也就是说，这种容量大小的阵列每108个中，就有100个阵列会出现重建发生扇区损坏的问题。而组建云存储最适合的硬盘就是SATA盘，选择SATA就只有抛弃RAID5了。

2、不考虑RAID0/RAID1/RAID10。

RAID0毫无安全性，RAID1/ RAID10硬盘利用率过低，亦不适合组建经济的云存储。

3、RAID6风险不可控。

考虑RAID6不是需要它恢复两个同时发生的硬盘故障，而是能用完好的对等硬盘恢复一个硬盘故障和一个BER。随着硬盘容量的上升，这种错误的发生几率也在增加。我们要在价格与风险之间进行权衡，SAS等企业级硬盘的MTBF长、BER更低，因而出问题的可能性也就少，而低端SATA有助于大幅节约购买硬件的投入，却会面临较高的双重故障几率。可是RAID6需要单独采购阵列卡，其价格大约相当于2-3T硬盘，个人认为，在阵列硬盘个数比较少（少于6个）的情况下，RAID6没有RAID1的性价比高，而固化在阵列卡上的第二重冗余校验算法各厂商自成体系，甚至同一厂商，不同批次的算法也不相同，同时，阵列卡的MTBF更是没有依据可查，故障风险不可预估，工作中就遇到过仅因阵列卡电池出现单点故障，整个阵列的数据就颗粒无收的情况。

4、zfs+raidz的优势。

raidz此时有它独特的优势：支持自动巡检自动修复BER；重建时即使存在BER扇区，它也能跳过坏扇区继续读取其他数据，从而将损失控制在最小范围内，仅仅是BER扇区所在的文件有问题，而不会整个阵列挂掉。raidz重建遇到BER可遇不可求，暂时没有条件通过实验验证，不过Oracle官方文档给出这种情况下，巡检结果会把图三中的errors列替换为如图四所示内容：

Oracle文档中给出的raidz重建遇到BER的情况

巡检后发现若干个不可恢复错误，但是损失仅仅是4个文件。而且能指出这4个文件的位置及文件名，并且这4个文件也不是完全不能读取，仅仅是某些字节损坏而已。如果这4个文件中是影音、照片，损失几个字节无伤大雅，也许其他地方另有备份，可以重新复制过来；如果是某些系统文件，只需重装软件或系统即可恢复，总之，raidz可以将损失控制在能容忍的范围内，这就是raidz的优势了。
定期巡检的raidz，在发生阵列灾难时可以将损失控制在能容忍的范围，可是它是否满足第一章结尾提出的基本要求呢？还是用图一的实验环境，进行测速实验。

基本读写速度测试

使用cifs协议共享映射读写速度对比测试图

使用ftp协议读写速度对比测试图

使用iSCSI协议读写速度对比测试图

网络接口通信图

物理内存使用效率图

随机读取对比测试图

图五、图六分别使用Windows共享网络磁盘和ftp软件方式测试连续读写速度，这两种方式平均读速度可以稳定在50MB/s左右，平均写速度可以稳定在30MB/s左右，通过图八在一个小时时间内以ftp的形式连续读写时，网络接口通信图可看出，平均读速度在45MB/s左右，平均写在35MB/s左右;而图七是通过iSCSI方式连接网络磁盘，在进行文件读写测试时，高达8G的缓存发挥了重要作用，由图九可知，物理内存占用量迅速攀升到6G，读写峰值基本达到了千兆局域网的传输极限，稳定后的平均读速度仍达到95MB/s，平均写速度达到75MB/s。同时，通过最接近日常使用情况的随机读取测试可知，在各级别数据块传输效率上，iSCSI的IOPS均接近或高于本地硬盘，如图十所示，因此在独享备份空间的情况下，应尽量使用iSCSI方式连接共享存储设备。

raidz以最小的冗余代价换取成几何级数增加的安全系数，同时读写性能又有成倍的提升，最大限度提高了硬盘空间利用率，同时采用定期巡检技术避免由于另一块硬盘的故障造成同一条带上的数据发生双重故障，可以保证数据安全性。
开机瞬间功率70多W，满负荷运行时，整机功率也从未超过60W；当无人访问时可以自动进入待机状态，整机功率不到30W，绿色环保、低碳节能。要知道，普通台式计算机如果采用主流Intel 酷睿i5系列CPU，仅CPU一项热设计功耗就达95W。

满负荷运行和待机运行两种工作状态下的功率
图五、图六、图七已经展示了通过iSCSI发起程序、共享映射、ftp工具实现的数据备份的过程。

四、基于zfs文件系统的raidz阵列灾难救援

场景一：损坏一块硬盘也不担心重建失败。

上图是正常状态的存储池

为了测试阵列硬盘损坏，笔者拔掉一块硬盘的数据线，然后启动。系统报原da3p1位置的硬盘已完全无法读出，整个zpool降级了。原来的盘被改名为一串数字。

上图是被降级了的存储池
还需要重点注意的是，降级的阵列仍是完全可用的。此时读写阵列上的文件一切正常。为了让这一实验更加真实，在降级的状态下，笔者又复制了500M的数据到陈列中。

降级状态下写入500M数据，test数据集已用空间对比图

接入一块新的硬盘，用zpool replace 命令替换故障的硬盘，（resilvering）表示 zfs正在为指定的驱动器重新构造相应数量的数据。此时，降级的阵列仍是完全可用的。

处于恢复状态的降级阵列

经过41分钟的重构，数据已经完全重建到新的硬盘上，此时只需把故障的硬盘位offline，整个阵列就再次online了。

构造完毕后，存储池的状态回复正常

场景二、系统崩溃换一块U盘继续提供服务。

模拟系统崩溃，无法启动的场景，换另一个U盘启动阵列，第一次启动之后，系统自动更新了阵列信息，随后自动重启，再次进入系统后，阵列已经可以正常读取，并且曾经恢复过的硬盘已经被新的系统重新编号。

用另一套启动盘启动阵列后，阵列状态正常

zfs这种系统盘和数据盘彻底分开的架构，使多系统盘备份成为可能。图一所示的测试环境，笔者就装了两个u盘，随便一个都可以读到阵列。用u盘A启动时，即使关机时没有做export的操作，用u盘B启动后，依然能读到所有的数据。也就是说，系统盘不再是单点故障点了，坏了立刻有替换的。成本是20元，一个2G u盘就可以做一份备份。如果系统是装硬盘上，得花多少钱、准备多少个硬盘？

上述2个场景，基本能够把绝大多数系统的单点故障去除掉了：坏硬盘，不怕的；坏系统盘，不怕的；坏raid卡，软raid不需要raid卡没法坏；坏主板、内存或电源，随便买个新的配件系统照样运行，根本不用买相同型号的。

五、raidz阵列高效存储技术实验

用数据爆炸来形容当前的存储规模再合适不过了，学院需要不断采购各式各样的存储设备来满足日益增长的存储需求。可是，单纯依靠采购存储设备来提升容量，并不是问题的根本解决之道。
其一，存储设备的采购成本越来越高，特别是更安全更专业的企业级阵列柜，任何用户都难以承受这样无边无际的开支。
其二，随着数据规模的扩大，存储管理成本、占用空间、能耗、安全隐患等也都变得越来越严重，其中数据安全尤为突出。
其三，各式各样异构的存储设备大大增加了管理复杂性，更容易造成资源浪费或使用效率不高，甚至因管理不善造成备份丢失。因此，需要另辟蹊径来解决数据爆炸式增长的问题。高效存储理念正是在这样的前提下提出的，它旨在缓解存储系统的空间无限增长问题，缩减数据占用空间，简化存储管理，最大程度地保护已有投资，降低成本。目前业界公认的五项高效存储技术分别是数据压缩、重复数据删除、自动精简配置、自动分层存储和存储虚拟化。
目前，数据压缩和重复数据删除是实现数据缩减的两种关键技术。简而言之，数据压缩技术通过对数据重新编码来降低冗余度，而重复数据删除技术侧重于删除重复的数据块，从而实现数据容量缩减的目的。

1、数据压缩

压缩后的数据极大减少对硬盘空间的占用，这一点大家都非常熟悉了，只不过平时我们使用的压缩技术都是通过第三方软件来实现的，比较常用的一般是winrar、7zip，而zfs的压缩是一种即时压缩技术，在启用数据压缩的数据集上，所有写入的数据都先要经过内置算法如lzjb/gzip/gzip9去除数据表达的冗余，从而达到降低IO、缩减存储空间的目的。数据压缩技术对IO密集型应用很有用，同时也适用于文档的备份，而影音、二进制文件压缩效果就不太明显。数据压缩对于普通用户来说也不是什么高深技术了，在此就不多做描述，仅以一例展示一下使用了gzip9压缩算法的zfs数据集，应用在论文最终稿的备份时的使用效果：

压缩前后空间占用量对比图

在Windows服务器上看到，这批论文稿占用空间3.27G，在考入到raidz阵列后，空间只占用了2.19G，压缩比67%。

2、数据消重

在备份、归档等存储实践中，人们发现有大量的重复数据块存在，既占用了传输带宽又消耗了相当多的存储资源：有些新文件只是在原有文件上作了部分改动，还有某些文件存在着多份拷贝，如果对所有相同的数据块都只保留一份实例，实际存储的数据量将大大减少，这就是重复数据删除，简称数据消重技术的基础。带有数据消重功能的IP存储设备，加入到云存储环境中，对数据库备份类的应用，是非常有用的，它会彻底颠覆传统预算理念，极大缩减备份文件占用的空间。
数据库的重要性怎么强调也不过分，因此为数据库进行密集备份就成了保障数据安全的主要手段之一。密集备份导致的问题也很明显，最主要的问题就是空间占用极其严重。以学院目前的necinfo主库为例，一份完整备份大约15G，小时级备份采用滚动模式，占用空间可忽略不计；日级备份数量惊人，一年的备份就需要占用15*365=5475G空间，即使超过1年的备份每周只保留一份，保存最近6年的周备份又要占用3900G空间，这还不止，随着数据库体积的增长、时间的推移，对备份空间的占用将呈线性变化，永无止境。
zfs支持块级数据消重，特别适合数据库备份这类应用，具体技术细节本文不再展开介绍了，这里简单展现一下利用这项“神奇”的技术模拟数据库备份的过程。为了使实验效果更直观，笔者继续使用图一所示，几乎被塞满的实验环境。首先创建一个名为Dedup的数据集，创建好之后，分别用zpool list / zfs lit /df -h 命令显示该数据集的空间占用情况，初始状态下，zpool list 看到的DEDUP值为1.00X，表示数据消重比为1倍，即没有任何数据块消重；zfs list 看到本数据集已使用250K空间，由于没有写入任何数据，这250K应该是系统自建的冗余元数据；df -h看到数据集所在逻辑目录的可用空间，由于此时整个阵列几乎被塞满，这时看到的总空间为10G，可用空间亦为10G。如下图所示：

新建的Dedup数据集空间占用情况

在写入第一份数据库备份后，再次用上述三个命令查看空间使用情况，没有发现什么特别，与普通的存储设备无异，图二下显示已用空间增加3.66G，可用空间减少3.66G。这里特别提醒读者留意一个参数，用df -h命令查看得到的可用空间还有6.6G，后面的实验我们要关注的是，这6.6G还能写入几份备份。

写入第一份备份后Dedup数据集空间占用情况

当写入第2份备份后，统计结果开始出现变化，zpool list查看到的DEDUP开始增长，显示为1.87X，df -h查看到的可用空间只减少了300M，而该目录的总空间增长为13G，这期间没有任何文件被用户删除。

写入第2份备份后Dedup数据集空间占用情况

更直观的结果，如下图所示，随着备份文件的不断写入，Dedup数据集的空间出现的神奇的变化，写入的备份文件越多，逻辑目录的总空间越大，代表已用空间的红线却永远追不上代表可用空间的绿线，这个初始可用容量只有10G的设备已经写入43.7G的数据了。

Dedup数据集某小时内空间占用变化情况

模拟数据库备份文件写入过程仍在进行中，已经有30份日级备份文件写入阵列，这时再用上述三个命令查看，数据消重比已经达到13.37倍，原本只有10G总空间的逻辑目录，已经神奇的变成了112G，并且还有19M的可用空间。

写入30份备份后Dedup数据集空间占用情况

在确定可用的池和文件系统空间方面，zpool list 和 zfs list 命令要比传统的 df 和 du 命令出色。使用传统命令，既不能轻易分辨池和文件系统空间，也不能对后代文件系统或快照使用的空间做出解释。因此也就出现了在没有删除任何文件的情况下，df命令查询到的目录空间出现莫名其妙增长的现象，而zpool list 和 zfs list从始至终都精确的给出可用空间和已用空间大小。zpool list 命令报告的 SIZE 值通常为池中的物理磁盘空间量，具体大小视池的冗余级别而异，可以理解为是解除冗余后的空间。zfs list 命令列出了可供文件系统使用的可用空间，该空间等于磁盘空间减去 ZFS 池冗余元数据开销（如果有的话）。
当模拟的数据库备份文件写入结束时，Dedup数据集已经写入了125G的数据，前面请读者留意的6.6G空间，最终写入了34份备份。仔细想想，其实不难理解，虽然单独一份数据库备份很大，可是每天变化的数据量很小，把3.7G一份的备份切成4KB一块的无数的数据块，相信相邻2天的备份绝大多数数据块都是完全相同的，数据消重技术就是利用这一点，相同的块只保留一份，因此极大缩减了备份文件占用的空间。而且消重技术还可以同压缩技术协同使用，进一步提高空间节省效果，以笔者做的测试来看，以某时间段连续数据库备份文件为样本，在已经启用数据消重的情况下，再启用数据压缩功能，可以额外获取10%-20%的空间节省效果。不过，由于消重和压缩都是cpu密集型操作，因此两者同时使用会给系统带来比较大的运算负担，造成比较明显的读取延时。另外，通过测试也发现，就单一文件来说，压缩的空间节省效果远远好于数据消重。但是压缩并没有含盖整个数据集的全域对比能力，仅对单一文件、单一作业的情况下有效，无法检测出后续写入的资料是否与已有的资料重复，在资料形态大致相同时，只能得到一个固定的空间节省比率，不像数据消重，具有文件越多，后续节省比率越大的效果。先启用数据消重，再启用数据压缩，可以达到最佳的空间节省效果，不过对系统性能的影响也最大。

3、精简配置

自动精简配置是一种存储空间管理技术，是利用虚拟化方法减少物理存储占用，可最大限度提升存储空间利用率。它的核心思想是“欺骗”操作系统，让其认为存储系统中有很大的存储空间，而实际上的物理存储空间并没有给它分配那么大。自动精简配置减少已分配但未使用的存储容量造成的浪费，根据用户的实际所需自动分配和利用存储资源。目前，IBM、HP、DELL的高端磁盘阵列均支持该项技术。raidz系列阵列的iSCSI共享方式也使用了精简配置技术，笔者在阵列接近写满的情况下，仍然可以创建多个2TB的虚拟磁盘，供操作系统共享使用。

4、云存储

随着存储的需求激增，物理存储资源（如服务器、磁盘阵列、IP存储设备）也随之成倍增长。这种分布式异构存储资源的蔓延发展最终使管理变得异常困难，从而导致存储资源未被充分使用，造成投资的浪费。对于这种存储管理困境的一种解决办法便是云存储。云存储是一种存储虚拟化，它将分散的物理存储资源整合抽象成单一逻辑资源池，使得管理员仅以单一的逻辑视图对存储资源进行识别、配置和管理。云将存储资源的物理特性隐藏起来，对于用户来说云存储资源就像是一个巨大的“存储池”，而不必关心其背后的物理存储设备。它能方便管理，并且能够最大化存储利用率，减缓存储需求。raidz系列阵列，支持标准的iSCSI/cifs/nfs/ftp等协议，可以方便的加入的云存储环境中来。

六、我院现行各类存储系统改进建议

1、集中存储

这是我院性能最好，可靠性最高的存储设备，组建的是RAID-DP阵列，双控制器互为冗余，并且支持每周一次自动巡检，虽然没有采用SAS硬盘而是企业级SATA硬盘，可靠性仍然很高，笔者翻阅了近2个月的巡检日志，没有一处校验错误。RAID-DP是NetApp自行开发的双冗余阵列，简单理解可以等同为RAID6，在两块硬盘同时故障时仍能保证数据安全。将它做为tomcat集群的集中存储是可靠的、高效的，数据库的日级滚动备份也可以放在这里，分层存储技术在我们的使用环境中不适用，除数据库主文件外的所有核心数据都可以存放在这台设备上，由主控利用生命周期管理技术来甄别数据，自动地把那些不常被访问的数据或过时的数据转移到速度较慢、成本较低的存储区域，而把那些经常被访问或重要的数据放在速度较快、成本较高的高速缓存或固态硬盘（SSD）上，以此来提升性能。当集中存储设备空间不足时，可以很容易地通过扩展柜扩容。

2、自建阵列的服务器

我们仍有部分服务器自建RAID5阵列，虽然采用自建阵列的服务器均使用的SAS硬盘，但这类服务器仍有一定的风险，应找合适的机会尽量改建RAID1或RAID10阵列。

3、备份用小型nas

这是典型的低效率、低能力、高容量存储，致命的是，用便宜SATA组建了RAID5。应该尽快转移数据，改建RAID1或RAID10，用于课件建设中间数据的保存、备份。

4、冷备份

组建任何阵列的情况下，多做冷备份都是必要的。对于结题的课件、关键时点的数据库、定期导出的运行数据，都应有一套冷备份，主要利用USB硬盘盒、刻录蓝光盘等方式。

5、改造一台支持数据消重的ip存储设备

利用现有设备，搭建一套基于zfs文件系统的raidz系列阵列，最好采用双重奇偶校验的raidz2阵列，利用优异的数据消重特性，实现用傻瓜式完整备份就能达到精确的增量备份的效果。新技术颠覆了传统的预算理念，不需要再以备份文件大小乘以可用天数来估算备份空间，只要粗略的高估数据库每天增长1G（显然是不可能的），1T的备份空间就足矣满足未来三年的日级备份存储需求。同时，课程网站、视频讲解等内容的备份也可以迁移到改造好的设备中来，这类备份很可能写入一次，就不会被再次读取，因此可以采用消重+压缩协同的方式最大限度节省空间，而采用傻瓜式的完整备份，只需每月把课程网站根目录“暴力”的备份到该设备，zfs自动消重，实现精确的增量备份效果。

6、异地备份

RAID组建模式再安全，单点故障全排除也不能保证数据的绝对安全，因为有一个因素无法抵抗，它叫：不可抗力。不管目前备份方案多完善，所有数据副本还是存储在学院机房这个物理空间里，冷备份副本可能存放在某办公室的保险柜里，但怎么也没跳出学院大楼这个物理空间。火灾、地震、战争等不可抗力发生时，所有副本很可能被“一锅端”。居安思危，异地备份首先要防止数据泄密，且不需要太频繁，只是在不可抗情况发生时，尽可能减少灾后重建的损失。

7、给个人用户的建议。

如果在单盘上存放了非常重要的数据，又不想做RAID的话，只有经常做冷备份：刻录光盘或复制到移动硬盘，单盘BER引起的数据丢失是没有办法恢复的，只有备份备份再备份。对于总量不大又非常重要的数据，如果条件允许，最简单的办法就是组建双盘RAID1。个人用户使用硬盘数量一般不大，通常3-5块，下面就以4块1T硬盘为例，给出常见使用环境中，最优RAID组建方案：

表二常见使用环境中，最优RAID组建方案