一 0.99999999999999999999999999999999...
在没有冗余的情况下。一个存储系统内的磁盘数量越多，单位时间内挂掉的磁盘也就越多，这个时间段内丢掉的数据也就越多。在有冗余的情况下，这个概率还和坏掉的盘是否互为一组副本的概率相关。
另外，不同批次，不同工艺，不同技术下的磁盘故障率是不尽相同的。
磁盘修复的速度也会对可靠性产生重大的影响，磁盘修复越快，丢数据的概率自然越低。
我们经常看到一连串9来描述存储系统的可靠性（参见各大云存储），不过N个9意味着什么？到底反映了什么有意义的结果呢？作为人类应该怎么解读它呢？虽然9越多越了不起，但是15个9和16个9到底意味着什么呢？差别在哪？为什么从来没看到磁盘生命周期，磁盘修复速度对其的影响呢？可能是因为这些参数对于消费者（云上开发者）来说太过于专业，不利于商业宣传，因此隐藏在其后的计算中去了。
还有些博闻广记的人可能会知道一个有着20多年历史的MTTDL(mean time to data loss)的概念，它使用了马尔科夫链来计算。一听就不知道高到哪里去了。那么，30年或者300年的MTTDL意义又在哪呢？这个时间长度岂不是早就超过了磁盘的生命周期吗？故障率难道是稳定的吗？300年比30年比较下来似乎没有优势啊？！
一个好的存储系统可靠性模拟会是什么样子呢？
我们希望它最起码的功能是能起到不同冗余方案（在这里实际上我们比的就是不同的RS）的可靠性比较作用，这一点上似乎很好满足，只要不瞎写，都没问题。但实际情况并非如此。
其他几个要求分别是，有意义，可理解，可比较。看上去，也没什么特别的。难道原有的计算模型不能满足这些需求吗？事实就是不满足。
当然，倘若真找到一个优秀的办法模拟存储系统的可靠性，那么这种模拟肯定是要可以计算的，只是想象的话也没有任何实际意义。
二 有用的数据
一般人很难有足够的观测数据。这个工作由一些院校的研究机构或是公司做了，但是还不够，有的磁盘数量不够，有的磁盘批次和规格不统一，有的记录时间不够，或者干脆三者皆不满足。那么，我们能怎么做呢？——把各份数据和论文结论结合起来看。
枯燥的数据就不列了，而且互相之间有一些矛盾的地方。仔细对比原因，应该是实验时间上有差异造成的。造成实验时间差异的原因，一方面可能是实验环境所限，另外一方面是原本基于故障率随时间变化的期望导致时间轴长度选取的差异,还有就是一般的报告均没有考虑制造厂商和产品型号带来的可靠性差异。我个人更倾向于backblaze和google公布的数据以及CMU的一份论文（虽然其不同报告本身如果只看结论的话，会有一点点矛盾之处的。这是由于磁盘规格、批次不同，磁盘数量变化，报告的组成体不同造成的。不同的磁盘其故障率甚至相差上百倍，而且磁盘数量仍然不够，其统计数据具有一定的偶然性。但使用他们的数据的好处正在于——如果细心观察就可以发现这些数据背后反映的问题。）因为可以清晰的看到几年来，同一规格磁盘的故障率变化,还有生产环境的使用率带来的影响等(使用率和故障率的关系很有意思，并不简单简单是高压力与故障率正相关）。
而且磁盘生命周期记录这玩意在工业中可以更加的灵活。倘若，在整套系统运行的第五年，“老家伙”纷纷开始倒下。那么，我们完全可以对每块磁盘的生命做记录，在其较为稳定的时期（第三年）就开始逐步替换新盘。这样的相当于注入了新的血液，整体的生命周期被拉回到接近初始的状态。
但是有人可能会反对，这磁盘替换率人为的一提高，费用岂不是随之上升了。不过我认为这个费用上升总比数据大量丢失造成的经济和信誉损失来的小吧。
三 各种动作的模型
找模型没有什么特别的窍门，利用实际生产环境中的观测数据，带上一些直觉，然后用各种模型带上参数去比较，找到最合适的参数就可以了。但是由于数据的缺乏，以及简化模型的目的，之前的可靠性算法都非常的不靠谱。
在确立模型之前，我们首先要思考自己对于磁盘生命周期的考虑。我们是指望一块盘一直用用到死再更换还是在其开始老去的时候让它光荣下岗？
接下来是对系统生命周期的期待。我们建造一个大型系统，肯定不打算只让它跑上一年，或者1分钟。那么模型作为一种模拟，它的优化方向肯定是往较长的时间的表现上而不是对突发时间的模拟。也就是说，我们的程序要能在一个长周期中捕获极小概率的事件。而且，太短的模拟时间内，极大可能得到的丢数据的量为0，毫无意义。
另外，对系统的生命周期我们也不能指望不做大的新陈代谢，就像之前所说不建议等到死亡才开始更新。:D
与此同时，我们还需知道，所谓的系统初始状态实际上是不存在的，系统一直是动态变化的。这倒不是说模型刚开始跑的时候就要考虑是否会有故障出现。我的意思是，系统的规模是随着时间不断变化的。而且，系统中的主要介质也会发生变化。原先看似可怕的老盘的比例随着新盘的快速加入而显得逐渐渺小。对于提供云服务的公司来说，其规模增长是非常惊人的。因此，一开始的磁盘规模很小，到后期就算故障率高，修复带宽也不会吓人。那么，显而易见的是，计算的结果将是针对目前这一批磁盘的未来状态的模拟。
首先，是我们最关心的磁盘故障率模型。
大部分数据显示，infant mortality的影响并不显著。总体上可以认为磁盘稳定的老化，故障率一直在上升。（google的数据显示磁盘老化的速度比backblaze要快，这可能是由于google的数据比较老，随着磁盘技术的进步，稳定性上升的关系。这一点也可以从backblaze的报告中看到，部分厂商的磁盘的新磁盘稳定性有了很大的提高）综合来看，我们可以使用一条较缓和的韦伯分布来平衡数据，而不是直线方程或是单参数的指数分布。使整个模拟计算阶段的总故障事件与实际状况尽量吻合。
HFRS(High-Fidelity Reliability Simulator)的作者使用Elerath和Pecht在Enhanced Reliability Modeling of RAID Storage Systems中的磁盘故障率的韦伯分布的参数是一个不错的参考，我们可以对其进行修改以符合自己的情况。
说了磁盘故障，不得的提磁盘修复的。磁盘的修复时间并不是恒定的，而且实际操作与理论值差距会很大，这是因为对于服务提供商来说，业务网络故障可能需要抢占修复网络的带宽。综合以上考虑，磁盘修复我们也使用韦伯分布来模拟。
另外，不少修复方案使用的并不是直接copy disk,而是使用并行修复这一办法提高修复速度。也就是其保持的是volume mirror而不是disk mirror，这样多个磁盘可以并发参与修复过程，修复速度越快，。尽管，scope（坏盘数据分布的广度）上升，其坏掉>=冗余数的盘导致丢数据的概率也上升（这个上升概率是很方便计算的，和scope的具体数值和分布方式，磁盘数量有关），但由于单位时间（修复时间）的缩短，磁盘坏掉这个数量级的概率也大大降低，因此单位时间内丢数据的概率也降低了，集群可靠性也随之上升。
然而，考虑到整个集群中可供修复的带宽，以及随着集群的扩大同一时间段内需要修复的磁盘数量也会攀升，那么通过并行修复提高的速度就无法体现了。说的再直白一点就是并行修复打破了修复过程中单个磁盘的外部传输速度的瓶颈，但是网络瓶颈才是修复的桎梏。
另外上一篇中我们已经看到使用RS编码，repair traffic非常高，是倍数级增长，但RS的吞吐又是有限的（超过单盘外部传输速度，但不满足scope特别大的并行修复的理论值）。这使得并行修复进一步失去了效用。网络中传输的有效数据(data)甚至都达不到单盘的外部传输速度，又由于scope的扩大至使丢数据的概率上升，可靠性反倒下降了。
由于我们所考虑的是通用的，廉价的云服务解决方案，拥有特别大的带宽冗余是我们不希望看到的。所以，在我看来并行修复在理论上在一个较小集群内对于一块磁盘损坏的情况能做出非常漂亮的数据，但是实际效果可能是反作用的。
接下来，我们一起来看扇区故障模型。
关于扇区故障确实非常难找到一个合适的模型，主要原因很简单，扇区实在太多，尤其是现在盘越做越大。正因为难找，所以很多人干脆不把扇区故障记录到可靠性计算当中。然而，这就好比从外太空看地球上死了一个人什么变化也没有，但确实是死了一个啊，这是无和有的差别，还是得考虑的。只不过，集群中扇区的数量可能会是几万个地球的人口数。而且扇区故障不考虑，很多模型的可靠性模拟下来就是100%
另外极其重要的是对于极小概率事件的捕获是非常重要的。这里有个二战时期起源的方法去记录极小概率事件，叫蒙特卡洛方法。名字还真是来源于赌场的名字。
至于具体为什么是这个概率模型而不是那个，可以随后查阅我推荐的论文。另外在以后的日子里，我会好好谈一谈概率模型。
四 丢了多少Bytes？
这个工作实际上已经有人做了。他们(加州大学圣克鲁兹分校的Storage Systems Research Center）用python（python2)写了关于存储可靠性的程序，名字叫做HFRS.
其原理是利用蒙特卡洛算法去捕获极小概率事件。HFRS非常的强大，可以计算多种erasure code集群的可靠性。最后，得到的最重要的结果不是一连串9或者几百年这样的结果，而是得到一个文件丢失总大小的数字。这是个非常直观，有效率的结果。满足我们对于可靠性分析的可计算性，丰富意义，可理解，可比较的所有要求。
在这里，我们重点要提的是一些参数上的选择。
比如我刚才提到的磁盘故障率的参数，我不建议使用其默认参数。关于磁盘修复的参数，可根据自己的实际情况调整，默认值对比生成环境的情况有些偏小，可以不用变更。另外关于扇区故障的问题，需要调整的是单磁盘扇区总量以及扇区大小（在代码中）
还有一个重要的参数是关于模拟的时长。我的建议是控制在3-5年。首先，磁盘生命周期有限，模拟很长的时间没有意义，我们不知道到底损坏率是多少，很有可能是飞速上升的。因此，模型将不再准确。另外，时间太短也没有意义，可能捕获不到任何错误，另外模型保持的也只是总体上的准确，在较短时间内可能失去其准确性。
网友评论