Su的技术博客

  • 首页
  • Java
  • MySQL
  • DDD
  • 事故复盘
  • 架构方案
  • Other
  • 工具
  • 打赏
  • 关于
  1. 首页
  2. 事故复盘
  3. 正文
                           

【悟空】阿里云香港云服务器P0史诗级宕机事件复盘

2023-02-20 71点热度 0人点赞 0条评论

 

上个周日12月18号,阿里云香港服务器发生了都不知道算 P 几事故的史诗级宕机事件,整个事件导致香港地区 C 区 ECS、OSS、EBS、RDS 等云服务大范围不可用,故障时间从 早上 8 点多一直持续到晚上 10 点多才最终恢复,整个故障时间长达 14 个小时。

比较有名的交易所平台如 Gate.io 和 OKEX 都受到大面积故障影响,我都还以为他们跑路了。

而按照本次事故的时间来计算,可用性大概是 98% 左右了,也就是说基本可以获得的赔偿是月度服务费的 25%。

昨天,阿里云官方也官宣了关于这次估计导致大范围阿里云程序员今年 325 的故障复盘说明。

处理过程

12月18日08:56,阿里云监控到香港Region可用区C机房包间通道温控告警,阿里云工程师介入应急处理,通知机房服务商进行现场排查。

09:01,阿里云监控到该机房多个包间温升告警,此时工程师排查到冷机异常。

09:09,机房服务商按应急预案对异常冷机进行4+4主备切换以及重启,但操作失败,冷水机组无法恢复正常。

09:17,依照故障处理流程,启动制冷异常应急预案,进行辅助散热和应急通风。尝试对冷机控制系统逐个进行隔离和手工恢复操作,但发现无法稳定运行,联系冷机设备供应商到现场排查。此时,由于高温原因,部分服务器开始受到影响。

自10:30开始,为避免可能出现的高温消防问题,阿里云工程师陆续对整个机房计算、存储、网络、数据库、大数据集群进行降载处理。期间,继续多次对冷机设备进行操作,但均不能保持稳定运行。

12:30,冷机设备供应商到场,在多方工程师诊断下,对冷塔、冷却水管路及冷机冷凝器进行手工补水排气操作,但系统仍然无法保持稳定运行。阿里云工程师对部分高温包间启动服务器关机操作。

14:47,冷机设备供应商对设备问题排查遇到困难,其中一个包间因高温触发了强制消防喷淋。

15:20,经冷机设备商工程师现场手工调整配置,冷机群控解锁完成并独立运行,第1台冷机恢复正常,温度开始下降。工程师随后继续通过相同方法对其他冷机进行操作。

18:55,4台冷机恢复到正常制冷量。

19:02,分批启动服务器,并持续观察温升情况。

19:47,机房温度趋于稳定。同时,阿里云工程师开始进行服务启动恢复,并进行必要的数据完整性检查。

21:36,大部分机房包间服务器陆续启动并完成检查,机房温度稳定。其中一个包间因消防喷淋启动,未进行服务器上电。因为保持数据的完整性至关重要,工程师对这个包间的服务器进行了仔细的数据安全检查,这里花费了一些必要的时间。

22:50,数据检查以及风险评估完成,最后一个包间依据安全性逐步进行供电恢复和服务器启动。

服务影响

12月18日09:23,香港Region可用区C部分ECS服务器开始出现停机,触发同可用区内宕机迁移。随着温度继续升高,受影响的服务器停机数量持续增加,客户业务开始受到影响,影响面扩大到香港可用区C的EBS、OSS、RDS等更多云服务。

阿里云香港可用区C的故障,没有直接影响客户在香港其他可用区运行的业务,但影响了香港Region ECS管控服务(Control Plane)的正常使用。

因大量可用区C的客户在香港其他可用区新购ECS实例,从12月18日14:49开始,ECS管控服务触发限流,可用性最低跌至20%。客户在使用RunInstances/CreateInstance API购买新ECS实例时,如果指定了自定义镜像,部分实例在购买成功之后会出现启动失败的现象,由于自定义镜像数据服务依赖可用区C的单AZ冗余版本的OSS服务,无法通过重试解决。

此时,部分Dataworks、k8s用户控制台操作也受到了故障影响。API完全恢复可用为当日23:11。

12月18日10:37,阿里云香港可用区C的部分存储服务OSS开始受到停机影响,此时客户暂不会感知,但持续高温会导致磁盘坏道,影响数据安全,工程师对服务器进行停机操作,从11:07至18:26中断了服务。

阿里云在香港Region可用区C提供了2种类型的OSS服务,一种是OSS本地冗余LRS服务(通常叫单AZ冗余服务),仅部署在可用区C;另一种是OSS同城冗余ZRS服务(通常叫3AZ冗余服务),部署在可用区B、C和D。在此次故障中,OSS同城冗余ZRS服务基本没有受到影响。可用区C的OSS本地冗余服务中断时间较长,因不支持跨可用区切换,需要依赖故障机房的恢复。

从18:26开始,存储服务器重新分批启动。其中,单AZ本地冗余LRS服务有部分服务器因消防问题需要做隔离处理。恢复服务前,我们必须要确保数据可靠性,花费了较多的时间进行完整性检验工作。

直至12月19日00:30,这部分OSS服务(单AZ冗余服务)才恢复了对外服务能力。

阿里云网络少量单可用区产品(如:VPN、Privatelink以及少量GA实例)在此次故障中受到影响。

12月18日11:21,工程师启动网络产品可用区容灾逃逸。

12:45完成SLB等大部分网络产品可用区容灾逃逸。

13:47NAT产品完成收尾逃逸。

除上述少量单可用区产品以外,各网络产品在故障期间保持了业务连续性,NAT有分钟级业务受损。

12月18日10:17开始,阿里云香港Region可用区C部分RDS实例出现不可用的报警。随着该可用区受故障影响的主机范围扩大,出现服务异常的实例数量随之增加,工程师启动数据库应急切换预案流程。

截至12:30,RDS MySQL与Redis、MongoDB、DTS等大部分跨可用区实例完成跨可用区切换。部分单可用区实例以及单可用区高可用实例,由于依赖单可用区的数据备份,仅少量实例实现有效迁移。少量支持跨可用区切换的RDS实例没有及时完成切换。经排查是由于这部分RDS实例依赖了部署在香港Region可用区C的代理服务,由于代理服务不可用,无法通过代理地址访问RDS实例。我们协助相关客户通过临时切换到使用RDS主实例的地址访问来进行恢复。

随着机房制冷设备恢复,21:30左右绝大部分数据库实例恢复正常。对于受故障影响的单机版实例及主备均在香港Region可用区C的高可用版实例,我们提供了克隆实例、实例迁移等临时性恢复方案,但由于底层服务资源的限制,部分实例的迁移恢复过程遇到一些异常情况,需要花费较长的时间来处理解决。

我们注意到,同时在多个可用区运行业务的客户,在这次事件中依然可以维持业务运行。对于业务需要绝对高可用的客户,我们持续建议您采用全链路多可用区的业务架构设计,以应对各种可能的意外事件。

问题分析与改进措施

1、冷机系统故障恢复时间过长

原因分析:机房冷却系统缺水进气形成气阻,影响水路循环导致4台主冷机服务异常,启动4台备冷机时因主备共用的水路循环系统气阻导致启动失败。水盘补水后,因机房冷却系统的群控逻辑,无法单台独立启动冷机,手工修改冷机配置,将冷机从群控调整为独立运行后,陆续启动冷机,影响了冷却系统的恢复时长。整个过程中,原因定位耗时3小时34分钟,补水排气耗时2小时57分钟,解锁群控逻辑启动4台冷机耗时3小时32分钟。

改进措施:全面检查机房基础设施管控系统,在监控数据采集层面,扩大覆盖度,提升精细度,提高对故障的排查和定位速度;在设施管控逻辑层面,确保系统自动切换逻辑符合预期,同时保证手工切换的准确性,防止内部状态死锁从而影响故障的恢复。

2、现场处置不及时导致触发消防喷淋

原因分析:随着机房冷却系统失效,包间温度逐渐升高,导致一机房包间温度达到临界值触发消防系统喷淋,电源柜和多列机柜进水,部分机器硬件损坏,增加了后续恢复难度和时长。

改进措施:加强机房服务商管理,梳理机房温升预案及标准化执行动作,明确温升场景下的业务侧关机和机房强制关电的预案,力求更简单有效,并通过常态化演练强化执行。

3、客户在香港地域新购ECS等管控操作失败

原因分析:ECS管控系统为B、C可用区双机房容灾,C可用区故障后由B可用区对外提供服务,由于大量可用区C的客户在香港其他可用区新购实例,同时可用区C的ECS实例拉起恢复动作引入的流量,导致可用区 B 管控服务资源不足。新扩容的ECS管控系统启动时依赖的中间件服务部署在可用区C机房,导致较长时间内无法扩容。ECS管控依赖的自定义镜像数据服务,依赖可用区C的单AZ冗余版本的OSS服务,导致客户新购实例后出现启动失败的现象。

改进措施:全网巡检,整体优化多AZ产品高可用设计,避免出现依赖OSS单AZ和中间件单AZ的问题。加强阿里云管控平面的容灾演练,进一步提升云产品高可用容灾逃逸能力。

4、故障信息发布不够及时透明

原因分析:故障发生后阿里云启动对客钉群、公告等通知手段,由于现场冷机处理进展缓慢,有效信息不够。Status Page页面信息更新不及时引发客户困惑。

改进措施:提升故障影响和客户影响的快速评估和识别拉取能力。尽快上线新版的阿里云服务健康状态页面(Status Page),提高信息发布的速度,让客户可以更便捷地了解故障事件对各类产品服务的影响。

 

本文仅供学习!所有权归属原作者。侵删!文章来源: 悟空聊架构

标签: 悟空 宕机 云服务器 阿里云 线上事故
最后更新:2023-02-20

coder

分享干货文章,学习先进经验。

打赏 点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

最新 热点 推荐
最新 热点 推荐
殷浩详解DDD 第四讲:领域层设计规范 既生@Resource,何生@Autowired? Go整洁架构实践 接口优化的常见方案实战总结 QQ音乐高可用架构体系 构建一个布隆过滤器 —— Building a Bloom filter
殷浩详解DDD 第四讲:领域层设计规范Redis为什么这么快?构建一个布隆过滤器 —— Building a Bloom filterQQ音乐高可用架构体系接口优化的常见方案实战总结Go整洁架构实践
Eureka源码剖析之四:服务续约 超实用的IDEA插件推荐!百万级下载量 【视频】NettyInAction作者:统治一切的框架Netty- One Framework to rule them all 笔记 | 面试又挂了,只因问了:TCP三次握手和四次挥手 QQ音乐高可用架构体系 仅使用set属性值就把数据库数据给改了

@Autowired (1) @Resource (1) API网关 (1) ddd (6) DP (1) ElasticSearch (1) eureka (7) go (1) HTTP (1) IDEA (1) iOS (1) Java (8) JSR (1) QQ音乐 (1) repository (1) Spring (1) SQL优化 (1) 代理 (1) 依赖注入 (1) 同城双活 (1) 垃圾回收 (1) 定时任务 (1) 容灾 (1) 布隆过滤器 (1) 异地双活 (1) 接口优化 (1) 故障转移 (1) 数据库 (2) 整洁架构 (1) 文件网关 (1) 方案 (2) 服务续约 (1) 注册中心 (7) 流水账 (1) 流量 (1) 第五 (1) 线上案例 (1) 线上问题 (2) 缓存 (1) 缓存击穿 (1) 编译 (3) 网络 (3) 聊聊 (1) 订单 (1) 设计规范 (1) 详解 (1) 连接池 (1) 限流 (1) 领域驱动设计 (4) 高可用 (1)

COPYRIGHT © 2014-2023 verysu.com . ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

粤ICP备15033072号-2