如果要在生产上来一次真实的整机房宕机,你会怎么做?

涂成义 陈跃泉 2020-03-19 10:59:20
​作者介绍

涂成义,苏宁科技集团CTO办公室技术架构部高级架构师,曾在华为,中兴等多家IT公司任职架构设计,技术负责人。目前专注于云计算相关技术研究,对高并发,高可用架构有较深入的理解和思考,多活多数据中心项目核心成员,主导混沌工程系统的设计和开发。

陈跃泉,苏宁科技集团CTO办公室技术架构部负责人,架构总监,苏宁多活多数据中心项目首席架构师,拥有15年零售、电信、金融超大型或大型项目经验,擅长于大规模分布式系统PaaS和IaaS架构设计。

 

随着苏宁多机房的成功部署,流量分流大大缓解了主机房的流量压力。但是主机房存在规划不合理,硬件设备老化,基础设施不完善等因素,短期内还无法彻底的解决,这些“达摩克利斯之剑”一直悬在苏宁 IT 人的心头。

 

如果主机房出现宕机,我们能否将流量整体切到备用机房?能否快速恢复业务?没人给出肯定的答复,因为谁也没实践过。

 

既然大家都没有实践过,那最好的方式就是在生产上来一次真实的机房宕机。经过技术调研和评估,我们选择了混沌工程,它通过系统性实验形式,实现整机房宕机演练。

 

什么是混沌工程?

 

我们先来了解下什么是混沌工程,混沌工程最早是由 Netflix 在《chaos engineering》中提出的,属于一门新兴的技术学科。

 

按照 Netflix 的定义,混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。

 

我们把它与我们熟知的故障注入测试做个对比,首先它们有着很多的重叠性,它们都是通过制造某种”故障”,来测试系统的反馈;其次,它们也有着明显的区别。

 

1)实施形式:故障注入测试是属于测试领域的范畴,主要针对的是一种场景的一种特定方法。

 

混沌工程是一门实验学科,可以采用多种方式探索复制系统的不良行为,是一种系统性实践。

 

2)实施方法:故障注入测试,主要还是针对错误或者故障,比如接口不通,通讯超时等破坏性行为。

 

而对于资源抢占,流量激增,拜占庭失败这些严格意义上无法称之为错误的不良行为,就无能为力了。混沌工程正是对这些弱错误或者影响层面的探索非常感兴趣。

 

3)实施结果:故障测试可以对结果进行断言,给定特定条件,系统将发出特定输出。

 

测试通常是二进制态的,并确定属性是真还是假,它不会产生关于系统的新知识,只是将效价分配给它的已知属性。

 

而混沌工程,对结果不可以预知,通过实验产生新的知识,混沌工程是一种实验形式,可以探索关于系统的新知识。

 

这也是混沌工程作为一门实验学科的重要使命。简而言之,混沌工程就一门探索新知识的实验学科。

 

为什么是混沌工程?

 

整机房宕机实践活动具有以下的特征:

 

  • 系统性,包括网络,主机,进程等,是涉及基础设施和应用系统层面综合性实验工程。

  • 不可预知性,其过程中发现的部分问题是不可预知的。

  • 有序性,过程一定是有序可控的,是生产演练的基本要求。

 

这些活动特征与混沌工程理念高度匹配,这就是我们选择混沌工程的主要原因,通过设计并且进行混沌实验,了解到系统脆弱的一面,在还没出现对用户造成伤害之前,我们就能主动发现这些问题。

 

按照混沌工程的原则,它的实施是有前提条件的,结合实施条件和苏宁的现状,我们对以下试验的条件进行评估:

 

  • 系统弹性能力是否满足,健壮性是否达到要求。

  • 系统的监控能力是否满足,各层级的监控指标是否全面覆盖。

  • 应急措施和方案是否满足,一旦出现不可预知的场景,能否快速的应急和回退。

 

近些年,苏宁的线上流量每年成倍数级的增长,IT 基础设施的不断完善,在生产实践中逐步具备这些能力。抛开苏宁电商的业务特色,这些实施标准是具有通用性的。

 

混沌工程的实施原则

 

混沌工程并不意味是”混乱”,它的实施过程涉及到系统,设施,场景,人员等各方面资源,必须是有原则,有序的,才能组织和协调各方资源来实现最终的目的。

 

它的实施原则有:

 

1)一个目标,即实施整机房宕机。混沌工程作为新兴领域学科,包含的场景和内容非常丰富,我们需要结合目标进行取舍。方案和实施都必须围绕目标,避免过度设计。

 

2)最小爆炸半径。生产试验过程中,必不可少的会对线上系统造成影响,造成用户投诉,最小爆炸半径就是结合方案和目标,减少对用户的影响。

 

图1 爆炸半径影响范围

 

爆炸半径越小,越容易得到控制,但是暴露问题会较少;爆炸半径越大,影响就越大,暴露的问题会更多,爆炸半径的选择与各阶段的目标以及实施能力是相匹配的。

 

3)循序渐进,分解目标。围绕最终目标,进行目标分解,由简入繁,由小到大。

 

图2 实施目标分解

 

该过程既能积累经验,又能给予团队以信心,信心非常重要:

 

  • 单系统应用节点,单个系统的应用层,如 Jboss,Tomcat 节点故障。

  • 单系统分库节点,单个系统的数据层分库,如 Redis,MySQL 的分库节点故障。

  • 单个系统的全库节点,单个系统的数据层全库,如 Redis,MySQL 的全库节点故障。

  • 组件节点,主要是指 Paas 的能力节点,如网关,消息分发,服务注册等节点故障。

  • 控制节点,是指集群控制节点,如 etcd,Zookeeper,Sentinel 等故障。

  • 接入/汇聚/核心网,是指接入/汇聚/核心网断网故障。

  • 物理机/机柜断电,是指某台物理机或者某台机柜断电故障。

  • DCI 网络,是指 DCI(Data Center Interconnection)网络故障。

  • 机房断电,是指整个机房断电。

 

将以上各目标组合,形成以下阶段性目标:

 

  • 单系统故障,是指某个应用系统故障,是单系统应用和全局故障的组合。

  • 全链路故障,是所有系统故障组合。

  • 机房内基础设施故障,是接入/汇聚/核心网络以及设备断电故障组合。

  • 整机房基础设施故障,是指 DCI 故障以及机房断电组合。

  • 整机房故障,是指所有故障的整合。

 

通过各个阶段故障的组合,最终达到整机房的目的。

 

混沌工程平台实现

 

“工欲善其事,必先利其器”, 结合我们的目标和实施原则,研发一套混沌工程平台。

 

Netflix 在《chaos engineering》中提出可以进行以下的试验输入:

 

  • 模拟整个 IDC 宕掉

  • 选择一部分网络连接注入特定时间的延迟

  • 随机让一些函数抛出异常

  • 强制 NTP 时间不同步

  • 生成 IO 错误

  • 榨干 CPU

 

对于系统级别的故障注入,初期并不是直接 Kill 应用进程,而是通过屏蔽虚机源目通讯端口,中断 TCP 连接,这样既能达到造成系统不可能的目的,又能最大程度确保系统快速恢复。

 

对于断电,目前还是靠人工操作。当前阶段混沌工程仅涉及全链路级别故障。

 

1、功能架构
 

 

图3 平台功能架构

 

混沌系统的功能架构分三层,自下而上包括:

 

  • 能力层,提供各种故障注入指令库,包括网络,存储,虚机,应用等。

  • 功能层,主要是平台的各种功能,其中最主要是指令管理,以及任务管理。指令管理是维护相关指令信息和脚本。任务管理是维护相关的任务信息,包括单系统以及全链路,任务是各动作的有序集合。

  • 编排层,主要针对系统运维人员,通过一系列的配置,编排动作,单系统任务,全链路任务,指定执行的依赖关系和顺序,使整个执行过程有序可控。

 

2、故障注入流程
 

 

图4 故障注入流程

 

故障注入流程如下:

 

  • 任务编排,混沌工程平台编排注入指令任务,并从平台数据系统获取目标虚机数据。

  • 下发故障注入指令,启动故障注入任务后,下发相关指令到目标虚机。混沌平台需要和各网络区打通。

  • 具有以下特点:安全管控,对身份和指令进行验证,确保任务执行安全;分布式部署,承担并发压力,整机房系统所涉及到的虚机数有 10万+ 台,需要并发执行,以减少故障注入时间,降低业务影响。

  • 故障注入执行,每台虚机上部署 Agent,收到指令后负责具体的注入操作。

  • 告警检测,虚机注入故障后,监控系统会探测到告警信息。

  • 流量切换,根据告警机器,告警类型,告警级别触发流量的切换,当前阶段是否需要进行流量切换,还需要人工决策。

 

3、故障恢复流程
 

 

故障注入后,需要进行恢复操作,其流程与注入类似。即下发恢复指令到 Agent,清除之前的故障指令。需要注意的是, Agent 的通讯端口作为白名单处理,否则注入后会导致混沌工程系统集群无法连接到虚机。

 

4、自愈功能
 

 

故障注入后,为防止某种原因导致网络不通,恢复指令无法下达到虚机,导致业务无法恢复,所以需要有自愈功能,在一段时间(自定义)没有收到新的指令,那么 Agent 将自动执行其对应的恢复指令。

 

总结

 

混沌工程平台上线以来,模拟各类异常场景,进行生产上各层次的流量切换演练,发现了多个关键性问题,为最终的整机房宕机演练成功以及机房稳定性夯实了基础。

 

混沌工程作为一门领域学科,包含的内容非常丰富。由于项目的紧迫性以及资源的限制,苏宁的混沌工程现阶段还是围绕整机房宕机演练这个目标而开展的。

 

在此基础上,后续我们将逐步拓展,包括故障注入的场景覆盖,自动化运行,流量切换和应急联动等,整体提升苏宁云的灾备能力。

 

作者丨涂成义 陈跃泉
来源丨51CTO技术栈(ID:blog51cto)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

 


 

宕机作为一种难寻逻辑的玄学,成为了运维人最害怕听到的两个字。但随着人工智能的兴起,运维也迎来了新的契机,想破解运维转型困局,让Gdevops全球敏捷运维峰会北京站给你新思路:

 

  • 《浙江移动AIOps实践》浙江移动云计算中心NOC及AIOps负责人 潘宇虹

  • 《数据智能时代:构建能力开放的运营商大数据DataOps体系》中国联通大数据基础平台负责人/资深架构师 尹正军

  • 《云时代下,传统行业的运维转型,如何破局?》新炬网络董事/副总经理 程永新

  • 《银行日志监控系统优化手记》中国银行DevOps负责人 付大亮和中国银行 高级软件工程师 李晓宁

  • 《民生银行智能运维平台实践之路》民生银行智能运维平台负责人/应用运维专家 张舒伟

  • 《建设敏捷型消费金融中台及云原生下的DevOps实践》中邮消费金融总经理助理 李远鑫

 
让我们在新技术的冲击下站稳脚跟,攀登运维高峰!那么2020年9月11日,我们在北京不见不散。
最新评论
访客 2020年04月05日

牛逼学到了

访客 2020年04月01日

阅读原文

访客 2020年03月26日

你好,可以请教一下多环境隔离的问题吗? 谢谢

访客 2020年03月10日

写的挺好的。 小工具能分享下吗

访客 2020年02月27日

文章写的太棒了,很细致,赞一个!

活动预告