可以在SSD上建传统RAID吗? 当被问及"在SSD上能否建传统RAID"这个问题的时候，大家的第一反应应该是"可以建，但是需要Trim命令的支持"。在网上也可以看到很多人拿SSD来建RAID，但基本上都会配置成RAID0或者RAID1。很少有人会去建RAID5，这是为什么呢？
答案很简单，在SSD基础上如果配置类似于RAID5这样的Parity-RAID，那么SSD的整体性能不能很好的发挥出来，更为重要的是Parity-RAID会影响SSD的寿命。一句话，Traditional RAID kills SSD。所以，传统RAID不能直接配置到SSD上，不仅仅是因为Trim命令的支持问题。
在分析传统RAID在SSD上的问题之前，首先看一下RAID能够给SSD整体带来什么价值？Tom's Hardware在SSD的基础上配置了一个RAID0，并且对比了RAID0和单块SSD的性能。从下图可以看出，当两块SSD被配置成RAID0之后，无论是顺序读或者写，性能基本上可以做到翻倍。所以，配置成RAID0之后，可以提升系统的整体吞吐量。RAID0模式下的顺序读写性能对比如下所示：
第二个比较关心的是随机读写能力。SSD的一大优势在于随机读写能力强，具有很高的IOPS，因此当配置成RAID之后，是否可以将IOPS的能力翻倍呢？答案是不一定的，当队列深度很小的时候，RAID0模式下的随机读写能力和单盘的性能没有差距。当队列深度为1时，RAID0模式下的随机读写性能对比如下：
只有当队列深度达到一定程度之后，RAID0的随机读写能力才能有所提升。当queue_depth达到64时，随机读写性能如下所示，基本上可以达到单盘性能的两倍：
第三个比较关心的问题是延迟。在数据库等应用中，特别在意IO延迟指标。组建RAID之后是否能够降低延迟指标呢？从原理上来讲，RAID只能延长IO延迟，并不能降低IO延迟。Tom's Hardware的测试结果如下所示：
从上图可以看出，引入RAID0之后，延迟时间增加了。所以，总体来讲，RAID可以提升系统的整体吞吐量；在Queue Depth很大的情况下，提升系统的随机IO能力；对延迟没有改善，只能增加延迟；如果配置成Parity-RAID的方式，还可以提升数据的可靠性。
在很多应用中，需要很强的IO吞吐量、IOPS、数据可靠性以及大容量，那么此时就需要RAID来支持了。但是，前面提到传统Parity-RAID在SSD介质上不能很好的工作，只能加速SSD的磨损。传统RAID主要存在的问题如下：
1、RAID的partial-stripe写问题。在RAID5之类的Parity-RAID中，一旦发生Partial-stripe写，那么首先需要将条带中没有被更新的数据读出来，然后和新写入的数据进行合并，最后计算校验值，将新更新的数据和校验值一同写入磁盘。整个Partial-stripe写的过程就是一次"读-修改-写"。从性能的角度来看，partial-stripe写过程严重影响了性能，增加了IO延迟。更为重要的是partial-stripe写会频繁的更新parity数据。由于SSD采用的是out-of-place的数据更新方式，所以这种频繁parity数据更新会导致SSD写放大系数增大，影响SSD的使用寿命。
2、数据重构问题。传统RAID的数据重构是针对盘的。也就是说当RAID中一块盘出现故障时，RAID会将该盘从RAID组中剔除，并且找一个空闲Spare盘进行数据重构。盘级数据重构会从头至尾对SSD进行数据重构，即Spare SSD会被从头至尾写一遍。在SSD中采用FTL进行page/block映射，如果SSD中的所有page页都被耗尽，那么SSD会被迫启动Garbage Collection，使得SSD性能达到最差。
3、数据同步问题。该问题和数据重构问题类似。
4、SSD盘同时发生故障问题。Parity-RAID将条带中的数据均匀分布到所有磁盘上，使得所有磁盘上的IO均等。对于SSD盘而言，其寿命基本是相同的。因此，在RAID这种使用模式下，SSD在短时间内同时发生故障的概率是很高的。
SSD盘和磁盘相比，底层技术是完全不同的。传统RAID不能很好的配合SSD盘，使得整体性能和SSD使用寿命都会受到严重影响。因此，在SSD上建RAID不是件那么容易的事情。
本文出自 "存储之道" 博客，请务必保留此出处http://alanwu.blog.51cto.com/3652632/1430288
【闲聊产品】之五：谁来背黑锅？ 
记得有部电影里面讲过，能力越大，责任就越大，其实这句话在一定程度上也可以反过来说，你承担的责任越大，那么你的能力也有可能随之变大，至少你会有增强自身能力的机会，那么为什么会有很多人不愿意去承担责任呢？原因很简单，因为承担责任就有可能背黑锅。
其实人性中始终会有自我保护的意识，比如小时候你和小伙伴玩，推推攘攘的把花瓶打碎了，这时候如果有家长问起，很多小孩会条件反射的不想承认是自己干的，但是由于小伙伴在场又不好说是小伙伴干的，所以就保持沉默，但是如果这时候有个小孩站出来主动承认是自己干的，很容易就赢其他小朋友的尊重，甚至赢得家长的尊重，自然而然在后面的玩耍中这个小孩就是大哥了，所以在人性中我们又会敬佩那些敢抗责任的人。
反之，如果在打碎花瓶之后，两个小朋友相互推卸责任，那么即便以后还会相互玩耍，但必然也会心存芥蒂。江湖大哥是怎么成长起来的？肯定是打群架时冲在最前面的那位。
扯远了，说回和产品相关的话题，在完成一个产品的过程中，产品经理必然会和各种项目组的各个角色打交道，由于产品经理其实在行政上没有直接的权利，更多依靠的是角色职能和在项目推进阶段建立的权威性，那么当产品出了问题的时候，如果产品经理把责任一股脑推给其他人，那么造成的结果必然导致项目团队的人心涣散和其他成员对你的不信任，后面再要推动产品朝前走就困难很多了，干事的时候别人像老黄牛，担责任的时候你跑得比谁都快，别人凭什么要跟着你干？所以该怎么做我想你懂的。
同时我发现在很多时候团队间邮件吵架的一个很大原因就是谁来背黑锅的问题，问题在任何公司都会出现，但是一旦出现了责任的相互指责，事情往往就会很难收场，所以在必要的时刻勇于背黑锅也算是一种人格魅力，尤其是男士，当团队的一群人都站出来承担责任的时候，问题可能就不是问题了，整个团队的气场也会更加团结。
最后一句忠告，在有怒气的时候千万不要发邮件、发微博和打电话，自己找个地方待着，冷静后在去平和的解决问题，往往事情会好办很多。
=====
我的微博：@最牛傻蛋
 |  |
没有评论:
发表评论