阿里如何作到百万量级硬件故障自愈？

摘要： 随着阿里大数据产品业务的增加，服务器数量不断增多，IT运维压力也成比例增大。各类软、硬件故障而形成的业务中断，成为稳定性影响的重要因素之一。本文详细解读阿里如何实现硬件故障预测、服务器自动下线、服务自愈以及集群的自平衡重建，真正在影响业务以前实现硬件故障自动闭环策略，对于常见的硬件故障无需人工干预便可自动闭环解决。

随着阿里大数据产品业务的增加，服务器数量不断增多，IT运维压力也成比例增大。各类软、硬件故障而形成的业务中断，成为稳定性影响的重要因素之一。本文详细解读阿里如何实现硬件故障预测、服务器自动下线、服务自愈以及集群的自平衡重建，真正在影响业务以前实现硬件故障自动闭环策略，对于常见的硬件故障无需人工干预便可自动闭环解决。

1.背景

1.1.面临挑战

对于承载阿里巴巴集团95%数据存储及计算的离线计算平台MaxCompute，随着业务增加，服务器规模已达到数十万台，而离线做业的特性致使硬件故障不容易在软件层面被发现，同时集团统一的硬件报障阈值经常会遗漏一些对应用有影响的硬件故障，对于每一块儿漏报，都对集群的稳定性构成极大的挑战。

针对挑战，咱们面对两个问题：硬件故障的及时发现与故障机的业务迁移。下面咱们会围绕这两个问题进行分析，并详细介绍落地的自动化硬件自愈平台——DAM。在介绍以前咱们先了解下飞天操做系统的应用管理体系——天基（Tianji）。

1.2.天基应用管理

MaxCompute是构建在阿里数据中心操做系统——飞天（Apsara）之上，飞天的全部应用均由天基管理。天基是一套自动化数据中心管理系统，管理数据中心中的硬件生命周期与各种静态资源（程序、配置、操做系统镜像、数据等）。而咱们的硬件自愈体系正是与天基紧密结合，利用天基的Healing机制构建面向复杂业务的硬件故障发现、自愈维修闭环体系。

透过天基，咱们能够将各类物理机的指令（重启、重装、维修）下发，天基会将其翻译给这台物理机上每一个应用，由应用根据自身业务特性及自愈场景决策如何响应指令。

2.硬件故障发现

2.1.如何发现

咱们所关注的硬件问题主要包含：硬盘、内存、CPU、网卡电源等，下面列举对于常见硬件问题发现的一些手段和主要工具：

在全部硬件故障中，硬盘故障占比50%以上，下面分析一下最多见的一类故障：硬盘媒介故障。一般这个问题表象就是文件读写失败/卡住/慢。但读写问题却不必定是媒介故障产生，因此咱们有必要说明一下媒介故障的在各层的表象。

a. 系统日志报错是指在/var/log/messages中可以找到相似下面这样的报错

Sep 3 13:43:22 host1.a1 kernel: : [14809594.557970] sd 6:0:11:0: [sdl] Sense Key : Medium Error [current]

Sep 3 20:39:56 host1.a1 kernel: : [61959097.553029] Buffer I/O error on device sdi1, logical block 796203507

b. tsar io指标变化是指rs/ws/await/svctm/util等这些指标的变化或突变，因为报错期间会引发读写的停顿，因此一般会体如今iostat上，继而被采集到tsar中。

 ●   在tsar io指标中，存在这样一条规则让咱们区分硬盘工做是否正常 qps=ws+rs<100 & util>90，假如没有大规模的kernel问题，这种状况通常都是硬盘故障引发的。

c. 系统指标变化一般也因为io变化引发，好比D住引发load升高等。

d. smart值跳变具体是指197(Current_Pending_Sector)/5(Reallocated_Sector_Ct)的跳变。这两个值和读写异常的关系是：

 ●   媒介读写异常后，在smart上能观察到197(pending) +1，代表有一个扇区待确认。
 ●   随后在硬盘空闲的时候，他会对这个197(pending)中攒的各类待确认扇区作确认，若是读写经过了，则197(pending) -1，若是读写不经过则 197(pending)-1 且 5(reallocate)+1。

总结下来，在整条报错链路中，只观察一个阶段是不够的，须要多个阶段综合分析来证实硬件问题。因为咱们能够严格证实媒介故障，咱们也能够反向推导，当存在未知问题的时候能迅速地区分出是软件仍是硬件问题。

上述的工具是结合运维经验和故障场景沉淀出来，同时咱们也深知单纯的一个发现源是远远不够的，所以咱们也引入了其余的硬件故障发现源，将多种检查手段结合到一块儿来最终确诊硬件故障。

2.2.如何收敛

上一章节提到的不少工具和路径用来发现硬件故障，但并非每次发现都必定报故障，咱们进行硬件问题收敛的时候，保持了下面几个原则：

 ●  指标尽量与应用/业务无关： 有些应用指标和硬件故障相关性大，但只上监控，不做为硬件问题的发现来源。 举一个例子，当io util大于90%的时候硬盘特别繁忙，但不表明硬盘就存在问题，可能只是存在读写热点。咱们只认为io util>90且iops<30 超过10分钟的硬盘可能存在硬件问题。
 ●  采集敏感，收敛谨慎： 对于可能的硬件故障特征都进行采集，但最终自动收敛分析的时候，大多数采集项只作参考，不做为报修依据。 仍是上一个硬盘io util的例子，若是单纯出现io util>90且iops<30的状况，咱们不会自动报修硬盘，由于kernel问题也可能会出现这个状况。只有当 smartctl超时/故障扇区 等明确故障项出现后，二者关联才确诊硬盘故障，不然只是隔离观察，不报修。

2.3.覆盖率

以某生产集群，在20xx年x月的IDC工单为例，硬件故障及工单统计以下：

去除带外故障的问题，咱们的硬件故障发现占比为97.6%。

3.硬件故障自愈

3.1 自愈流程

针对每台机器的硬件问题，咱们会开一个自动轮转工单来跟进，当前存在两套自愈流程：【带应用维修流程】和【无应用维修流程】，前者针对的是可热拔插的硬盘故障，后者是针对余下全部的整机维修硬件故障。

在咱们的自动化流程中，有几个比较巧妙的设计：

a. 无盘诊断

 ●   对于宕机的机器而言，没法进无盘(ramos)才开【无端宕机】维修工单，这样可以大量地减小误报，减小服务台同窗负担。
 ●   无盘中的压测能够彻底消除当前版本的kernel或软件的影响，真实地判断出硬件是否存在性能问题。

b. 影响面判断/影响升级

 ●   对于带应用的维修，咱们也会进行进程是否D住的判断。若是存在进程D住时间超过10分钟，咱们认为这个硬盘故障的影响面已扩大到了整机，须要进行重启消除影响。
 ●   在重启的时候若是出现了没法启动的状况，也无需进行人工干预，直接进行影响升级，【带应用维修流程】直接升级成【无应用维修流程】。

c. 未知问题自动化兜底

 ●   在运行过程当中，会出现一些机器宕机后能够进无盘，但压测也没法发现任何硬件问题，这个时候就只能让机器再进行一次装机，有小部分的机器确实在装机过程当中，发现了硬件问题继而被修复了。

d. 宕机分析

 ●   整个流程巧妙的设计，使得咱们在处理硬件故障的时候，同时具有了宕机分析的能力。
 ●   不过整机流程还以解决问题为主导向，宕机分析只是副产品。
 ●   同时，咱们也自动引入了集团的宕机诊断结果进行分析，达到了1+1>2的效果。

3.2.流程统计分析

若是是一样的硬件问题反复触发自愈，那么在流程工单的统计，可以发现问题。例如联想RD640的虚拟串口问题，在还未定位出根因前，咱们就经过统计发现了：同个机型的机器存在反复宕机自愈的状况，即便机器重装以后，问题也仍是会出现。接下来咱们就隔离了这批机器，保障集群稳定的同时，为调查争取时间。

3.3.业务关联误区

事实上，有了上面这套完整的自愈体系以后，某些业务上/kernel上/软件上须要处理的问题，也能够进入这个自愈体系，而后走未知问题这个分支。其实硬件自愈解决业务问题，有点饮鸩止渴，容易使愈来愈多还没想清楚的问题，尝试经过这种方式来解决兜底。

当前咱们逐步地移除对于非硬件问题的处理，回归面向硬件自愈的场景（面向软件的通用自愈也有系统在承载，这类场景与业务的耦合性较大，没法面向集团通用化），这样也更利于软硬件问题分类和未知问题发现。

4.架构演进

4.1.云化

最第一版本的自愈架构是在每一个集群的控制机上实现，由于一开始时候运维同窗也是在控制机上处理各类问题。但随着自动化地不断深刻，发现这样的架构严重阻碍了数据的开放。因而咱们采用中心化架构进行了一次重构，但中心化架构又会遇到海量数据的处理问题，单纯几个服务端根本处理不过来。

所以咱们对系统进一步进行分布式服务化的重构，以支撑海量业务场景，将架构中的各个模块进行拆解，引入了 阿里云日志服务(sls)/阿里云流计算(blink)/阿里云分析数据库(ads) 三大神器，将各个采集分析任务由云产品分担，服务端只留最核心的硬件故障分析和决策功能。

下面是DAM1与DAM3的架构对比

4.2.数据化

随着自愈体系的不断深刻，各阶段的数据也有了稳定的产出，针对这些数据的更高维分析，能让咱们发现更多有价值且明确的信息。同时，咱们也将高维的分析结果进行降维，采用健康分给每台机器打标。经过健康分，运维的同窗能够快速知晓单台机器、某个机柜、某个集群的硬件状况。

4.3.服务化

基于对全链路数据的掌控，咱们将整个故障自愈体系，做为一个硬件全生命周期标准化服务，提供给不一样的产品线。基于对决策的充分抽象，自愈体系提供各种感知阈值，支持不一样产品线的定制，造成适合个性化的全生命周期服务。

5.故障自愈闭环体系

在AIOps的感知、决策、执行闭环体系中，软件/硬件的故障自愈是最多见的应用场景，行业中你们也都选择故障自愈做为首个AIOps落地点。在咱们看来，提供一套通用的故障自愈闭环体系是实现AIOps、乃至NoOps（无人值守运维）的基石，应对海量系统运维，智能自愈闭环体系尤其重要。

5.1.必要性

在一个复杂的分布式系统中，各类架构间不可避免地会出现运行上的冲突，而这些冲突的本质就在于信息不对称。而信息不对称的缘由是，每种分布式软件架构在设计都是内敛闭环的。如今，经过各类机制各类运维工具，能够抹平这些冲突，然而这种方式就像是在打补丁，伴随着架构的不断升级，补丁彷佛一直都打不完，并且越打越多。所以，咱们有必要将这个行为抽象成自愈这样一个行为，在架构层面显式地声明这个行为，让各软件参与到自愈的整个流程中，将本来的冲突经过这种方式转化为协同。

当前咱们围绕运维场景中最大的冲突点：硬件与软件冲突，进行架构和产品设计，经过自愈的方式提高复杂的分布式系统的总体鲁棒性。

5.2.普适性

透过大量机器的硬件自愈轮转，咱们发现：

 ●   被归入自愈体系的运维工具的反作用逐渐下降（因为大量地使用运维工具，运维工具中的操做逐渐趋于精细化）。
 ●   被归入自愈体系的人工运维行为也逐渐变成了自动化。
 ●   每种运维动做都有了稳定的SLA承诺时间，再也不是随时可能运行报错的运维脚本。

所以，自愈其实是在复杂的分布式系统上，将运维自动化进行充分抽象后，再构筑一层闭环的架构，使得架构生态造成更大的协调统一。

原文连接