从上文分布式存储系统可靠性-系统估算示例 中详细分析了系统可靠性量化的估算手段，并且给出了示例代码，代码的主要输入参数为如下所示。

1
2
3
4
5
6
LoseRate(S, N, RepNum, T, AFR)
N：系统中磁盘的数量（包括磁盘的容量信息）
S：系统Copyset的数量
RepNum：存储的备份数量
T：坏盘情况下的恢复时间
AFR：磁盘的年度故障率

这里基本可以揭示，在一个固定大小为N的分布式存储系统中，影响存储可靠性的因素主要为S、RepNum、T、AFR。接下来我们分别从这几个方面来分析，在分布式系统设计和运维过程中的一注意点。

1 年故障率（AFR）

排除人为因素和系统Bug，丢数据的核心原因是磁盘发生不可逆故障造成的。当前磁盘的过保时间大概是4年，4年后磁盘的故障率会急剧上升，同样从成本上考虑，随着磁盘技术的不断提升，存储密度每4年可以有很大得上升，替换使用新的磁盘更佳具备成本优势。如继续让老的磁盘在线上提供服务，系统丢失数据的风险会变大。根据google的生产环境的数据显示，磁盘的AFR数据如下。

针对这一特性，我们潜在能够采取的措施包括

1 及时替换老的或者故障磁盘

在系统设计层面上需要能够记录每一块硬盘的品牌、系列、上线日期等，对于经常出现坏块和频繁出错的磁盘需要尽快进行，并且对于快要使用年限的磁盘进行替换下线。

2 根据smart信息预测换盘

采集磁盘的smart的信息，分析smart信息，对磁盘的换盘行为做预测工作。

2 副本数(RepNum)

显然副本数是影响数据可靠性的关键因素。这里我们通过量化的方式来衡量副本数对可靠性的影响。

使用的系统示例分布式存储系统可靠性-系统估算示例 。考虑副本数 ∈[3，6] 情况下的可用性，如下所示。

RepNum 可靠性(年故障率)
3 1.14*10E-6
4 2.78*10E-8
5 3.18*10E-10
6 3.32*10E-12
7 2.33*10E-14

从上表可以看出，增加副本可以使得可靠性得到数量级上的提升，但是成本和写入性能上会给系统带来一定的负担。产品可以从数据的重要性，系统本身的workload等方面在在各方面权衡选择系统的副本数。

3 Copyset数目(S)

单从copyset 这一因素考虑，我们基本可以确定CopySet越多丢数据概率会愈大，这我们可以从分布式存储系统可靠性-如何估算 文中 第2节“数据丢失与copyset（复制组）” 看出。

以下，我们同样以Copyset 与 丢失数据概率具体看CopySet对可靠性的影响，使用系统示例同样为分布式存储系统可靠性-系统估算示例中的示例，随机情况下CopySet数量为S

CopySetsNum 可靠性(年故障率)
S 1.14*10E-6
S/2 5.74*10E-7
S/4 2.87*10E-7
S/8 1.43*10E-7
S/16 7.17*10E-8

从上表我们可以看到，减小CopySet数量对于可靠性的影响基本是线性。

那么如何规划系统中CopySet的数量。在随机策略情况下，CopySet的数量越多，说明一个磁盘上的数据打得越散，那么一块磁盘上对应的数据的副本分布在更多的磁盘上，可以获得更高的恢复带宽，坏盘的恢复时间越短，从而进一步降低丢失数据的风险。但是在现实系统中，为了保障数据对外服务的带宽能力。一般来说用于系统恢复的带宽不会超过20%，所以T级别盘能够在1个小时内恢复已经是非常不错的。

比如一块8T盘1小时恢复所需要的带宽 8*1024/3600 ~= 2.27 GB，假设每块磁盘能够提供的恢复带宽为10MB，那么只需要 2.27*1024 /20 ~= 106 块盘参与即可，也就是说一块磁盘的数据只需要打散在106块磁盘中即可，不用过于分散。在随机放置副本情况下，我们可以控制分片大小来达到减小copyset的目的 分片大小 ～= 8*1024/106 = 77GB。 这种清下，可靠性可以提高到1.49 10E-7 。 后续我们会介绍更佳有效的控制系统copyset的方法。

4 修复时间(T)

单从修复时间考虑，修复时间越快，丢失概率越小。因为同时发生坏盘的概率随着时间的缩短能够得到非常有效的降低。这从分布式存储系统可靠性-如何估算 中介绍坏盘服从的柏松分布中可以看到。

如下为N=7200， AFR=0.04情况下；在单位时间∈[1,24] 内坏 ∈(3，6)块盘的概率；从图表中我们可以看到，从20小时变为2小时，时间段内损坏N块盘(3~6)的概率都能得到3个数量级以上的提升。

5 总结

总结来说，为了提高存储系统数据可靠性，首先在系统允许的成本范围内选择合适的副本数，再次在系统设计中我们首先优先考虑加快数据恢复时间，在此基础上减小系统的copyset数量。使得在既定的成本下达到尽可能高的可靠性。

This article used CC-BY-SA-4.0 license, please follow it.