大规模机器集群-故障自动处理(一)

前言

大规模集群，通常是一家公司经过多年发展积累起来的，机器规模达到数万台，服务类型涉及接入、web、业务逻辑、cache、大数据、机器学习等，有以下特点，

特点	现象&问题
机器规模大, 过保机器多，故障率高	数万台机器的集群，过保机器超过30%，硬件故障率约1.3%，其中磁盘故障率约7.5%
业务模块数目多，上下游关联复杂	处理机器问题需要同步处理上下游关系，包括监控、变更系统、状态同步等
机器环境差异大，故障处理、环境部署方式各异	环境设置不一样，包括系统、内核参数，基础环境依赖等
机器利用率不合理	A业务机器资源紧缺，B业务机器空闲，却无法快速调配使用
机器归属管理困难	不同业务的机器，借用、归还、环境清理、过保下架等流程冗长，沟通成本高
机器自动化处理工具不具备通用性，复用性低	A业务机器的自动处理工具，无法直接在B业务使用，运维工程师重复开发，无沉淀

这些问题，存在于整个机器生命周期里，从上架通电到下架报废，不定期制造业务故障，例如因机器故障导致的部署失败、版本不一致、读写异常、性能陡降等；日常消耗一线运维10%～20%的时间，还造成大量的机器、机架资源浪费，得不到有效利用。

本系列文章目录如下，讲述了解决这些问题的方案和实现，实际效果，踩过的坑，希望对读者有帮助。

1. 机器运维相关的数据

2. 机器运维模式的思考

3. 机器故障自动处理

4. 机器基础环境管理

5. 大规模集群机器快速交付

6. 机器日常运维效率

注： 运维工程师= SRE = OP，这三个名词有各自的定义，为表述方便，这里简单地认为是同义词。

1. 机器运维相关的数据

 

一切从一次机器“摸底排查”开始。

排查的结果是: 数万台机器的集群，过保机器约占30%，硬件故障率约1.3%，其中磁盘故障率约7.5%，这意味着近千台整机，几千块磁盘处于故障状态，还有数量不小的过保机器、无主机器无人跟进处理，机器资源浪费严重。

同时，我们访谈了各业务线运维同事，从前端web到后端存储，从在线到离线，询问“关于机器运维存在什么问题”，得到了各式各样无法量化的“苦水”；

• “Oncall 每周都要重启、报修十几台机器，又摘服务又传数据又恢复服务什么的，烦死了”

• “上线部署时，老是有一些机器部署失败，都是些死机、根目录读写失败的，处理这些长尾要几个小时”

• “这次case study 是机器坏了修好后忘了同步程序，版本不一致，部署时把老版本程序带起来了，这太坑了！”

• “喂，键盘仔，limits参数没改，服务起不来啊”

• “你这自动处理系统不行啊，把有数据的机器重装了，数据丢了，你发故障报告吧!”“谁叫你不认真看我的文档啊，我这是前端机器故障处理系统，你有业务数据就不能用! 你发!”

• “业务紧急扩容，借我们50台机器吧”, 1个小时过去了，sre还在确认这些机器上各个服务都是谁的，要停服

• …

这个苦水列表还可以再列好多条，我反问他们为什么平时不反馈出来，原因大体都是：

这些问题都是零碎的，平时这几台机器死机，那几台机器掉块盘，还有些机器处于薛定谔状态，内存报CE\UE信息, 不知道什么时候会出问题；

反馈出来，经理强调一下，大家集中处理一波，故障数量暂时下去之后，积攒一段时间又上来，如此反复，endless。

通过统计机器故障、细化机器操作任务耗时、历史故障case的方式，我们得到了以下数据：

• 过保机器约占30%，硬件故障率约1.3%，其中磁盘故障率约7.5%

• 机器运维任务占一线运维工程师总时间的20%左右

• 因机器故障导致的业务故障，平均每个月有1～3次

所以我们要从业务稳定性、运维效率、硬件成本出发，解决这些问题。

1. 机器运维模式的思考

 

在传统的运维模式里，机器归属天然是按业务来分的，即某个业务的运维工程师负责本业务机器的运维工作。这种划分方式存在以下问题，

• 重复投入人力，如机器故障维修，各业务工程师都要做故障检测、服务离线、硬件维修、环境初始化、服务上线等相同流程的工作，且由于业务的差异(如无状态的web服务，有状态的存储、模型计算服务)，实现的方案不具备通用性

• 工程师的主要工作是业务运维，没有精力去解决机器任务长尾、自动化安全性、通用性、扩展性问题，已实现的方案无法复用，机器运维效率没有真正提高

针对传统运维模式存在的问题， 我们在运维人员和机器之间加入了“机器管理系统”，消除机器环境、故障修复流程等差异，统一提供故障管理、环境管理、归属管理、任务管理、统计管理的功能组件，向运维工程师屏蔽机器运维细节，提高机器运维操作效率、机器资源利用率；

同时考虑了可扩展性、通用性，即新业务机器可低成本地纳入管理、不同业务类型的处理逻辑可通过插件的方式集成到系统中，有利于自动化程度的提升，工具的复用，自动化任务的沉淀。

通过这种方式，逐步提高机器运维效率，减少故障机器的积攒，而故障机器的减少，间接提高了稳定性。

2. 机器故障自动处理

我们从最大的痛点开始，一线运维日常要花费大量人力处理机器故障，如下图所示，

 

监控系统监控到硬件故障、任务系统执行失败、rd使用机器时的异常，都需要运维工程师来处理。

为什么做不到自动化？我们围绕以下4方面来分析。

• 通用性与差异化

• 通用设计与具体实现的关联

• 自动化与安全

• 流程、闭环、扩展性

通用性与差异化

在不同的环境里，故障自动处理过程的差异化是非常大的。

1. 如果是无状态服务，比如nginx web服务、java application服务，通常只需要重启机器、重刷环境、重新部署服务就可以，如果是硬件故障，可以直接报修，不用处理上下游。

2. 如果是有状态服务，比如索引服务、推荐服务、模型训练服务，业务方是希望尽可能在不重启机器的情况下修复，更不能直接报修重装，因为这涉及上下游关系更新、部署系统摘除、数据迁移等一系列工作，耗时从几个小时到几天都有可能。

3. 对于不同故障，不同业务的处理方式也不一样。例如，

内存、cpu、风扇这些硬件故障，不一定会马上死机，但存在宕机风险，无状态服务可以接受一旦出现这些风险就直接停服报修，而有状态服务不允许；

对于系统故障，比如文件系统异常，出现 Input/Output Error，此时系统已经异常，基础agent 已经无法正常工作，部署、执行任务都会失败，但服务还正常跑着，所以业务不希望停机；

对于基础环境文件缺失，业务更是希望不停机。

4. 机器修复后，服务恢复的方式也不一样，无状态服务只要保证和线上版本一致就行；而有状态服务，涉及从哪里拷数据，拷完后启动加载数据，确认加载完之后，才能引流。

可以看到，这么多的差异，是各业务线的机器运维工具无法复用的原因，

如果仍然按现有模式来做自动维修，可以预见的结果是，新系统也会陷入一大堆的复杂修复逻辑的泥潭里，所以我们第一个要解决的就是通用性问题。

经过分析抽象不同业务的维修流程，得到一个通用的维修流程：故障检测、服务离线、故障维修、环境初始化、服务上线，如下图，

这个流程，不管是有状态服务，还是无状态服务，以何种方式维修，都可以覆盖。

通用设计与具体实现的关联

第二个问题，通用流程如何与具体的差异化逻辑关联。

比如针对“故障维修”这个环节，“磁盘硬件故障修复”和“文件系统异常修复”是不同的，如何关联起来，有两个思路：

1按现有模式，各自写一个修复工具，遇到什么样的问题，就调用那个修复工具。这种方式，效率、成本、效果都不好，因为总会有新的问题出现，就得写新的修复工具，写完后还得重新加载注册修复工具，设置问题与工具的对应关系，然后还得保证修复工具的成功率，这些都是成本。

2 经过运维工程师们讨论，最终的修复方法是两个原子操作：重启、重装。

因为，修复工具也有较大的概率修复失败，当修复工具也修不好时，只能重装，还不如一开始就选择重装。

比如磁盘文件系统故障，选择单盘在线修复重新挂载，这个过程异常艰难，lsof找出占用磁盘的服务，kill / fuser 停服，umount磁盘，修改fstab，fsck/fdisk，mount，这么复杂且耗时的操作下来，可能大概率修不好，真是一顿操作猛如虎，一看成功率二点五；而选择重装，无硬件问题的，基本30分钟内交付，有硬件故障需要更换配件的，也有SLA约定的交付时间。

据此我们得到一张“简单粗暴”的表格，

故障类型	处理方式	备注
宕机故障	重启	如果重启失败，当作硬件故障，走重装
硬件故障	重装	硬件故障包括：cpu/内存/磁盘/风扇/电源故障

注: 系统部在重装机器时，会对硬件进行检测，如果有硬件故障，会先修复再重装

自动化与安全

这个问题，是从稳定性、安全角度考虑的。

如果自动化之后，效率是提高了，但是重启/重装错了机器，那还不如不搞自动化，所以自动任务的安全策略也作为重点考虑，在真正开始执行自动任务之前，设置多道防线，例如白名单/阈值/服务容量等，更多安全策略细节，将在后续章节中阐述。

加入安全策略后的流程：

流程、闭环、扩展性

如何把上述流程衔接起来? 工作流天然就是干这个的。

但是这里的“衔接”，有运维角度看重的要求： 闭环 和 扩展性。

下面这张图展示了 闭环、扩展性的特性。

闭环

在以往的机器自动化工具中，始终面临一个棘手问题，就是自动化任务的“中断”，

比如，

自动任务发起重启，超过1小时未启动

发起硬件维修的机器，超过规定时间仍未交付

中断之后，往往没有后续的处理动作，通常都是机器的使用方催促了，才去人工介入处理，这使得rd、sre都觉得“自动化工具并不自动，非常挫！”。

我们通过 “任务分支“ 来解决“中断”的问题。

一台机器出现故障后，是有明确的状态的，要么机器修复，恢复上线；要么机器不可修复(通常是过保)，下架处理；从图中可以看到，如果“故障维修”环节无法完成，则系统可以执行“机器下架”分支，最终达到流程结束的状态，而不是“机器发起维修了，但是很久也没有交付“的中间状态。

有了任务分支，就无需人工介入，形成闭环，最大程度地保证了自动化。

扩展性

服务上下线，是一个复杂的过程，涉及新部署一个实例，数据拷贝，从上游摘除等操作， 这就要求系统能方便地、低成本地增加任务节点。

我们通过任务链表来实现，从图中“服务离线”环节可以看到，action 是可以扩展数量和指定顺序的，实现细节会在后续章节中阐述。

经过上面的分析，可知自动维修系统由几个关键子系统组成，

• 工作流系统

• 故障检测

• 安全策略

• 维修工具及SLA

下一篇开始阐述具体的实现。