亲宝软件园·资讯

展开

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

曲行人 人气:1

本篇开始介绍具体的实现过程,为表述方便,先定义一些名词,

  • AutoRepairSystem: 故障自动维修系统, 缩写为ARS

  • 原子操作:任务的最小操作,机器任务通常是指重启、重装

  • 运维人员:运维工程师= SRE = OP,系统工程师 = sys

  • 远程管理工具: 远程控制操作物理机器的工具,如ipmi、ilo

 

先来看ARS的整体视图和流程图,

 

 

 

 

 

 

 

 

ARS的工作流程,

  1. 故障检测: 每5分钟发起一次故障检测,获取当前时刻整个集群的故障机器列表,推送到工作流子系统

  2. 安全策略: 遍历故障机器列表,依次执行安全策略,过滤不符合要求的机器,得到一个可安全执行重启、重装的机器列表

  3. 服务离线: 遍历可安全操作的机器列表,执行服务离线

  4. 故障维修: 服务离线后,发起重启、维修操作,轮询机器状态,直至重启成功或维修完成

  5. 环境初始化: 执行环境初始化,保证机器环境符合业务需求

  6. 服务上线: 恢复服务,检查服务达到可服务状态,流程结束

 

接下来将介绍工作流子系统,这是所有具体操作任务执行的基础;

再依次介绍上述流程中的关键环节: 服务上下线,故障检测,安全策略,维修工具及SLA;

然后通过一个线上例子,说明整体的工作流程;

最后分享系统上线后的运行数据。

 

2.1 工作流子系统

工作流最基本的功能,是驱动一系列预定义任务顺序执行,达到明确的结束状态;在机器故障自动处理这个问题域里,对工作流还有闭环、扩展性的要求(详见第一篇的分析).

 

经过分析统计机器相关的操作任务, 比如机器重启、重装、初始化环境、启动/停止服务、查看信息等,抽象出机器操作的任务模型,即”对一组机器执行相同的任务,且任务可以进一步拆分为一系列更小的原子操作组合”,如图所示,

 

 

上图表示对一组机器执行相同的任务,下图表示,这个任务具体有4个原子操作。

由此,我们可以定义工作流的几个关键类,以及他们的关系,

 

 

 

 

 

注:为了简化表述,这里只列出和流程执行、任务分支、通用性相关的字段和逻辑,工作流子系统的完整信息,后续会另写文章介绍。

 

  • Job,定义了任务类型以及要操作的目标集合

  • Task,定义了一个具体的操作目标,以及action_tree的root节点

  • Action,定义了业务逻辑的内容和加载方式

  • Scheduler, 调度Job的运行

  • Monitor, 监控 Job、Task、Action 的状态

  • Executor, 控制Job下的task/action 的执行顺序、并发等

 

接下来重点看看工作流系统是如何达到前文提到的扩展性、闭环要求的。

 

第一点,扩展性。

 

 

扩展性需求,最初来自于不同服务上下线操作的差异,主要是有状态服务。

它们之间的差异,体现在操作步骤的数量和顺序不同。例如,

  • 推荐模型服务,要求先寻找可用的机器资源,在新资源上部署相同版本的服务,启动服务加载数据,判断数据加载进度,直到达到某个阈值,才算是完成“迁移”,此时才达到可维修的状态

  • Docker服务,相对简单,只需向docker发起迁移命令,等待docker返回迁移进度,迁移完成后即可维修

  • Hadoop服务,主要痛点在磁盘故障上,要求维修过程中不能长时间停服,所以维修逻辑很复杂,要先停止本机服务,umount故障磁盘,启动服务,维修故障磁盘,修复之后再停服,起服,让Hadoop重新使用这块磁盘

  • 其他无状态服务相对简单,通常直接维修即可

 

 

可见,不同服务的差异化是不可穷举的,如果ARS要介入具体的维修逻辑,无异于“揽屎上身”,最终陷入泥潭里无法自拔。

 

我们的思路是: 对外提供一套机制,能简易地将维修逻辑嵌入工作流子系统,实现步骤如下,

  1. 将复杂任务拆解成多个原子操作,每个原子操作实现为一个python方法,返回值格式固定

  2. 定义原子操作的执行顺序以及分支

 

只要满足上述条件,系统就能支持任意数量、任意顺序的原子操作集合。

 

原子操作的python实现如下图所示,

 

 

action1为原子操作名字,do_hard_work()方法由业务sre 完成,工作流子系统只负责调用, is_succ表明本次操作是否执行成功,result通常是操作结果信息。

 

只要按照这个约定编写的任务,都可注册到系统里被执行,哪怕提交人只是用python 包了一坨 shell 脚本,也是可嵌入系统的,虽然我们在review的时候会“建议”他重写。

 

有了原子操作的实现,就可以定义它们的执行顺序,我们使用了“树”的概念,如下图json配置示例所示,

 

 

 

可以看到,整棵树有多棵子树组成,每棵子树指向一个nodes list,每个node就是一个action, action的数量和顺序可以在nodes list里任意配置扩展。

在example_trees里, action1~action6就是原子操作,执行的顺序有两种可能分支,

action1-> action2 (true)--> action3->action4->结束;

action1-> action2 (false)--> action5->action6->结束;

 

假设现在业务有一个大的改动,需要在action2之前增加一个操作action7, 并在action6之后,增加一个分支action8,  这只需在配置上小改动即可实现,

 

 

 

example_trees 会被保存在Action类的action_definition字段里,这个配置记录了执行逻辑的python 文件,类和方法; 工作流在运行时,会动态加载相应的类,根据方法名调用方法,如下图所示,

 

 

 

 

凭借这些特性,业务sre可以灵活多变的定义自己的任务树,其中公共部分,由平台sre编写,与业务相关部分由业务sre编写。

 

第二点,闭环。

以无状态的 web机器的宕机自动处理流程为例,(这里为了方便表述,做了简化)

  1. 检测宕机的机器

  2. 重启机器

  3. 如果能起来,检查程序版本,启动web 服务,流程结束

  4. 如果不能起来,则报修硬件故障

  5. 如果能修复,回到第3步

  6. 如果不能修复,则检查是否过保,如果是,则下架机器,流程结束

 

其流程树的配置如下,

 

 

 

 

 

可以看到,reboot_host、check_host_alive、repair_host等action为原子操作;

这棵树有两个分支节点,

如果 reboot_host之后 check_host_alive为Ture, 则执行online_service 分支,流程结束; 

如果为false, 则执行repair_host 分支,如果能修好,则回到 tree2 ,最后也达到 online_service的状态,  流程结束;(只要是没过保,都能修好)

如果修不好,那么则进入 off_rack 下架流程,流程结束。(通常是机器过保)

 

这里之所以反复强调任务分支,是因为有了任务分支,就可以在各个可能执行失败的环节,指定下一步的操作,最终将目标操作到一个可预期的状态(机器要么被修好重新投入使用,要么修不好被下架),形成闭环,不用人工介入,真正提高自动化程度。

同时,由于在一开始就设定了维修只有两种操作:重启,重装,这两种操作都由sys来保证交付时间,所以这棵树能保证流程是闭环的。

 

在ARS上线之前,早期的自动工具发起重启命令之后,机器起不来,通常是人工通知sys 报修,报修之后 sys 再根据机器是否过保来给sre 反馈维修状态,这个过程,如同黑洞,吞噬了rd-sre-sys-机房外包四方大量的沟通时间, 如图所示,

 

 

工作流子系统还涉及状态机、并发控制、重试、任务重入、超时、执行进度等,后续另写文章介绍。

 

在下一节里,将介绍故障检测、安全策略等内容。

 

2.2故障检测

故障检测的完整性、正确性是故障维修自动化的前提。

通过分析历史机器故障类型,可将故障分为5个层次,如下表,基本覆盖了sre日常处理的故障。

 

层次

异常类型

常见问题

检测方式

业务相关

执行异常

磁盘空间不足、部署时调用的control脚本返回值异常、目录权限

Falcon

运维系统

平台自身异常

帐号异常、Executor执行任务异常、部署系统异常

Falcon+运维系统接口

基础环境

依赖异常

环境异常(依赖库/文件缺失)、版本不符(内核/python/perl)、limits.conf不符

Falcon+shell/python

系统层

读写异常

文件系统错误(Input/Output Error)、文件系统挂载错误(read-only、home未挂载)

Falcon+shell/python

机器层

连接异常

硬盘故障, 宕机故障, 内存故障, 电源故障, 风扇故障, CPU/GPU故障

ping/ssh/Falcon+ipmi

 

ARS主要覆盖了机器层、系统层,下面分别做说明。

 

磁盘故障

磁盘故障率高的业务类型很多, 如hadoop、索引服务、分布式文件系统服务、机器学习模型训练服务等,这些服务的机器,磁盘块数最高多达36块,大量读写磁盘,造成磁盘故障率很高。

常见的磁盘故障类型有掉盘、读写错误(Input/Output Error)、漂盘、挂载错误、 read-only错误、性能剧降(ls https://img.qb5200.com/download-x/disk/ 超过10分钟无反应);

磁盘故障的积累,有可能会导致数据丢失,以及拖慢整个系统的性能,所以要尽早检测到尽早处理。

 

宕机故障

宕机故障分为完全死机,假死。

完全死机(指连续3个小时失去心跳,并且主动ssh 探测失败的机器),这种情况容易处理,直接进入自动重启流程;

假死,有如下类型,

l  Connection timed out

l  Connection closed by remotehost

l  Connection reset by peer

l  Connection refused

l  Connection closed by

 

这些假死状态,可能会造成业务受损。

比如机器假死,服务端口还能连接,但实际业务进程内部无法正常工作,如果是前端web机器出现这种情况,会导致业务5xx监控飙升;此时,想手动重启,ssh已经无法连接,只能通过ilo重启,或者紧急联系机房,处理耗时往往超过半小时。

 

 

内存故障

内存故障时,通常机器还没有死机,(在/var/log/message 里显示CE error on CPU#1Channel#2_DIMM#1)

 rd认为机器还能跑,不愿意停服务;

如果积攒到多台机器出现类似错误,极有可能在短时间内出现连续死机,导致服务容量突然减少,服务性能大幅下降的业务故障,所以对于一些敏感服务,出现这种故障,还是要当作死机来处理。

 

电源故障

双电源是突然断电、市政施工的保障,如果电源坏了不修,在这种情况下,机器会断电关机,如果积攒多了,服务容量会突减,影响业务。

 

风扇故障

不会马上造成死机,但是会产生连锁反应。风扇故障会导致cpu温度升高,引发死机。

 

 

上述故障检测的实现,主要是通过 Falcon监控系统 + scripts 实现,涉及了 ping/ssh/ipmihttps://img.qb5200.com/download-x/dmesg/proc/sar…等大量系统命令和系统信息。

Falcon 运行这些scripts,检测故障,外部应用就可以从接口里查询故障列表信息,如下,

 

 

ARS从Falcon拉取当前时刻集群内所有故障机器的列表,附带了相应的故障信息,推送到工作流里,进行维修。

 

 

2.3 安全策略

对机器的操作,通常是重装、重启、root环境修改、部署基础agent等;此类操作往往不可逆且无法暂停,所以需要严格的安全策略保证机器操作不影响线上服务或影响最小。

 

经过“故障检测”这个环节后,得到一个当前时刻所有故障机器列表,安全策略会对这个列表进行分析过滤,下表是我们使用的安全策略列表,

 

策略

作用&应用场景

实现

filter_bw _lists

黑白名单;

通常用于敏感服务,如支付、隔离环境服务

只处理白名单内的机器

跳过黑名单内的机器

filter_alive_hosts

过滤掉处于非死机的机器;

防止误判,重启了非死机的机器

1、3分钟内连续ping机器,如果有响应,则过滤机器

2、过滤可以响应 ssh 请求的机器

3、防止网络抖动误判,在多个机房 ping,交叉验证

filter_switch_fail

防止交换机故障引起误判,比如批量机器无法联通

按分钟统计机器的故障时间,如是同一分钟内报上来的(falcon采集周期是1分钟),本次就不会向后端推送任何机

filter_base_agent

过滤掉基础agent端口存活的机器;

某些特殊服务会禁止ping/ssh命令,所以通过基础agent端口来判断存活

通过 telnet/curl  ip:port 判断基础agent是否存活,基础agent存活代表机器存活,过滤机器

filter_running_service_hosts

过滤掉有服务处于running状态的机器;

防止误判,操作了服务还在运行的机器

检查机器网卡流量、磁盘io等指标,超过阈值则认为存在服务,过滤机器

filter_capacities

根据服务容量过滤;

防止因操作了机器,导致服务容量不足

计算服务容量, 当前running实例数/总实例数  < 阈值(90%),过滤机器

filter_duplicate

去重,保证同一时刻同一台机器只有一个操作任务在执行;

防止多个任务叠加到同一台机器,出现未预期结果

遍历系统所有任务,如果此机器有处于running的任务,跳过此机器

filter_pattern

过滤指定patterns的机器;

这是最严格的过滤器,通常是单点服务使用此策略

对机器的机器名、节点名、运行服务名、在各类配置中心注册名进行正则匹配,如果匹配,则过滤机器

filter_threshold

阈值保护,保证同时进行的机器操作任务数低于允许维修的数量

1、按机房粒度,对于不同的任务类型,如果当前此机房的机器操作任务数大于阈值,跳过此机器

2、按服务(app)粒度,如果当前此服务(app)的机器操作任务数大于阈值,跳过此机器

例如这个例子,当前app1任务数是3,而允许维修的阈值是5,所以只能再发起2台机器的维修

current_repairing/beijing/app1: 3  

threshold /beijing/app1: 5

filter_by_date

遵循分级发布原则,在一个星期内的某一天,只能维修对应机房的机器

1、指定每天允许维修的机房

2、遍历所有机器,如果一台机器所属的机房不是当天允许维修的,跳过此机器

 

这个安全策略表,是总结分析多个业务线的历史case study得出来的, 在线上运行以来,未出现过误判,保证了自动任务的安全性。

 

每一个安全策略,实现为工作流里的一个原子操作,即action,结合上述重启的例子,json配置如下,(维修的流程也可以使用这些安全策略,这里不再单独列出)

 

 

这些策略,可复用也可自由组合、调整顺序,这对于接入不同业务的机器进行自动维修,有很大的便利性和灵活性,同时降低了接入成本。

 

如果业务有自己的安全策略需求,只需按照上述的action 方法规范,自己写一个安全策略方法,在配置里指定即可使用。

 

 

2.4 维修工具及SLA

 

机器硬件故障维修,是真实世界中的事件,这个过程需要人去到机房现场,从仓库拿出配件,走到机架旁边,拆卸机器,装配硬件。

所以这个环节是“不可抗力”产生的地方,比如配件备货不足;节假日厂商人员放假,无法赶赴机房;赶上两会,机房封禁,不让进入等各种问题。

 

1  交付时间

为了达到流程闭环,我们(甲方)和机器厂商(乙方)约定机器维修交付时间, 通常是36小时交付(不同公司、厂商可能不一样),至于怎么解决上述“不可抗力”,由乙方负责。

 

2  远程管理工具可用率

远程管理工具是机器操作自动化的必备工具,reboot_host/repair_host底层调用的就是ipmi;

为了尽可能地减少机房现场人员操作,我们要求sys保证远程管理工具可用率达到 99.9%,比如,ilo,ipmi

 

有了这两个SLA,我们可以认为 reboot_host、repair_host 这两个原子操作的最长耗时为36小时,所以维修流程是一定可以闭环的,避免了因任务中断导致的人工介入。

 

当然,有了这些,也只是修复了硬件,还有系统参数设置、环境初始化、基础agent的问题,这个内容比较多,在下一篇讲。

 

将上述提及的技术细节汇总,得到ARS的完整视图,

 

 

 

最后,看一个自动重启的例子,

可以看到任务树定义的actions 是怎么执行的,先是执行一系列的 filter_*安全策略,然后屏蔽报警,执行服务离线,发起重启,然后轮询机器状态,直到任务结束。

 

 

 

 

2.5 系统运行数据

 

ARS上线后,覆盖数万台机器的故障自动处理,死机数量保持在10台左右,所有硬件故障总数量保持在100台以下,这对于一个数万台机器的集群来说,是非常理想的状态了。

 

人力方面,对于20人的sre 团队,机器故障只需要 0.5人力维护系统正常运转,例如新服务的接入、业务要求紧急修复之类的情况;当机器规模增长时,人力并不需要相应的增加。

 

2.6 总结

最后,总结一下几个关键点,

  • 标准,定义了有哪些类型的故障,什么故障执行什么样的修复,修复的标准流程

  • 闭环,对于机器的操作,用任务分支覆盖操作成功或失败的情况,用SLA约束厂商在约定时间内交付机器,保证流程可达到明确的结束状态,避免人工介入

  • 安全,10个安全策略组成的过滤链,并支持低成本的增加新策略,保证自动化任务是安全的

 

在本文中,有一个重要的事项没有提到,就是环境初始化,这个再下一篇文章讲述。

 


 

排列文字,重组感受。

我是曲行人,日常写码,闲时写点儿文字,

如果你觉得有点意思,或者有点用,可以关注我,

我将在大脑里的思维原子做布朗运动时,输出文字。

公众号: qxren7

二维码: 

 

加载全部内容

相关教程
猜你喜欢
用户评论