可视化存储智能解决方案之一“大话Raid2.0”

据说IT屌丝都是夜猫子，所以瓜哥选择在这个时候发个帖：）

几个月之前，冬瓜哥给大家发了一份免费大餐，叫做《可视化存储智能——思路、设计与展现》，50页pdf文件，可谓是瓜哥为大家精心准备的一份盛大宴席。这个解决方案，是瓜哥当年从零开始一步一步雕刻而成，虽然只形成了图纸，最终也只有其中个把名词得到了应用之外，可惜没有落到实处，因为在之前那个平台瓜哥寻觅了许久，找不到能够与瓜哥一样有匠心而且有人力的人来一起实现之，瓜哥黯然离去，打算从此不问江湖事，但是人在江湖身不由己，瓜哥还不能做到了无牵挂，所以，在这里瓜哥打算把这份大餐，分章节发送到微信这种快餐信息工具上，以飨大家。

这次打算分享一下Raid2.0这个东西，“可视化存储智能”必须建立在一个底层数据布局充分灵活的基础上，对于传统存储来讲，Raid2.0无疑是个好胚子。所以，本节先说说Raid2.0，但是瓜哥这套解决方案，和Raid2.0确没有直接关系，有人可能认为“Raid2.0多么高大上啊”，我被忽悠了好久，感觉他们忽悠的时候，那逼格，帅呆了！哈哈，冬瓜哥要说，那是由于你自身的逼格不够，那就只能被忽悠。冬瓜哥对Raid2.0没什么感觉，因为冬瓜哥属于曾经沧海难为水，一个Raid2.0，不足以撼动冬瓜哥那已经对忽悠免疫的神经。Raid2.0只是冬瓜哥要造的这台超级跑车的底盘。

1.1 Raid1.0 和Raid1.5

在机械盘时代，影响最终IO性能的根本因素无非就是两个，顶端源头一个，也就是应用的IO调用方式和IO属性；底端源头一个，那就是数据最终是以什么形式、形态和形状存放在多少机械盘上的。应用如何IO调用完全不是存储系统可以控制的事情，所以从这个源头来解决性能问题对于存储系统来讲是无法做什么工作的。但是数据如何组织、排布，绝对是存储系统重中之重的工作。

这一点从Raid诞生开始就一直在不断的演化当中。举个最简单的例子，从Raid3到Raid4再到Raid5，Raid3当时设计的时候致力于单线程大块连续地址IO吞吐量最大化，为了实现这个目的，Raid3的条带非常窄，窄到每次上层下发的IO目标地址基本上都落在了所有盘上，这样几乎每个IO都会让多个盘并行读写来服务于这个IO，而其他IO就必须等待，所以我们说Raid3阵列场景下，上层的IO之间是不能并发的，但是单个IO是可以多盘为其并发的。所以，如果系统内只有一个线程（或者说用户、程序、业务），而且这个线程是大块连续地址IO追求吞吐量的业务，那么Raid3非常合适。但是大部分业务其实不是这样，而是追求上层的IO能够充分的到并行执行，比如多线程、多用户发出的IO能够并发的被响应，此时就需要增大条带到一个合适的值，让一个IO目标地址范围不至于牵动Raid组中所有盘为其服务，这样就有一定几率让一组盘同时响应多个IO，而且盘数越多，并发几率就越大。Raid4相当于条带可调的Raid3，但是Raid4独立校验盘的存在不但让其成为高故障率的热点盘，而且也制约了本可以并发的IO，因为伴随着每个IO的执行，校验盘上对应条带的教研块都需要被更新，而由于所有校验块只存放在这块盘上，所以上层的IO只能一个一个的顺着执行，不能并发。Raid5则通过把校验块打散在Raid组中所有磁盘从而实现了并发IO。大部分存储厂商提供针对条带宽度的设置。比如从32KB到128KB。假设一个IO请求读16KB，在一个8块盘做的Raid5组里，如果条带为32KB，则每块盘上的Segment为4KB，这个IO起码要占用4块盘，假设并发几率为100%，那么这个Raid组能并发两个16KB的IO，并发8个4KB的IO；如果将条带宽度调节为128KB，则在100%并发几率的条件下可并发8个小于等于16KB的IO。

讲到这里，我们可以看到单单是调节条带深度，以及优化校验块的布局，就可以得到迥异的性能表现。但是再怎么折腾，IO性能始终受限在Raid组那少的可怜的几块或者十几块盘上。为什么是几块或者十几块？难道不能把100块盘做成一个大Raid5组，然后把所有逻辑卷创建在它上面来增加每个逻辑卷的性能么？你不会选择这么做的，当一旦有一块坏盘，系统需要重构的时候，你会后悔当时的决定，因为你会发现此时整个系统性能大幅降低，哪个逻辑卷也别想好过，因为此时99块盘都在全速读出数据，系统计算XOR校验块，然后把校验块写入到热备盘中。当然，你可以控制降速重构，来缓解在线业务的IO性能，但是付出的代价就是增加了重构时间，重构周期内如果有盘再坏，那么全部数据荡然无存。所以，必须缩小故障影响域，所以一个Raid组最好是几块或者十几块盘。这比较尴尬，所以人们想出了解决办法，那就是把多个小Raid5/6组拼接成大Raid0，也就是Raid50/60，然后将逻辑卷分布在其上。当然，目前的存储厂商黔驴技穷，再也弄出什么新花样，所以它们习惯把这个大Raid50/60组成为“Pool”也就是池，从而迷惑一部分人，认为存储又在革新了，存储依然生命力旺盛。

那我在这里也不放顺水推舟忽悠一下，如果把传统的Raid组叫做Raid1.0，把Raid50/60叫做Raid1.5。我们其实在这里面可以体会出一种轮回式上升的规律，早期盘数较少，主要靠条带宽度来调节不同场景的性能；后来人们想通了，为何不用Raid50呢？把数据直接分布到几百块盘中，岂不快哉？上层的并发线程小块随机IO在底层可以实现大规模并发，而上层单线程的大块连续IO在底层则可以实现夸张的数百块磁盘并行读写服务于一个IO的效果，达到超高吞吐量。此时，人们昏了头，没人再去考虑另一个可怕的问题。

至这些文字落笔时仍没有人考虑这个问题，至少从厂商的产品动向里没有看出。究其原因，可能是因为另一轮底层的演变，那就是固态介质。底层的车轮是不断的提速的，上层的形态是轮回往复的，但有时候上层可能直接跨越式前进，跨掉了其中应该有的一个形态，这个形态或者转瞬即逝，亦或者根本没出现过，但是总会有人产生火花，即便这火花是那么微弱。

这个可怕问题其实被一个更可怕的问题盖过了，这个更可怕的问题就是重构时间过长。一块4TB的SATA盘，在重构的时候就算全速写入，其转速决定了其吞吐量极限也基本在80MB/s左右，可以算一下，需要58小时，实际中为了保证在线业务的性能，一般会限制在中速重构，也就是40MB/s左右，此时需要116小时，也就是5天五夜，一周时间，我敢打赌没有哪个系统管理员能在这一周内睡好觉。

1.2 Raid5EE 和Raid2.0

20 年前有人发明过一种叫做Raid5EE的技术，其目的有两个，第一个目的是把平时闲着没事干的热备盘用起来，第二个目的就是为了加速重构。见图1-2-1：

图1-2-1 Raid5EE

很显然，如果把图中用“H（hot spare）”表示的热备盘的空间也像校验盘一样，打散到所有盘上去的话，就会变成图右侧所示的布局，每个P块都跟着一个H块。这样整个Raid组能比原来多一块磁盘干活了。另外，由于H空间也打散了，当有一块盘损坏时，重构的速度可以被加快，因为此时可以多盘并发写入了。