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

前言

大规模集群，一般是一家公司通过多年发展积累起来的，机器规模达到数万台，服务类型涉及接入、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. 机器运维模式的思考

 

 

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

1. 1. 重复投入人力，如机器故障维修，各业务工程师都要作故障检测、服务离线、硬件维修、环境初始化、服务上线等相同流程的工做，且因为业务的差别(如无状态的web服务，有状态的存储、模型计算服务)，实现的方案不具有通用性
   2. 工程师的主要工做是业务运维，没有精力去解决机器任务长尾、自动化安全性、通用性、扩展性问题，已实现的方案没法复用，机器运维效率没有真正提升

 

 

 

 

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

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

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

 

 

2. 机器故障自动处理

 

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

 

 

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

 

为何作不到自动化？咱们围绕如下4方面来分析。

1. 通用性与差别化
2. 通用设计与具体实现的关联
3. 自动化与安全
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 闭环

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

好比，

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

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

 

中断以后，每每没有后续的处理动做，一般都是机器的使用方催促了，才去人工介入处理，这使得rd、sre都以为“自动化工具并不自动，很是挫！”。

 

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

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

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

 

2 扩展性

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

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

 

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

1 工做流系统

2 故障检测

3 安全策略

4 维修工具及SLA

 

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