千亿级数据防丢指南：存储系统的可靠性保障实践( 二 ) _数据

1）原因

硬盘故障：最常见最重要的，驱动器、磁头、温度、机械臂故障
主机故障：服务器各部件故障导致服务器无法启动
机柜故障：由于电源、温度、网络等原因导致整机柜服务器停机
机房故障：整个机房由于自然灾害或供电原因瘫痪
AZ故障：同一地理区域独立电力和网络的机房故障
Region故障：不同地理区域的一个Region故障

2）硬件故障的解决方案

数据冗余技术【RAID5/6、副本、纠删码】
多AZ数据冗余部署【vivo 3 AZ 部署】
跨区域复制功能【功能具备，vivo还没多地域机房】
故障预测+故障发现+故障修复

如果我们只按照传统方式，增加K，减少M，修复带宽就会非常高。并且，多AZ之间的修复带宽本身成本较高，所以给可靠性带来了很大压力。因此，我们设计了一个低冗余度、支持多AZ部署、且修复带宽较少的纠删码优化方案。

文章插图
上方右图来自2021年亚马逊AWS S3关于可靠性保障的演讲，这幅图提供了两个重要的信息。

第一个信息：11个9是通过可靠性模型量化得到的，它与磁盘的故障率、故障发现的时间和消费时长是强相关的。
第二个信息：可靠性评估模型，用于指导线上环境的修复策略，以及指导跨AZ纠删码技术存储系统的设计。

三、建模：存储可靠性量化模型
1.11个9的由来
11个9是亚马逊在2006年提出的可靠性标准，所有云存储提供商都像军备竞赛一样，声称自己能提供多少个9，但行业内几乎没有任何一家云厂商能提供权威的量化模型。
这11个9如何量化？

文章插图
亚马逊的官方文档提供了两种定义：

第一个定义是，存储一千万个对象预期平均每1万年发生一个对象丢失。这个定义很好理解，但它实际上并不好量化；
第二个定义是，平均每年对象的丢失率预计为0.000000001% 。这个定义具体到每年的对象丢失率，进入到统计学概率的层面，为量化提供可能。

回顾那张AWS演讲里的图，它引入了两个比较重要的参考指标：硬件的平均故障时间、故障的平均修复时长，对应到年平均指标的层面上，就是年平均故障率和年平均修复率。
2.可靠性模型影响因素
接下来，介绍建立模型的具体影响因素。如下图所示，如果第一个磁盘爆炸，后面磁盘的数据需要对它进行修复，这个过程可能涉及到修复带宽，所以修复带宽的大小一定会对可靠性产生影响。这个磁盘本身的数据量、系统节点数目也影响了修复时间，这三个指标实际上影响了修复率的值。

文章插图
副本的数量、磁盘故障率对可靠性也是有影响的，这比较好理解，如何理解数据分布系数对可靠性的影响？
如上图左下角所示，备份有两种数据分布方式。在第一种备份的数据分布状况下，如果第一个磁盘挂了，只能依靠第二个磁盘进行修复，即只有一个盘进行修复，所以速度较慢。
第二种备份将数据分块打散，其他三个磁盘都存储一部分数据。第一个磁盘挂掉后，就有多个磁盘并行修复，速度会更快。
这是不是说明第二种备份方式就是最好的？也不一定。因为第一种备份虽然修复速度慢，但正好修复了挂掉的数据。用第二种备份方式，修复的数据可能不是挂掉的数据，实际存在数据丢失情况，因此，数据分布系数对可靠性也有影响。
3.MTTDL可靠性模型

文章插图
以下介绍几个重要的存储可靠性量化模型。第一个是MTTDL（平均系统数据丢失时间），它和磁盘的MTTF的区别在于， MTTDL用于衡量系统平均数据丢失时间。
MTTDL模型在1994年被提出，1.0版本基于Markov链推导而来，上图列出了一个简化版的计算公式。相对于1.0版本，最近几年出现的MTTDL的2.0版本，引入了刚才讲到的数据分布系数。
MTTDL有几个缺点：第一个缺点是，它基于Markov链的方式；第二个缺点是，基于当前整个系统的故障平均时间，它是服从指数分布的。
另外，前期的MTTDL模型没有考虑扇区错误，所以近期的MTTDL优化版本屏蔽了Markov链的劣势，不使用这种方式建模；将指数分布优化成，故障率可以动态调整的Weibull分布；考虑独立扇区、相关性扇区的错误；考虑修复时长等NORMAL指标。