阿里妹导读:随着阿里大数据产品业务的增长,服务器数量不断增多,IT 运维压力也成比例增大。各种软、硬件故障而造成的业务中断,成为稳定性影响的重要因素之一。本文详细解读阿里如何实现硬件故障预测、服务器自动下线、服务自愈以及集群的自平衡重建,真正在影响业务之前实现硬件故障自动闭环策略,对于常见的硬件故障无需人工干预即可自动闭环解决。
对于承载阿里巴巴集团 95% 数据存储及计算的离线计算平台 MaxCompute,随着业务增长,服务器规模已达到数十万台,而离线作业的特性导致硬件故障不容易在软件层面被发现,同时集团统一的硬件报障阈值常常会遗漏一些对应用有影响的硬件故障,对于每一起漏报,都对集群的稳定性构成极大的挑战。
针对挑战,我们面对两个问题:硬件故障的及时发现与故障机的业务迁移。下面我们会围绕这两个问题进行分析,并详细介绍落地的自动化硬件自愈平台——DAM。在介绍之前我们先了解下飞天操作系统的应用管理体系——天基(Tianji)。
MaxCompute 是构建在阿里数据中心操作系统——飞天(Apsara)之上,飞天的所有应用均由天基管理。天基是一套自动化数据中心管理系统,管理数据中心中的硬件生命周期与各类静态资源(程序、配置、操作系统镜像、数据等)。而我们的硬件自愈体系正是与天基紧密结合,利用天基的 Healing 机制构建面向复杂业务的硬件故障发现、自愈维修闭环体系。
透过天基,我们可以将各种物理机的指令(重启、重装、维修)下发,天基会将其翻译给这台物理机上每个应用,由应用根据自身业务特性及自愈场景决策如何响应指令。
我们所关注的硬件问题主要包含:硬盘、内存、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。
总结下来,在整条报错链路中,只观察一个阶段是不够的,需要多个阶段综合分析来证明硬件问题。由于我们可以严格证明媒介故障,我们也可以反向推导,当存在未知问题的时候能迅速地区分出是软件还是硬件问题。
上述的工具是结合运维经验和故障场景沉淀出来,同时我们也深知单纯的一个发现源是远远不够的,因此我们也引入了其他的硬件故障发现源,将多种检查手段结合到一起来最终确诊硬件故障。