SRE保障数据可靠性的四大武器

740次阅读  |  发布于2年以前

1 背景

数据可靠性保障除了数据备份大家还可以想到什么，提升副本数？提升硬件能力？ 如果有个前提是不能增加成本，不能增加机器，我们还能做什么。

今天来介绍四大武器，数据校验、数据备份、数据流动、数据磁盘故障预测。

1.1 数据安全和数据可靠性的关系

这里我用两个图解释清楚二者之间的关系，一个从空间维度，一个从时间维度

空间维度：整体就是数据安全部分，而红色这块就是数据可靠性部分

任何事情都是有两面性的，包括数据安全也是是有两面性的，风险不仅仅是企业带给用户的，同样也用户带给企业的，比如著名的快播就是用户带给了企业非常大的风险，而企业没有及时的发现和处理。所以安全是一把双刃剑，保护好自己，保护好别人。

时间维度：例如一个网盘文件的生命周期是这样的，数据可靠性呢就是处在用户实际存储过程中需要保障的事情也就是红色部分

用户登录：登录的时候会面临账号被盗的风险，例如非常著名的某邮箱公司的账号泄漏导致无数人的账号泄漏，所以现在的登录增加了各种验证机制比如绑定手机、人脸验证等等

文件传输：用户在上传和下载的时候很多时候会经过cdn，一般情况下经过cdn的文件都需要有加密，如果没有加密的话cdn这里看到的就是原始的文件很容易被劫持

内部交互：比如从接入层到存储层的过程，这个时候是也是容易存在密码泄漏的，如果用户的日志、用户的下载链接也是非常容易被人看到的。需要重点做好内外传输的加密，比如日志加密

实际存储：最终文件落盘后需要面临的最大的挑战就是硬件的损坏，如果用户文件落盘之后长时间不读这个文件是很难发现这个文件的丢失情况的。

后期运维：人员的误操作带来的挑战也是很大的，比如常见的删库跑路事件，一旦这个风险无法及时封堵那么后患无穷

总结：可以看到从空间到时间是相互对应的关系，数据安全是一个非常宽的概念，而数据可靠性/数据持久性其实是一个比较窄的概念，重点在硬件的损坏、人员的误操作带来的风险

1.2 数据可靠性的意义是什么

数据可靠性对于存储产品将会是致命的

硬件损坏的case：

2018年8月腾讯云的客户北京清博数控科技有限公司所属“前沿数控”平台一块操作系统云盘发生故障，导致文件系统元数据损坏。

腾讯方面提出了总金额136,469元的“赔偿+补偿”解决方案，前沿数控则索赔11,016,000元，被腾讯认为过高，双方未达成一致。

现在，腾讯云发布了一份关于客户“前沿数控”数据完整性受损的技术复盘，对客户业务所受影响表示诚挚歉意的同时，详细解释了此次故障发生的根源，以及将采取的措施。

腾讯云经过复盘发现，故障缘起于因磁盘静默错误导致的单副本数据错误，再加上数据迁移过程中的两次不规范的操作，导致云盘的三副本安全机制失效，并最终导致客户数据完整性受损。

误操作的case：微盟删库跑路

本次故障及事件简要回顾

事件影响

意义是不言而喻的，致命的

1. 3 什么是数据可靠性如何定义和衡量

重点来了！！！ 数据可靠性衡量两个方式：简单的和复杂的

简单的：1-(丢失数据量/ 总的数据量）这个是不是非常简单，但这个是事后的衡量，偶然的因素也很大

复杂的：这是一个非常非常经典的公式，这里免费开放，这个公式意义再也通过硬件故障率和恢复时间可以衡量目前的可靠性的程度

这里解释一下，N代表副本数，F代表故障率，比如磁盘故障率，人工故障率等等，T代表恢复时间，i代表故障类型。

根据如上公式，可以包括四个方面

1.4 如何提升数据可靠性系统解决方案

灾难预防：人员和平台的建设，如果搞不定这个那么将会是致命的

副本数提升：常见做法是数据备份，这个实现成本是最低的，也是最有效的，常见的热备、温备、冷备

故障率降低：

后续在系列文章中跟大家分享这些技术

2 防线一：磁盘故障预测

磁盘故障预测帮助最大的有状态的服务，也就是存储服务，对于数据安全有着非常重要的意义。如下图说明一下磁盘故障预测与数据可靠性关系

如下图，如果在第一时刻，分片A有两个副本出现故障，分片B有三个分片没有故障但是有隐患，如果没有磁盘故障预测的话，我们只会修复分片A的两个副本，在第二时刻，分片A完全修复，而分片B已经故障。这个时候分配B就会出现数据丢失

第二个图，如果有磁盘故障预测的话，在第一时刻就会同时对分片A和分片B发起修复，在第二时刻完成修复，不会导致故障发生

磁盘故障预测与数据修复联动。整体分为三个部分

整体来说分为三个阶段

数据获取：这里是指获取需要磁盘故障异常的信息。业界采用的做法是磁盘smart信息。但是这里建议单纯靠smart信息可能无法体现业务的表现。

举个例子比如这个时候磁盘预测正常，但是业务的读写延迟已经非常大了，这个时候的磁盘就可以判断为故障。

其次可以采用厂商信息，最后可以结合业务表现数据。业界常见的数据都是以smart信息为主，辅助其他的数据信息。比如业务信息（读写延迟等等）

数据探索：

难点一：就是型号的干扰。建议：先按照单一的型号的训练。

难点二：维度爆炸，smart信息就有几百个维度，再加上业务信息，其他信息等等。建议：先不考虑多个维组合的情况，就考虑单个维度，判断基尼系数。在故障磁盘和正常磁盘里面看他的基尼系数，把干扰的维度都去掉。先找到一个最小集。如果维度还很大需要继续降级维度，建议降维到20个以内。 如果训练几百个维度的话会非常消耗资源，而且容易产生过拟合的情况。常见的机器学习降维都可以。比如PCA，LDA等等

数据规范化 ，这里就不详细说了，

数据分类：数据分类需要考虑以下指标。分类全正，全负。正+负对比正+负。考虑一个二分问题，即将实例分成正类（positive）或负类（negative）。对一个二分问题来说，会出现四种情况。如果一个实例是正类并且也被 预测成正类，即为真正类（True positive）,如果实例是负类被预测成正类，称之为假正类（False positive）。相应地，如果实例是负类被预测成负类，称之为真负类（True negative）,正类被预测成负类则为假负类（false negative）。

数据预测：其实这里采集的数据大部分都是已经发生故障磁盘的数据，常见的算法有LR，随机森林，决策树等等。业界还有很多深度学习的算法。根据我的经验，随机森林等机器学习算法就可以满足。

BP神经网络 Proactive Drive Failure Prediction for Large ScaleStorage
决策树 面向磁盘故障预测的机器学习方法比较_董勇
递归神经网络 基于深度学习的硬盘故障预测技术研究
随机森林 基于随机森林的硬盘故障预测算法的研究

线上验证：最后一步就是上线

整体的模型如上，master来回收结果并进行离线训练，把训练好的模型部署到agent，进行实时检测。

同时把训练结果进行标注，进行离线训练，把训练好的模型继续部署到agent上

3 防线二：大象快跑—数据流动

3.1 先考虑如何几个问题

1为什么要搬迁

2 风险点在哪里

3 如何高效完成

3.2 机房搬迁—搬迁思路

为什么要搬迁和流动呢，

原因我总结了一下一共有三个层面，

第一是数据可靠性，当老机房因为故障率升高导致数据可靠性无法保障业务的需要的时候这个时候时候就必须进行大规模的机器替换了。根据磁盘故障的浴盆曲线，磁盘故障率到了后期会急剧的上升。

第二是当新机房的成本有明显的优势的时候，数据的搬迁和流动可以是节省一大笔钱的时候就可以尝试把数据搬迁到新的机房了。

第三个原因和战略层面，我们不能被一个机房或者一个云厂商卡死，如果没有数据流动的能力，一旦这个云厂商出现什么问题，就非常被动。

综上所述，数据流动的能力是一个非常关键的能力。

搬到哪里

关键点是四个

第一个是成本，成本往往是最容易启动和考量的一个因素。首选肯定是哪里便宜往哪里搬迁。

第二个是稳定，这个机房或者云厂商一定是稳定的，具备灾备能力的，稳定性是必须保障的

第三个是延迟和带宽，跨机房通信往往需要大量的延迟和通信需要得到保障。

第四个是安全，需要考量对内的安全，法律安全，GR风险等等这个也是需要考虑。 比如在海外选择云厂商得考虑一下来自各个国家的GR风险。

搬迁之前

搬迁之前，一定要做好数据的备份，或者元数据的备份。另一个事情就是无效数据的回收，要不把无效数据再做一轮搬迁，就会是非常浪费资源的。

3.3 搬迁的难点分析

目标：如何快速、可靠性、稳定地进行数据搬迁。

解决方案

搬迁之前 搬迁过程 搬迁之后
数据可靠 完整性校验 可靠传输 完整性和一致性校验
服务稳定 资源预留 实时监控 实时调整 流量的重新分配
搬迁快速 任务均匀 长尾任务 空闲机器 无

快速：主要是解决两个问题，慢节点的问题和吞吐的问题

慢节点的问题如何解决，监控和强制干预，如果发现几个节点是慢节点，就主动发现，并强制干预，把任务迁移到别的节点去。

吞吐的问题如何解决：抽象一下就是如下，我们要从以下箱子里面搬迁球出来，把球尽量地平均。球最多箱子球尽量轻，球最少的箱子尽量多。因为多个分片会集中在一台机器上，尽量让分片平均在各个机房来提高吞吐。具体算法：每次选择实际容量最小的，如果实际相同选择最大容量最小的

可靠：这里需要联合数据校验，但同时会面临一个问题就是数据校验会引入额外的资源和时间消耗（数据校验往往会占据35%的搬迁时间）如何解决这里采用的地候流水线的方式，一般搬迁一遍校验，校验失败的就增加一个搬迁任务，把任务进行到第二轮，这样当一轮都完成后，按照经验基本可以完成99%，然后依次多重复几轮就可以完成。

数据校验可以参考[数据可靠性保障核心之数据校验]

稳定：在搬迁过程中如何保障服务的稳定

主要是做三方面的事情，

搬迁之前需要做资源预估和整体的评估看可以提供多少资源出来为搬迁使用。

搬迁过程中流速要实时的控制，根据线上的稳定性指标和整体的吞吐剩余来动态的调整搬迁的速度，不能因为搬迁来影响线上。

搬迁之后要对新的集群在一轮整体的流量和容量的调整，让新的机房的流量和容量尽量的均衡。

3.4 总结

数据流动能力是一个存储系统一个非常重要的能力，有了强悍的数据流动能力可以给后续的成本优化，机房规范提供一个更加广阔的空间。我之前负责运维的一个产品有上EP的存储量，搬迁能力需要每天几P的量，同时需要保障各种因数。最终完成后对整体产品的数据可靠性提供了好几个量级。

4 数据校验

4.1 为什么要有数据校验

腾讯云的故障 ：当天上午11:57，腾讯云运维人员收到仓库I空间使用率过高告警，准备发起搬迁扩容。14:05，运维人员从仓库I选择了一批云盘搬迁至新仓库II，为了加速搬迁，手动关闭了迁移过程中的数据校验。20:27，搬迁完成之后，运维人员将客户的云盘访问切至仓库II，同时为了释放空间，对仓库I中的源数据发起了回收操作。20:30，监控发现仓库II部分云盘出现IO异常。腾讯表示，数据搬迁过程中的违规操作主要如下两点：

第一是正常数据搬迁流程默认开启数据校验，开启之后可以有效发现并规避源端数据异常，保障搬迁数据正确性，但是运维人员为了加速完成搬迁任务，违规关闭了数据校验；

第二是正常数据搬迁完成之后，源仓库数据应保留24小时，用于搬迁异常情况下的数据恢复，但是运维人员为了尽快降低仓库使用率，违规对源仓库进行了数据回收。

其中都有一个共性数据校验被关闭了或者没有，没有经过校验的数据都是不可靠的

总结一下：很多case是无法通过监控来及时发现的，只能依赖数据校验来完成校验目的是解决系统层面无法自动发现的问题通过系统本身来发现，比如副本缺失。无法通过存储系统本身来发现例如下面场景

4.2 数据校验应该考虑点

数据校验重点要解决两个问题，第一实时性；第二完整性

这是两个互斥的动作我们如何保障实时性和完整性，如果所有的数据都校验一遍那么实时性肯定得不到保障，如果我们非要保障实时性，那么完整性就无法保障。实时性的关键是保证实时性的关键是抽样，简单。完整性的关键全量、聚合、互证

如何保证实时

实时的目的是为了发现新出现的问题，之前有个case是因为有上线容易导致数据的错乱，meta信息的更新不全，问题发生在产品层，所以在meta层和data层是非常难发现这个问题的。所以就需要快速地发现。如何做呢？这里采取的方案是抽样。

模拟用户对刚刚写入的文件进行读写，一般是千分之一或者百分之一的比例，这样整体的性能增加也是在百分之一左右不会对系统造成太大的压力，但是可以快速的发现问题，一般一旦出现这个问题就是全局的

如何保证完整

这里我们的思路是两点，分层、聚合、互证，分层是目标，是让不同的系统去解决不同的问题。抽样的目的是按照用户的角度去抽样，去快速发现问题。

分层：业务层、平台层、硬件层

业务层：从用户角度看数据是否正常，比如网盘为例，上传的文件跟下载的文件是否完成一致

平台层：存储平台例如副本是否完成，副本之间是否一致，

硬件层：数据是否损坏，是否有bit反转等等

两层互验：是指隔层之间的元信息是否一致完整性保证：如何确认存储的数据是否完整，这里需要校验元数据，交叉校验，建议数据存储层也存一份元数据，这里的元数据跟元数据存储层做对比。

dropbox的校验思路：https://dropbox.tech/infrastructure/pocket-watch

两层互验：这里重点说一下IO规避的问题

如果一个集群40p为例子如果一条key512k左右，那么就有220亿条key，按照400qps来 计算：需要

40*1024*1024*1024*1024/200/20/60/60/24/400.0=318.145天。那么也是不现实的

经过分析仅仅依赖系统系统的读接口去校验，必须每次校验都需要读取key所对应的value，而实际只是需要知道这条key是否存在，md5，长度。而不需要完整的value。这里有两种方案

方案一：系统改造提供；key是否存在，md5，长度的接口。优点：实时，可以跟线上保持同步缺点：实现起来比较复杂，这个接口的使用也会跟线上服务产生竞争，导致读写失败

方案二：把key的元信息dump到文件中，处理这个元信息文件优点：实现简单，同时不会引入额外风险，属于离线操作跟线上资源不会有竞争

这样整体的校验思路就是一天左右就可以完成完整性校验，也就是是否存在校验

4.3 数据备份过程的校验思路

数据备份是一个单路的过程也涉及到校验这里简单提一下一共分为三步

1）第一步是保证每一个文件都能传输成功，如果没有第一步则文件容易出现单个文件传输不完整的情况。为什么常用crc32校验，因为crc32的校验速度相比md5更快，效率更高。

2）第二步是为了保证每一轮都能所有文件都传输成功。如果没有第二步，则很容易出现文件遗漏的情况。这一步考虑到效率问题就不用逐个文件比对crc或者md5

3）第三步是保证恢复的有效率，防止备份完后无法恢复情况出现

4.4 总结

数据校验和保证存储可靠的重要环节，一定要在系统设计的时候多加注意，同时数据校验综合考虑数据完整性和实时性。关键点在于，抽样与全量相结合，离线与在线相结合。同时要考虑校验的合理性。

5 数据备份

5.1 数据备份和从零恢复的区别

5.2 为什么需要有数据备份机制呢

看一下这些的例子

事故

谷歌数据中心遭雷击导致0.000001%数据被永久删除

美国知名云服务商DigitalOcean主数据库遭到删除，持续5小时

携程误删除生产代码导致1宕机，损失月/1300万美元，股价下跌11%

下厨房数据误删除，导致数据丢失长达2个月之久

GitLab误操作导致300GB生产数据误删除，约丢失5037个项目

华为员工误删除南宁移动用户数据，面临5亿罚款

腾讯云故障致客户数据丢失，遭千万索赔

5.3 为什么这里不讨论从零恢复呢

5.4 如何来做备份呢

这里是一个通用的备份系统一个分为四层

备份存储层—常用的有磁带、文件系统、云服务等等，比如阿里云

备份传输层—常见的技术p2等

备份中间层—这层需要保障数据备份时候的可靠和完整

备份管理层—提供给用户一个操作的入口和运维入口

5.5 备份资源如何平衡

我们需要整体考虑到资源问题

分层和数据流动的配合，常见的做法冷、温、热三种方案

同时需要考虑数据压缩技术

压缩工具 原始文件 目标文件 压缩比 压缩时间
gzip 29G 5.0 17.2% 25m15.036s
pigz 29G 5.0 17.2% 1m24s
lz4 29G 9.3 32% 2m57.367s
lzma 29G 4.7 16.2% 38m50.260s

5.6 如何保证备份数据的有效性

这里需要两个手段，数据校验，和恢复演练。数据校验会在后面的文章中介绍到，今天看一下恢复演练

5.7 恢复演练

如果每个业务都恢复那么恢复的成本就会特别高，

参考一下美国选举。

相同类别汇聚，每个类型选取1-2进行恢复即可

5.8 数据备份和恢复是最后一道防线也是最有效的防线，一定不能放松

6 最后终极武器—数据医生

上面的技术其实都是手段，其实最理想的还是一个贴身医生，

医术最高的境界如何衡量 这里古人给了我们很好的解释

华佗解释道：“大哥治病主要在病情发作之前，由于一般人不知道他事先能铲除病因，所以他的名气无法传出去。二哥治病，主要是治病于病情发作初起之时，一般人认为他只能治轻微的病，所以他的名气只传于本乡里。而我治病，是治病最严重的时候，一般人都看到我能做大手术，所以，认为我的医术高明，名气自然就响遍全国

所以最高境界是在发病之前就能感知就能去掉，而不是在发病的时候再去治疗

数据医生其实不是一个系统而是一个体系，包括评测

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8