谈谈这次阿里云香港可用区C故障

阿里云在上周日(2022-12-18)发生了发生了香港region的可用区C的大规模故障,阿里云自己在也微信公共账号贴出了处理过程,服务影响,问题分析和改进措施。(《关于阿里云香港Region可用区C服务中断事件的说明》

我使用阿里云不算多也不算少,2000个不到的实例,rds的mysql、pg、sqlserver,dts的同步、迁移也都在用。我觉得阿里云最大的问题,不是在假的status页面,也不是降温处理慢导致消防喷淋,而是阿里云的可用区建设,根本就是一坨屎。(其实如果可用区设计的好,单可用区故障那都不叫事)

rds的高可用区选择,乱成一团麻。可以选择(1)单可用区的高可用部署;(2)多可用区指定主可用区+指定备可用区部署;(3)多可用区指定主可用区+自动选择备可用区部署;而且这些标准,是因地而异,比如杭州的多可用区是“多可用区部署+备用节点可用区自动选择”,而法兰克福的多可用区是“多可用1(可用区A+可用区B)。

同样的rds购买菜单下,不同类型的rds,能选择的可用区数量不一样。比如买mysql高可用版时,可以选择的可用区是可用区F、可用区D、可用区E(我他妈也不知道为什么是这个排序),买pg高可用版的时候,可以选择的可用区是可用区F、可用区E。

同样rds购买菜单下,哪怕是同一种类的rds,比如mysql,不同的版本,选择的可用区也是不一样。比如我选择买mysql 8.0高可用版,可以选择的可用区是:可用区F、可用区D、可用区E, 如果我选择买mysql 5.6高可用版时,可以选择的可用区是可用区F、可用区D、可用区E、可用区A、可用区B。

可用区的淘汰和下线,也是跟薛定谔的猫一样,虽然是从字母ABCD开始排起来,但是你完全不知道,当前哪个可用区已经没资源了,比如我需要128c的资源,我要去看看可用区A有没有,可用区B有没有…… ;我terraform已经写好了程序,自动部署到可用区B,可是过几天,terraform就部署失败了,一问,原来是可用区B的资源已经耗尽了,而且因为可用区B比较老,阿里云不会再补充新资源。

可用区的新建,也是个薛定谔的猫。当前已经新建可用区,到哪个字母了? 可用区H? 可用区I? 可用区J?阿里云从来不会主动通知。我在terraform中怎么去添加新可用区。因为新可用区不确定,所以terraform的基础设施即代码的思想,也不得不被迫变成了一个笑话。

不同的region,可用区建设不一样,有些region比如孟买,pg15只有可用区B,那么就算是高可用部署,也只能2个实例都在同一可用区。再比如杭州有6个可用区,深圳是4个可用区。

在阿里云的自己的故障报告中,也提到了:“由于大量可用区C的客户在香港其他可用区新购实例,同时可用区C的ECS实例拉起恢复动作引入的流量,导致可用区 B 管控服务资源不足。” —— 如果一开始客户就是选择多可用区部署的,那么可用区B的资源就应该是预留的。不应该导致可用区B的资源不足。如果是客户大量新建的,那么应该是在客户的新建订购页面报错,直接拒绝了,而不应该影响到可用区B的管控服务。

另外,阿里云可用区C挂了,为啥某些依赖的对象是在可用区B? 在可用区C挂掉的时候,我们检查了所有的rds的连通性,发现有4台多可用区部署,可用区B+C的rds,是无法访问的。—— 受代理服务影响? 抱歉,我们的rds都没开代理服务,为什么不能访问了? 所幸的是,4台是非核心业务数据库,可以等。

阿里云的多可用区,不仅仅收到物理资源的限制,还有一个问题。就是IP的问题,rds需要获取IP,而IP受限于虚拟交换机分配的网段。那么“备用节点可用区自动选择”这个能选到我事先约定某个可用区中,多个虚拟交换机中的某个虚拟机交换机吗?

不过话又说回来了,阿里云之所以敢这么设计可用区,虽然有很多槽点,很多风险,但是胜在价格便宜呀。

PS:aws你别笑,回头我们再来谈谈你三天两头强制升级的问题。

相关文章

一条评论

  1. 哈哈
    可用区资源的问题 说实话 前后端是分离的 前端其实也不知道后端有没有资源 只有当任务发出去之后 流程报错 前端才知道没资源 我猜测

发表回复

您的电子邮箱地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据