"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营, 我们希望与业界各位志同道合的伙伴交流切磋最新的网络服务器行业动态信息, 同时分享腾讯在网络与服务器领域, 规划运营研发服务等层面的实战干货, 期待与您的共同成长
背景
伴随着腾讯业务的蓬勃发展, 近几年服务器数量快速增长, 随着时间的推移, 现网逐步累积了大批量服役年份时间很长的服务器, 服务器运营面临日益凸显的服务器整体老龄化问题理论上服役时间越长的服务器发生故障的几率也将越大, 从腾讯全网服务器的统计结果也表明服务器老龄化的加剧, 故障概率会加速上升, 特别是使用年份超过 4 年的设备故障率将出现陡升的情况, 显而易见高故障率的老龄化设备将对现网业务造成巨大的影响, 也极大的提高了运营复杂度和成本
在这些故障中贡献最多的当属硬盘了(如图 1 所示), 它在服务器部件故障中占比高达 70% 以上, 这也归结于它的体量最大, 并且生命周期比较短(如表 1 所示), 硬盘的生命周期一般只有 3 到 5 年我们的服务器使用年限超过 5 年后, 硬盘故障率都是非常高
于是乎, 想快速有效的降低服务器故障的影响, 核心就在于降低硬盘故障的影响当前业界采用更多的是在线故障监控和故障后自动修复, 不能修复则只能换盘, 并做业务迁移, 虽然这一定程度上也起到了一些作用, 降低了数据丢失的风险和对业务的影响, 但毕竟有点马后炮了故障不可避免, 故障永远会发生, 但如果我们有一双未来之眼, 可以提前预知故障的发生, 从容淡定的迁移数据和业务, 该有多好
一硬盘预测面临的困难
虽然预测这种东西由来已久, 但真正能做到精确的寥寥无几像地震, 虽然根据监控地壳的活动和动物的异常行为, 可以提前预知地震的发生, 预留一些时间, 让人们可以提前迁移到庇护所, 尽可能减少人身财产损失, 并且早在公元 132 年就有地震仪的诞生, 但到目前为止, 仍然无法精确的预知它的发生因为这里面涉及到的因素太多, 方方面面都要考虑硬盘故障也是这样, 从 20 世纪 50 年代至今, 经历了一系列技术革新和换代, 到目前为止, 仍然很难预测它何时会坏虽然可以从统计学上获取一些粗略统计: 服务器及关键部件生命周期上限一般是 5 年, 行业内针对大于 5 年的老龄设备通常采取的是直接退役的方案, 但是并不适用于体量巨大的我们, 考虑到成本业务迁移等问题, 这种方案还是太过任性了些既然一刀切不行, 那是否有折中方案可供选择呢
二硬盘故障预测的探索过程
俗话说巧妇难为无米之炊, 没有依据如何预测, 所以数据源的选取是头等大事, 有了数据才能开搞但是面对杂七杂八体量巨大的数据, 如何才能将它玩出花样来这里涉及到一系列的数据处理数据建模和模型验证的过程 (如图 2 所示) 为了达到更佳的预测效果, 可能会重复多次建模, 直到模型的预测结果符合标准为止
1 关于数据源
自 13 年以来, 我们就陆陆续续对硬盘故障开展了一系列的研究和分析, 虽说现在数据挖掘技术日趋完善, 但预测的首要问题在于数据的选取, 高质量的数据, 对最后取得良好的预测效果有决定性的作用, 所以没有数据支撑, 何谈预测所以我们经历了一连串的筛选过程
刚开始很容易想到的是硬盘的宿主服务器, 会是个主要影响因素, 因为我们已经知道随着服务器上架年限的增加, 整体故障率会逐渐加速上升, 由此推测如果在上架时间的基础上, 再结合机型业务等维度, 是否能给出一些推论甚至于有价值的结果呢所以我们用聚类的方法, 对此进行了统计分析, 但是结果并非如此或许这些服务器配置信息能给出一些统计结果, 我们想要的是即将故障的硬盘, 而不是这些差异性不大的各个集合的整体故障率
我们希望知道的是单块盘的故障概率, 把危险的盘更明显的标记出来, 所以后来我们又考虑了磁盘 I/O, 因为直观上就觉得磁盘负载越高就越容易坏, 所以决定一试究竟我们对三种值进行了分析: 每秒磁盘读写块数和每秒之中用于 IO 操作的 CPU 时间占的比例, 通过对比多种方法, 最终我们选用临近两个时间点之间的 IO 变化的绝对值作为主要的元数据, 也就是后一个时间点与前一个时间点对应 IO 差的绝对值, 简称为 IO 跳变它与磁盘故障间关系如图 3 所示:
由上图可以看到故障时的 IO 跳变大小排在前 10% 的故障数占比 66% 以上, 看到这个本来让我们有信心可以用它来预测磁盘故障了但是最后的预测正确率却不到 40%
我们再接再厉, 又考虑了磁盘 S.M.A.R.T(Self-Monitoring Analysis and Reporting Technology 自我检测分析及报告技术, 后面简称 SMART)之所以考虑用 SMART 作为核心数据, 一则是因其相关技术发展比较成熟, 至今也近 20 年了, 业界对其认可度较高, 二则我们内部对硬盘故障的发现和修复, 大部分也是依据 SMART 信息, 而且采用 SMART 是经过我们实际验证的结果, 所谓不信广告信疗效嘛
2 数据处理
数据积累到一定程度后, 发现问题来了, 数据量太大, 如何用? 如果只是几百万数据, 那还简单, 可是现在是几十上百亿条一两百个维度的数据, 没有装备玩不转如何破? 幸好我厂有 TDW 这么高大上的系统, 借助于 TDW 强大的数据存储和计算能力, 我们才可以把这个事情顺利地开展下去
一百多个维度的 SMART 信息并不都跟故障密切相关, 如果一股脑全用上, 有些反而会成为干扰项, 所以经过关联分析和聚类分析, 层层筛选, 最终只选取了其中 13 项作为我们建模的基础数据, 如表 2 所示:
值得一提的是, 由于每种特性分原始值 raw 和标准值 value, 原始值范围不一, 会影响权重, 故而这里我们主要取的是标准值 value, 可以理解为归一化后的值对于 Reallocated Sector Count 和 Current Pending Sector Count 这种核心项的原始值也会给与一定的考虑, 例如会重点关注坏块达 800 的硬盘故障情况
3 预测模型
这里选取的是支持向量机 SVM 来对历史故障样本和非故障样本建模, 再将模型用于线上数据其他故障预测方法, 像 K-Means 聚类逻辑回归 (Logistic Regression) 神经网络(Neural Network), 我们都做过尝试, 也遇到了不少坑, 最终选定了 SVM 算法
4 统计模型
上面说的 SVM 是个二分类器, 也就是说在它的世界里非黑即白, 无所谓中间状态, 那问题来了, 这个耿直 boy 给出的结果这么多, 就算判刑也要有个轻重之分吧, 我们怎么判断哪些是更坏的可以直接判死刑, 哪些是没那么坏的可以判个死缓呢? 所以这里我们根据对历史预测结果, 结合硬盘型号服务器类型上架月份版本号等维度, 进行统计, 计算出每个小集合的正确率, 然后倒排, 这样我们就可以很轻易的排出轻重缓急了如图 6 所示, 横坐标代表每个小集合的编号, 这里就有一万多个小集合点 A 之前左边对应的小集合的正确率都是 100%, 之后开始逐渐下降, 于是累计正确率开始被拉低, 到点 B 的时候是 80.93%, 如果继续往右, 会继续下降, 直到点 C 也就是整体正确率的 44.46% 因此可以通过酌情设置门限 (对应小集合的累计正确率, 后面简称为预测比) 就能将重要紧急的先放出来, 剩下的可以从长计议另外这个门限是随时可调的, 增加了很大的灵活性
5 运营模型
有了预测模型, 可以给出预故障盘, 有了统计模型, 可以给出预故障盘的预测比但是问题来了, 对于运营同事来说, 不同的服务器可能优先级又会有所差异, 并且这个优先级还是随时可调的为了支持我们提供了运营模型设置, 主要包括服务器类型, 上架年限, 服务器健康度, 业务模块, 预测比, 坏块比, 性能参数等, 系统会根据这个设置表, 对满足其中任意一条规则的预测故障盘, 自动发起故障流程至于不符合任意一条规则的也会展示出详细信息, 供运营同事进一步确认
如图 7 所示(受篇幅所限只列出了部分维度), 第二行表示预测比在 0.6 到 0.8 之间并且上架月份在 3 到 6 年的预测故障盘如果单看预测比可能会觉得这个指标略低, 因为按照我们前期定的标准: 预测比要达到 80% 以上才可发起故障单, 而对 80% 以下的, 则不做过多考虑但按照我们之前的统计, 5 年以上的老旧机器故障率会加速攀升, 如果这部分机器已经有故障的态势, 那么它故障的概率比正常机器要大得多处于这种考虑, 我们在预测策略中, 将预测比和上架月份结合了起来所以第二条策略, 既考虑了预测比在 60% 到 80%(略低于 80%), 又考虑了上架月份满足 3 到 6 年(老旧机器), 这样我们就会更加有信心了其他规则也是类似的根据不同维度之间的权衡给出来
6 总体框架
结合上面几点, 基本上就得到了我们的系统总体框架, 如图 8 所示这里提到了 SMART 阈值检查可以作为一种简单的判断过程, 它会将 SMART 的核心项远远超过正常值的情况直接判断为预故障另外, 在应用层我们会提供预测结果查询页面, 可以查看预测单的状态和相关信息, 进行运营模型设置, 人工激活预故障单, 由系统发起故障处理流程
三效果篇
现已完成多个硬盘型号的故障预测, 各型号预测正确率和故障覆盖率如表 3 所示其中前六种型号达到运营要求, 已进入推广, 具体覆盖 65% 的 SATA 盘第七八两种型号暂需进一步优化和验证后才会放出来剩下的部分体量少, 还需进一步优化和验证
部分型号提前天数 & 预测正确率的趋势参考图 9:
值得一提的是, 刚开始我们把预测单与实际故障单作对比时, 效果并不是非常理想因为我们预测是以 SMART 数据为准, 我们报出来的预故障单都是从 SMART 上看, 属于亚健康甚至病危状态的硬盘而实际故障单是以磁盘自检失败并且不可在线修复和系统 dmesg 信息中的错误关键字 (主要包括 SCSI 设备掉线, ATA 设备超时和设备故障) 为准发起故障处理流程, 并且结单故障类型为硬盘故障, 也就是说有实际换盘的, 这个定义其实是相当严苛的, 它其实会漏掉很多情况因为结单故障类型是现场去确认后填写的, 如果没有换盘或者没有填写结单故障类型就会算是我们的误报, 这真是比窦娥还冤另外实际故障单更多的侧重于依赖 OS 层面的判断, 把部分能捕捉到的问题暴露了出来, 其实一定程度上漏掉了一些健康堪忧但并未报障的硬盘, 也就是说硬件本身当前最原始的健康状况被忽视了针对这些问题, 我们把误报的部分提供给厂商确认, 的确被确诊为病态盘甚至于高危盘于是我们不单纯依赖于结单故障类型, 还要关注单块硬盘自身的健康状态如果它的 SMART 核心项远远超过安全阈值, 也会作为故障判断这一点在运营模型中也有所体现: 预测比就是根据实际故障单而来, 坏块比和性能指数就是 SMART 核心项的反映有了这些支撑, 我们的预测正确率才能一步步逐渐提高
运营同事可以通过提供的预测管理页面, 做一系列的操作, 包括批量预测结果查询手工触发报故障单处理策略管理阈值管理状态维护处理进度管理等功能从 2016 年 2 月到 5 月, 共预测出 2353 片硬盘故障, 现网已灰度产生 2340 单故障, 其中人工发起 1962 单, 自动发起 378 单 (前期比较谨慎, 运营逐步确认后发起, 后续会逐渐放开) 成功预测的硬盘故障数量, 粗略估算已覆盖 SATA 硬盘故障数的 50% 左右, 进而促使 5 年以上服务器对业务影响的硬件整体故障率也下降了 0.5%
四未来展望
故障预测类似于临震预报, 最重要的意义是给用户一个从容的时间段进行数据和业务的迁移或处理, 改善用户体验但预测技术的研究也是一项厚积薄发的事情, 从摩拳擦掌跃跃欲试到真正落实下来, 也经历了一系列的磨砺过程, 最终的点点成效就是最大的肯定后续将 SASSSD 作为核心, 希望能有更大的作为当然, 我们也会与服务器厂商和设备供应商一起紧密合作, 在 FW 和介质底层更深入的分析硬件失效的原理, 对持续降低故障率发起挑战
注 1: 凡注明来自鹅厂网事的文字和图片等作品, 版权均属于深圳市腾讯计算机系统有限公司所有, 未经官方授权, 不得使用, 如有违反, 一经查实, 将保留追究权利;
来源: https://cloud.tencent.com/developer/article/1037692