（本文镜像于： http://cloudme.info/?p=32）
1. 前言
RAID（Redundant Array of Independant Disks，独立冗余磁盘阵列），已经火了二十来年，在存储领域一直是速度和可靠性的代名词。专业的存储，没有看见谁不用RAID的。RAID提供了很多级别，常用的有0，1，5，6，10等。其中，兼顾性能（数据并发访问）和可靠性（利用冗余来提升）的RAID5,6,10是在实际应用中利用得最多的，尤其是RAID5，几乎成了考察磁盘阵列性能的首选测试级别。除了专业存储的设备（NAS,SAN等），普通操作系统对RAID也有很好的支持，比如Linux内核中的md模块就是用软件来实现RAID的，同时在用户态有一个管理程序mdadm能够对RAID进行复杂的配置。
本文以分析RAID5为主，来谈谈云时代RAID技术所遇到的一些情况。
RAID5能够容忍任意一块磁盘出错，保证在出错的时候磁盘仍能顺利读写。在大多数人看来，两块磁盘同时出错的概率并不是很高，所以一般认为RAID5也就足够用了。且现在的磁盘阵列都提供热备盘，只要有盘出错，就会自动把空闲盘加入RAID5中，利用剩下的好盘重建数据，把计算出来的数据写入新盘。当数据重建完成之后，该设备就完好如初了，又能容忍任意一块盘再出错。看上去似乎很不错。
假设一个RAID5设备由n块磁盘组成，则实际存放数据的磁盘有n-1块，另外一块盘用来存放Parity（校验码，RAID5的校验盘是分散在每个磁盘中的，合计共用一块盘），则数据的有效利用率是(n-1)/n，这是一个比较高的值，尤其是当n比较大的时候，它的利用率就越高；该设备能够并发访问(n-1)个盘的数据，理论上也可以达到单盘速度的(n-1）倍，这也是很高的一个值。看来，RAID5在速度，空间利用率，容错性上都得到了很好的平衡，理所当然地成为许多人的首选了。
事实果真如此吗？RAID是在1987年提出的，那个时代，硬盘还是非常昂贵的设备，RAID的优势在于能够在控制整体成本的基础上兼顾性能和容错。如今，磁盘越来越廉价，数据本身越来越重要，时过境迁，一些应用模式也发生了根本的变化。如今，Google的文件系统，Hadoop的HDFS等分布式文件系统大行其道，它们有一个共同的特点，都是利用简单地把一组数据复制到多个计算节点的方法来实现冗余的，单机并不做RAID（最多做不损失容量不提供冗余的RAID0），已经抛弃了传统的RAID概念。这样看似成本会高不少——在传统的RAID中，提供数据冗余可靠只需要多用一两块磁盘就可以了，但现在却得多好几倍的磁盘数（一般情况下冗余度至少为3，也就是说至少要用3倍于原始数目的磁盘），还得采购更多的计算节点，这，成本不是高那么一点点吧？下面我会从可靠性，性能和成本三个方面对RAID加以分析。
2. 可靠性
云计算，可靠性是用户担心的首要问题。要达到宣传中所提及的99.99%的UPTIME（正常运行时间），一年也就只能宕机一小时左右。如果有过两三次不能正常使用的情况，用户无疑会对这项业务产生怀疑。用户的不信任是云计算商业运用的一大杀手，保证可靠性对云计算提供商来说，无疑是最紧迫的任务之一。也许部分用户的业务不需要如此高的可靠性，但是既然作为云计算，服务的对象就是千千万万的大众客户，总有一些人是需要很高的可靠性的。更重要的是，媒体对这种事情非常敏感，他们的宣传，如同一把刀架在提供商的脖子上面，逼迫他们不得不提供原高于正常水平的可靠性。否则，谁会用你呢？
1.1 硬盘的高坏盘率
RAID5只能提供一块磁盘的容错率。但是，硬盘的坏盘率其实是很高的，尤其是在服务器上，硬盘始终在工作，很少有休息的时候。据Google的论文（labs.google.com/papers/disk_failures.pdf）报告，硬盘的年坏盘率为1.7%-8.6%。显然，在一小段时间内，两块或者更多的磁盘坏掉的可能性并不是那么小。也许可以不选择RAID5，而采用RAID6。的确，仍使用RAID的许多高可靠性系统中，也有不少是采用RAID6的。RAID6能够提供任意两块盘的容错率，但是由于要生成两组校验码，所耗费的资源也比RAID5大不少。
1.2 RAID的长时间重建（rebuilding)
当有盘坏掉的时候，会加入热备盘来重建数据。现在的磁盘容量都很大，以使用得最多的SATA盘和典型容量1TB为例，一般来说，单盘速度可以到100MB/s，假设重建数据的过程全速运行，则这个过程也需要耗时将近3个小时（事实上很多时候实际重建速度达不到这么快）。在这3个小时内，RAID5是没有数据保护功能的，如果再有一块盘出问题——哎呀，那后果就比较严重了。事实上，在RAID5重建数据的过程再有盘出错是比较容易见到的。因此总是出现很多企业为如何恢复数据而焦头烂额。磁盘速度的提升远没有容量的提升快，因此未来重建数据花费的时间可能更长，这个问题更突出。
1.3 RAID对硬盘外的错误无法处理
RAID还有一个天生的缺陷，它只能对付磁盘本身的出错，不能对付非磁盘因素造成的问题。比如，Oops了，内存坏掉了，主板烧掉了，网络断掉了，电源挂掉了，机房被炸了……诸如此类，RAID完全无能为力。冗余度再高的RAID，也不能让用户恢复对系统的访问。实际情况中，软件出问题的可能性也非常大，其他硬件出问题的概率同样不小。可靠性是对用户的全面保证，不能只盯着磁盘出错来看。很多控制器架构的存储产品提供HA(High Availability，高可用性）功能，在同一套系统中有两个控制器（每个控制器有CPU内存等硬件，可以看成一台独立的计算机），当一个控制器坏掉之后，另一个控制器能够马上接管坏掉控制器的工作。同时也提供冗余的电源等部件。但是，这些硬件的冗余度一般只有2，很难再提高，同样不能应付整个机房断电等意外情况。另外的问题是，这种双控系统中，两个控制器之间的耦合度是很高的（通过内部电路和软件来提高耦合度），很容易出现一个控制器出问题，另外一个控制器也不能正常工作。
1.4 单个RAID设备的磁盘总数控制
由于单盘出错率比较高，一般也不建议用户在一个RAID设备中加入太多的磁盘。可以替代现有RAID5的一种方法是RAID50，它是把几个RAID5设备再用RAID0组合起来。每个RAID5内部能容忍一块盘出错，但是对于整个RAID50来说，可以有条件地容忍多块盘出错，在提高了可靠性的同时，也扩大了单卷容量，同时也比RAID6的性能高。不用廉价的SATA盘，选用速度更快可靠性更高的SAS或者SSD盘也是一个选择，但是高昂的成本总是让很多人望而却步，为了提升那么一点点可靠性花更多的钱，估计也只有银行等巨头才能承受得起。
可见，RAID的可靠性比起单盘系统来说，高了不少，但是无法应付在云计算环境中更高的可靠性需求。
2. 性能
任何时候，性能都是用户追求的主要目标之一。云计算也是如此，可以不是最快，但是一定得够快。RAID通过把多块磁盘组合在一起进行并发读写，显著地提升了性能。前面我们讨论了n个盘组成的RAID5，可以达到(n-1）个盘并发操作的高性能。假设每块磁盘的速度是100MB/s，则总速度可达100*(n-1)MB/s。看上去很惊人。事实上会这样吗？
2.1 理论最高带宽只是一个理想值
理论上RAID5是可以达到这样的速度的，但是条件非常苛刻，必须是完全顺序的读或者写操作，且数据传输通路上的任一部分都要能够支持如此大的带宽。实际运行的系统很难满足这两个苛刻的要求。不用说数据库操作极其随机的读写IO，就连归档备份等看似很顺序的操作也带有不少随机性，毕竟由于文件系统的存在，磁头不得不时而转到元数据区更新文件基本信息，时而转到数据区更新文件本身。如果在服务器上插入PCI-E的RAID卡，倒是可以达到很高的带宽，但是如此大的数据量带来的运算负担也会让CPU吃不消；如果不用RAID卡，接入单独的NAS或者SAN设备，内部带宽再高，也会受限于FC或者iSCSI等外部端口的速度。这些端口的速度往往只有1～2Gbps（小于256MB/s），想要进一步提高带宽，只能使用MPIO等方法让多个端口聚合使用，但这也提高了网络的复杂性。
事实上，单盘的100多MB/s的带宽已经能够满足很多应用程序的需求，同时这个值也反映出我们没有那么大的必要去追逐极限带宽，享受一个NB的数值带来的愉悦感也没有多大的意义。那为什么我们总是认为存储的速度跟不上呢？主要是因为真实应用环境中的IO都多多少少带有随机性，随机IO的速度往往比顺序IO低1～2个数量级。改用SSD能够降低随机IO和顺序IO之间巨大的速度差异，但是毕竟目前来说性价比不是很高，所以我们谈论的重点还是传统的通过磁头机械转动来访问数据的磁盘。
2.2 RAID5的写惩罚
RAID5对随机IO的处理是它的一大弱势，对于随机读写不仅仅性能会下降，而且由于它的特点会导致写性能额外的损失，这就是通常我们所说的RAID5 performance penalty。RAID5是把数据划分成一个个条带（Stripe）来处理。最理想的情况就是整个条带一起写入，也就是把IO同时发往所有的磁盘，以达到最大化的并行效果。如果是持续地连续写入，就符合整个条带一起写入的情况，该条带中的校验码能够根据用户写入的数据直接生成，和其他IO并行写入。但是如果只写一个条带中的部分数据，情形就大不一样了。由于写入的部分条带数据无法生成校验码，所以必须从磁盘上读出该条带未被写入的全部或者部分内容（具体读多少和算法有关），再重新计算该校验码。这次写入操作带来了额外的读操作，开销陡然增大很多。本来只有一次IO操作，但是实际上却产生了两次IO，这对性能的影响不可小觑。而且，为了提高吞吐量，部分系统会延迟写入的时间（比如Linux中的md模块），以便同一条带中有更多的内容能够凑齐在一起。运气好的话，这种算法可以让随机IO汇集在一起，构成一个完整的条带，一次性写入；但是更多的情况是凑不齐一个条带，仍然会导致额外的读操作，且复杂的延时对系统的性能并没有很好的促进作用，反而会打乱一些本来可以顺序提交的IO，造成性能的损失。
2.3 RAID5重建对性能的影响
从“可靠性”一章也可以看出，当出现坏盘的时候，RAID5重建数据会花比较长的时间。重建的过程由于磁盘本身不断地在读取数据计算校验码，因此势必对正常的IO产生较大的影响，也会影响性能。
2.4 RAID6和RAID10的性能
RAID6的原理本身和RAID5很类似，RAID5存在的性能问题它也具有。且它多一块校验盘，性能开销会更大。因此，为了得到比较高的性能，部分系统会倾向于选择磁盘利用率并不高的RAID10。毕竟，RAID10写入数据在任何时候都不需要进行额外的读操作，它的校验数据只是简单的复写而已，没有RAID5/6的计算过程。不过，RAID10虽然在某些时候可以提供一半坏盘的最大容错度，但是如果是同一个RAID1里面的磁盘出错，那坏掉两块盘也就可以导致系统无法使用。
单纯从读来说，RAID5的性能一点也不占劣势；但是实际的云计算应用环境肯定是又有读又有些，也很难是非常连续的IO，采用RAID5很可能会导致比RAID10更多的性能问题。RAID10是靠它那简单的冗余策略来取胜的，它也告诉我们，如果不怎么考虑空间利用率，把一组数据简单复制成几分再写入到不同磁盘，其实是一个很快的操作。
3. 成本
按照传统的观点，RAID能够提供低成本的高性能高可靠性解决方案。建一个RAID5设备，只需要多一块磁盘，最多再加块热备盘。为冗余度而多花的代价似乎只有一两块磁盘的价钱而已，这个成本是很低廉的。假设用户以每10块盘做一个RAID5，每个RAID5另备一个热备盘（实际上可以做多个RAID组共享的全局热备盘，进一步降低磁盘总数），则只需额外多购买18%（2/11）的磁盘而已，对于企业来说，这个成本算不了什么。如果用RAID10，在不加热备盘的基础上，就需要100%的额外磁盘数，因此，大多数企业还是更倾向于RAID5。
但实际上，为了稳定性和便于扩展，企业用户采用RAID一般都会用专用的网络存储设备（NAS或者SAN）。一台专业存储实际上就是一台独立的服务器，为了购置它，往往需要付出磁盘总价好几倍的价钱，这大大地增加了RAID方案的总体拥有成本。部分企业对稳定和性能更加敏感，采用了FC接入的设备，或者高转速的SAS硬盘，会进一步增加整体成本。当然，部分企业为了控制预算，直接在服务器里面接RAID卡。这样做也可以满足某些需求，但是可靠性相对来说就降低了一些，可扩展性也不是很好，RAID卡本身也并不便宜。
类似Google和Hadoop的大规模存储方案，摒弃了RAID估计一个重要的方面就是成本原因。虽然分布式的高度冗余方案会购买所需容量好几倍的磁盘，但是多买一点廉价的SATA盘已经不成问题，更重要的是，省去了专业存储硬件的高昂价格。既然再怎么做，单个节点都容易出问题，那还不如买可靠性稍微高一点点的廉价PC服务器——如此这般，成本节省不是一点两点！有人会说，这种存储方案用了数以千计的PC服务器，这些服务器再怎么便宜，总价也是相当昂贵的，所以成本并不低廉！的确，这不是穷人和小公司能够玩得起的玩意儿，但是对大公司来说，这是一个性价比超高的解决方案。尽管会添置非常多的的PC服务器，但是每台服务器除了管理存储之外，还会用来做其他计算，物尽其能，一点都不浪费。
4. 总结
传统的RAID存储在云计算时代遇到了越来越多的瓶颈，Google和Hadoop等新的架构也许更能满足云计算的需求：简单，高效，可靠，平均成本（每GB存储）低廉。不过，Hadoop这种方案必须在计算节点很多的情况下才能发挥实效，不适合中小公司自己搭建存储网络。因此，传统的RAID设备在大量领域继续具有生存空间。事实上，Hadoop的每一个节点可以利用本地的RAID来进一步提高可靠性，但是在可靠性足够的情况下，一般来说很少有人再愿意这么做了。
当公有云进一步发展，网络带宽越来越高，中小公司都不需要自己维护存储，如同购买电量一眼直接从大型云计算服务提供商购买存储容量的时候，RAID的用武之地才会进一步减少。但它也不会消亡。云计算领域它不堪重任，但是在其他领域仍可以发挥余热，比如可靠性要求不高但是又需要那么一点点的应用。 RAID本身也会逐步改进，比如RAID50在提高RAID5容量的同时也维持了对应的稳定性。也许以后我们会看到RAID的进一步完善。