智能运维 | 单机房故障自愈,收藏这一篇就够了

时间:2024-04-10 12:07:05

智能运维 | 单机房故障自愈,收藏这一篇就够了

在《使用故障自愈机器人?运维小哥先解决这些问题》中,我们介绍了单机房故障自愈的准备工作和基础设施,包括容灾能力建设、监控平台以及流量调度平台。本篇主要介绍在百度云Noah智能运维产品体系中单机房故障自愈的具体解决方案,内容包括:单机房故障止损的能力标准、单机房故障自愈的整体架构及单机房故障自愈的常见问题和解决方案。

01

单机房故障止损的能力标准


在单机房容灾能力、故障发现能力、流量调度能力基础上,业务线具备了通过流量调度进行单机房故障止损的条件。理想情况下,我们希望构建一套完整、自动、智能的自愈方案,但各个业务线的服务特点不同和基础能力参差不齐,很难一蹴而就,所以我们建立起一套自愈能力的等级标准,业务线根据自身情况制定相应建设计划,逐步提升自愈能力。

自愈能力等级标准划分为5级,从Level 0的完全人工止损,到Level 4的自动化、智能化止损。对于Level 0、Level 1,人工感知止损面临着速度慢、误操作、场景覆盖不全、风险控制能力不足等问题;Level 2则实现了止损操作的平台化、预案化,一定程度上提升了止损效率;Level 3则实现了自动化报警联动故障止损,实现了止损效率的进一步提升。2016年,百度大部分核心产品线已经实现了Level 2、Level 3的自动止损能力,但在场景覆盖与风险控制上仍存在不足。由此,Level 4智能自愈方案应运而生。

智能运维 | 单机房故障自愈,收藏这一篇就够了

02

单机房故障自愈的架构


针对传统故障自愈方案中存在的问题,我们构建了单机房故障自愈整体解决方案。

自愈方案通过抽象、规范处理流程实现单机房故障自愈的自动化,即将止损过程划分为统一的感知、决策、执行三个阶段;同时通过运维知识库解决基础数据、基础设施差异化问题;通过策略框架支持智能化异常检测、策略编排、流量调度问题,同时支持用户自定义策略需求。实现单机房故障自愈的标准化、智能化。

智能运维 | 单机房故障自愈,收藏这一篇就够了

在单机房故障自愈--黎明之战提到的百度网络与业务架构情况,我们将整体流量调度止损架构拆分为3层:接入层、服务层、依赖层。

智能运维 | 单机房故障自愈,收藏这一篇就够了

针对这3层的监控感知、止损决策与故障止损方式的不同,将止损自动决策拆分为外网止损自动决策与内网止损自动决策。

外网止损自动决策:覆盖接入层。基于外网、内网监控信号;触发外网止损决策器进行止损决策;执行DNS流量调度止损。

内网止损自动决策:覆盖服务层、依赖层。基于内网监控、基础监控、业务监控提供的故障信号;触发内网止损决策器进行止损决策;执行流量调度、主备切换、弹性降级等止损操作。

03

单机房故障自愈的常见问题和解决方案


传统的流量调度自动止损方案存在如下问题:

1、容量风险控制能力不足

【问题描述】

传统流量调度的模式有两种:固定比例模式与容量保护模式。

智能运维 | 单机房故障自愈,收藏这一篇就够了

  • 固定比例模式:按照预先设定的固定预案,一个机房故障,该机房的流量按照预先设定的比例分配到其他的机房。很可能某个机房的容量或剩余机房的总容量不足,切流量后导致多个机房发生故障。

  • 容量保护模式:针对固定比例模式存在的容量风险问题,改进的流量调度方式为执行前判断容量是否充足,容量充足则进行流量调度,否则不进行调度并通知人工介入处理。但此种方案面对的问题是:

1. 容量仍有Buffer可以进行部分止损。期望能够在不超过容量保护的情况下进行尽可能的调度,减少对用户的影响。

2. 即使按照容量进行调度,服务过载仍可能发生,容量数据本身存在一定误差,流量成分的变化以及变更等导致的容量退化,都可能导致原先容量无法完全可信。

【解决方案】

  • 基于容量水位的动态均衡

智能运维 | 单机房故障自愈,收藏这一篇就够了

在流量调度时,对于容量不准确存在的风险,我们划分两条容量警戒线。

  • 安全水位线:流量处于在安全线以下则风险较小,可以一步进行切换。

  • 水位上限:该水位线表明服务的最大承载能力,一旦流量超过故障水位线,很大概率会导致容量过载。

如果安全水位线提供的容量不足以满足止损,那我们期望使用上两条中间的容量Buffer,同时流量调度过程中进行分步试探,避免一次性调度压垮服务。

  • 基于快速熔断的过载保护

在流量调度时,建立快速的熔断机制作为防止服务过载的最后屏障。一旦出现过载风险,则快速停止流量调度,降低次生故障发生的概率。

  • 基于降级功能的过载保护

在流量调度前,如果已经出现对应机房的容量过载情况,则动态联动对应机房的降级功能,实现故障的恢复。

2、业务线止损策略需求差异大

【问题描述】

我们实现了基础的单机房故障流量调度止损算法,但在部分业务线中仍存在较大的需求差异,比如:

  • 分步动态调度需求:业务存在充Cache的情况,过程中服务能力降低,需要控制切换速度。

  • 优先级调度需求:产品对延迟敏感,止损时需要优先切到同地域机房;业务服务于多个上游,多个上游的重要程度不同,优先保证重要上游服务稳定。

  • 容量负载计算需求:请求成分不同,不同成分请求带来的容量负载不同。

这部分需求一部分与业务强相关,不具备通用性,另一部分则存在不同产品线需求冲突的情况。

【解决方案】

针对以上问题,我们推出了故障止损流量调度策略开放框架。支持用户根据业务需求自定义策略实现。同时将较为通用的策略开放为插件,使业务线可以根据需求*插拔策略。

智能运维 | 单机房故障自愈,收藏这一篇就够了

基于以上两点,结合智能运维开发框架,单机房故障自愈框架无缝支持不同业务线,使得研发者可以更关注策略本身,而无需关注不同业务线运维模型、底层平台适配成本。同时,整体解决方案具备良好的扩展性,单机房故障自愈框架抽象出故障信号、容量数据、路由信息、调度命令等,可以通过增加不同实现的方式对接其他开源监控系统、命令执行系统,以适应不同用户场景的解决方案。

04

总结


通过单机房故障自愈系列文章,我们详细介绍了单机房故障止损的必要性、准备工作,并构建了基于容量动态分步流量调度的单机房故障自愈框架,实现自动化智能化故障止损。对整体单机房故障自愈解决方案不同阶段的改进总结如下:

智能运维 | 单机房故障自愈,收藏这一篇就够了

经实践证明,在单机房故障自愈场景下,我们的解决方案已经相对成熟,若您有兴趣进一步了解单机房故障自愈的相关问题,欢迎联系我们!

作者介绍

 运小辰 百度云高级研发工程师

负责百度云智能故障自愈方案相关设计研发工作,致力于降低单机房故障自愈风险、提高故障自愈效率,为业务可用性保驾护航。

往期

回顾


智能运维 | 百度自动化运维是怎么做的(上)——概念以及标准从何而来?

智能运维 | 百度自动化运维是怎么做的(下)——运维编年史

智能运维 | 为何说自动化运维三大要素是标准化、工程化和智能化?

智能运维 | 百度网络监控实战:NetRadar横空出世(上)

智能运维 | 百度网络监控实战:NetRadar横空出世(下)

智能运维 | 框架在手,AI我有

智能运维 | 干货分享,百度如何实现大规模分布式监控系统的高可用

智能运维 | 百亿级外网访问质量保障:百度猎鹰外网监控(上)

智能运维 | 百亿级外网访问质量保障:百度猎鹰外网监控(下)

智能运维 | 百度海量日志处理——任务调度实践与优化

智能运维 | 有了故障自愈机器人,运维小哥终于可以安心睡了

智能运维 | 使用故障自愈机器人?运维小哥先解决这些问题

智能运维 | 单机房故障自愈,收藏这一篇就够了