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

in 网站建设
关注公众号【好便宜】( ID:haopianyi222 ),领红包啦~
阿里云,国内最大的云服务商,注册就送数千元优惠券:https://t.cn/AiQe5A0g
腾讯云,良心云,价格优惠: https://t.cn/AieHwwKl
搬瓦工,CN2 GIA 优质线路,搭梯子、海外建站推荐: https://t.cn/AieHwfX9

前言

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

image.png

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

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

  1. 机器运维相关的数据
  2. 机器运维模式的思考
  3. 机器故障自动处理
  4. 机器基础环境管理
  5. 大规模集群机器快速交付
  6. 机器日常运维效率

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

  1. 机器运维相关的数据

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

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

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

  1. “Oncall 每周都要重启、报修十几台机器,又摘服务又传数据又恢复服务什么的,烦死了”
  2. “上线部署时,老是有一些机器部署失败,都是些死机、根目录读写失败的,处理这些长尾要几个小时”
  3. “这次case study 是机器坏了修好后忘了同步程序,版本不一致,部署时把老版本程序带起来了,这太坑了!”
  4. “喂,键盘仔,limits参数没改,服务起不来啊”
  5. “你这自动处理系统不行啊,把有数据的机器重装了,数据丢了,你发故障报告吧!”“谁叫你不认真看我的文档啊,我这是前端机器故障处理系统,你有业务数据就不能用! 你发!”
  6. “业务紧急扩容,借我们50台机器吧”, 1个小时过去了,sre还在确认这些机器上各个服务都是谁的,要停服

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

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

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

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

  1. 过保机器约占30%,硬件故障率约1.3%,其中磁盘故障率约7.5%
  2. 机器运维任务占一线运维工程师总时间的20%左右
  3. 因机器故障导致的业务故障,平均每个月有1~3次

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

机器运维模式的思考

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

    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 约定的交付时间。

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

image.png

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

自动化与安全

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

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

加入安全策略后的流程:

流程、闭环、扩展性

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

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

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

1 闭环

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

比如,

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

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

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

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

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

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

2 扩展性

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

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

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

1 工作流系统

2 故障检测

3 安全策略

4 维修工具及SLA

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

关注公众号【好便宜】( ID:haopianyi222 ),领红包啦~
阿里云,国内最大的云服务商,注册就送数千元优惠券:https://t.cn/AiQe5A0g
腾讯云,良心云,价格优惠: https://t.cn/AieHwwKl
搬瓦工,CN2 GIA 优质线路,搭梯子、海外建站推荐: https://t.cn/AieHwfX9
扫一扫关注公众号添加购物返利助手,领红包
Comments are closed.

推荐使用阿里云服务器

超多优惠券

服务器最低一折,一年不到100!

朕已阅去看看