Skip to main content
 首页 » 运维干货

5分钟一键切换!基于多云的站点同城容灾建设和故障演练实践


作者简介

吴佳兴,恺英网络技术中心资深运维研发工程师。

曾就职于携程旅行网、哔哩哔哩弹幕视频网,目前在恺英网络担任资深运维研发工程师,也是 CNCF 多个项目的 contributor,目前专注于 IT 基础设施和研发效能提升

很高兴为大家带来一次线上的技术分享,我这次演讲的主题是基于多云的站点同城容灾建设和故障演练实践。

先简单介绍一下恺英网络,恺英网络是国内知名的互联网游戏上市公司,旗下的上海恺英、浙江盛和浙江九翎先后开发并运营了多款热门游戏,然后旗下的XY游戏平台是国内知名的精品网页游戏运营平台。我们这次演讲主题也即是运维同学怎么去运维XY平台的平台服务,然后保障稳定性和可用性的过程。

屏幕快照 2020-09-03 下午4.32.31.png

这是本次演讲的内容提要,分为四大块:

第一,首先介绍一下项目背景,为什么做这件事情。
第二,怎么通过一个同城容灾的项目,通过机房架构跟站点架构的一个大规模的改造,实现站点的同城容灾。
第三,怎么通过一个故障演练手段去验证,进一步优化可用性。
第四,故障自愈+混沌工程的方向。

背景

屏幕快照 2020-09-03 下午4.35.08.png

首先介绍一下项目背景,在这之前我想先简单介绍一下什么是高可用,我想运维同学应该对这个概念并不陌生。高可用指的是系统能够无中断的执行其功能的能力,代表系统可用性程度。

这里有一个公式:

image.png

其中 A 是可用性,MTBF 是平均故障间隔,MTTR 是平均修复时间。可以看到,如果想要使一个系统可用性程度更高,那可以降低故障的发生频率,也可以缩短故障的持续时间。业内其实也有一个通俗说法,比如说 99.9%、99.99%,99.99% 已经算是比较高的一个程度。

这里是我个人对于站点高可用建设的几个维度的思考。

屏幕快照 2020-09-03 下午4.35.45.png

第一、鸡蛋不能放在一个篮子里。比如一个站点是托管到自建机房还是单个公有云都是不可靠的。无论是公有云还是自建机房都有故障的风险。使用公有云或单个自建机房,又没有备选方案和冗余方案,那很容易被绑架。我们知道公有云或者自建机房肯定是会有故障的风险,未来必然是一个多云或者是混合云的冗余架构。

第二、消除单点故障。 这个我相信运维同学都不陌生,比如服务架构,服务部署要求双副本或多副本,包括DB、SLB这些都需要消除单点故障。
第三、提高关键节点的健壮性。这个关键节点我认为是站点架构里的核心交错点,比如网络、DB、SLB,如果这些关键节点能够提高健壮性,相对来说站点可用性是一个很大的提升。

第四、故障发生之后的快速恢复,这个我觉得可能大家很多时候对这块比较忽视,一个故障发生之后我们有没有对应的预案很快地去恢复,是不是可以通过降级、容灾、熔断的方式恢复服务,这也是一个很重要的维度。

屏幕快照 2020-09-03 下午4.38.39.png

上面是恺英网络2018年至今的可用性数据。可以看到 2018年不太理想,P0级别的事件发生多起,持续时间2000多分钟,可用性掉到99%。2019年-2020年都保证在99.9%,目前在往99.99%冲刺的阶段。
为什么2018年故障这么频繁?可以从机房架构跟站点架构来思考下,XY平台当时部署在腾讯云广东机房,上海这边部署的是其他的核心服务,腾讯云和华为云中间有专线打通,一旦专线出现故障,腾讯云和华为云都不会成为责任方。

屏幕快照 2020-09-03 下午4.39.09.png

XY平台当时是腾讯云四层到七层,再到中山机房七层,再到后端DB的这样一个结构。其实我们遇到很多次故障,比如中山机房断电,网络炸了或者后端服务、DB挂了等等,一系列情况都是很被动的情况,除了中山机房,我们没有备选机房。另外一个情况,从腾讯云到中山机房是否健壮?能不能切走,也是一个问号。

诸如这些故障和痛点,确实不太好看,老板层面也有很大压力,促使我们做下一件事,就是同城容灾。

同城容灾(DR)

屏幕快照 2020-09-03 下午4.51.14.png

接下来从2018年开始做的事情,主要是同城容灾,相当于这套架构给改造掉,提高它的稳定性。这套方案称之为同城容灾也就是DR项目,为什么不做成多活模式?这个我们是有讨论过的,发现多活需要投入的精力很多,而且技术投入很大,比如说后端服务要做相应的改造,数据库层面可能需要一些中间件的支持,这个对我们来说是一个投入产出比没有那么高的情况,所以我们选择是一个更为适合我们的DR的方案。

这是我们当前的一个机房架构,可以看到从最开始的一个单机房,多云之间用单线直连,到现在引入 pop 点,office先连到 pop点,这个 pop 点连到云上。这样有什么好处呢?之前专线如果挂掉,没有责任方也没有冗余,现在 pop 点首先有冗余,然后 pop 点的一根专线挂掉也不会造成故障。
另外一块我们对机房架构做了一定的标准化,分为核心机房和边缘机房。核心机房有华为云和腾讯云打通,核心机房和边缘机房通过 VPC0 连到对应的内部网络。
为什么这样设计?我们在边缘部署一些单个的游戏服务,大家知道游戏特点快速迭代、快速验证的方式,如果投入产出比不理想,我们会快速卸掉,在这个过程中我们不希望对核心机房造成一些变动,所以会部署到边缘机房。
这样一个结构对于我们是足够冗余的多云结构,鸡蛋没有放到一个篮子里。
随着我们机房结构变迁,站点架构也做了一些改造。以XY平台为例,之前是腾讯云广州到中山机房的线路,中山机房是很大一块问题,其次有很多单点跟故障风险点。这些风险点在改造之后,首先演变成一个多云的冗余机构,每套云上面都有完整XY平台服务。DB的话,变成一个多主多从的数据库方案。

如果遇到各种故障,比如机房挂了,可以通过 DNS 直接切换到华为云上,如果是服务挂了,通过一个自建的SLB可以将后端自主切换到对应另外一套机房的后端,所以这里其实有一定的冗余和灾备的。

屏幕快照 2020-09-03 下午4.54.09.png

我们发现也会有一些痛点。
  • 第一、手工操作。在发生故障的时候切换步骤非常多,切换执行下来会花费很多时间;
  • 第二、工具可用性。发生故障的时候工具不一定就绪,比如说发生故障我们想用SLB平台,管理SLB的工具,想用SLB平台做切换的时候,我们发现这个工具也出问题了,也切不动了,这个时候很被动了,我们只有联系对应的工具开发去找问题,我们手动去配置和修改;

  • 第三、可监察性。故障发生时需要通过监控告警手段去验证服务可用性。这里分为两点,第一点我们需要通过监控告警发现站点挂了,第二在故障发生之后切换了,怎样去验证切换是否OK呢?也是通过监控告警的手段。

  • 第四、伪双活。真正要切换到备用服务器时,好像不是100%可用,这个相信大家可以理解。比如研发或运维做变更或代码发布,优先面向主,备有时候会很忽略,代码有没有更新?配置没有更新或是有些服务没有起,这些都是问题。

练兵:故障演练

标准运维

那这些问题促使我们做下一个阶段的事情,也就是所谓故障演练,一个实际练兵的过程。我们前面做了架构改造,能不能验证,能不能进一步优化,我们就启用这样故障演练的手段。

以XY平台为例,架构是CNAME 域名指向四层再到七层,然后到后端再到DB,这里有两种方案,一种是DNS直接切换,第二种是后端解析过去。因为XY平台是一个核心服务,有依赖于第三方服务,例如微信和支付宝,如果单纯做DNS切换是会影响到客户的,如果主挂了,切DNS到备,主这边的服务还有人访问。

我们希望除了DNS之外,后端也能切换到备用的服务。这样的话,主跟备对应的 SLB 都起到了作用,大家访问的都是可用的那套服务。

这里需要调度的人员其实挺多的,每次演练都需要跨部门的协调。

屏幕快照 2020-09-03 下午4.55.35.png

这是一个故障演练的实际情况。可以看到分9大块,上图就是实际的一个步骤,这中间也依赖于监控告警,比如在模拟故障时,验证是否真正故障,DB停掉是否有告警?这样模拟效果达到了。

下方的图,访问量和 Nginx 处理量可以知道,故障之后访问量降低了,这也是可以验证切换是否成功了,服务的访问量回去了。

屏幕快照 2020-09-03 下午4.56.55.png

这是故障演练步骤。这是标准运维这个阶段,还是一个相对手工的阶段,即便是运维人员操作的时候是通过工具切换,但是其实这些步骤是手工操作步骤,其实是需要人去操作的,这里可以看到大概是花费了16分钟的时间,其实大部分都是SLB和数据库方面的切换,所操作花的时间。

屏幕快照 2020-09-03 下午4.57.25.png

这是我们这次故障演练时发生的一些问题,可以看到真正去做这件事情的时候,你会发现没有你想象的那么美好,你会发现有很多莫名其妙的问题冒出来。
比如主从复制,数据不一致,IE浏览器访问、SLB等等。这必须是终端访问才会爆出来的问题。XP 系统 IE 浏览器访问发现 HTTPS 异常,只有真正做的这个故障演练,真正终端用户访问的时候才会出现这样的问题,所以这些问题是只有真正演练才会发现的问题。

工具多活

屏幕快照 2020-09-03 下午4.57.58.png

我们刚说了标准运维的故障演练的阶段,这里其实还牵扯到一个阶段,我们在演练的时候工具挂了怎么办?这其实是一个很大的问题,怎样保障需要做切换的时候工具是可用的,这是一个大前提,这里我们就发起了第二阶段的演练过程,所谓的工具多活的改造。

工具能不能做成多活?首先这是一个前提和问题,那么其实是可以的,答案是肯定的,我们只需要把运维工具数据库置为双写,两边机房双写,因为工具场景是一个写频率比较低,写入口相对来说是可以控制的,因为操作人员就这些,可能是研发甚至只有运维同学来做,所以这些数据被脏写的风险很小,其实我们是可以通过数据库做成多活的模式,双写的模式来做成多活的。

屏幕快照 2020-09-03 下午4.58.32.png

这里是我们实际工具多活演练过程当中发生的一些问题,主要的问题还是工具跟工具之前其实是有依赖的,那么这个依赖是需要解开的。比如说当时发现 DB 切换是依赖 Workflow 工作流任务系统,工作流DB又是依赖DB,DB是只读的切不了,所以就发生这种问题。还有比如说代码不一致、服务的问题、监控问题这些都是问题,通过演练把这些问题发现解决掉。

一键切换

屏幕快照 2020-09-03 下午5.04.06.png

这里可以理解为 Ansible 里的 playbook,搭配自定义参数里的 vars 变量组合起来,指定一个策略,可以一键切换。

下面是一个截图可以看到演练方案,然后是一个双机房后面是切换策略,从A机房切换到B机房,运维同学点切换按钮,点确认就可以自动化,一键式切换。这个是16个步骤,从检查工具系统是否可用,到维护,切换DB主从,包括后面切机房,DNS解析,其实运维只需要去看有没有什么问题,出问题去恢复,如果一套下来没有问题,那么减轻了运维同学很多的负担,所以是一键式切换平台带来的好处。

屏幕快照 2020-09-03 下午5.04.47.png

左边是一个变量,右边是执行的步骤。

屏幕快照 2020-09-03 下午5.05.18.png

通过这样一个一键切换工具平台,真正实现了站点能够在大约在5分钟内完成一键切换。

常态化演练

第四个阶段常态化演练,因为我们知道一个站点服务毕竟是一个不断演进,不断迭代的过程,包括代码也好服务架构、负载均衡配置也好,这些东西都是一个不断演进的过程,如果要保证这套流程不被腐化,那么一定需要常态化演练,定期要做的事情,稳步推进可靠性站点建设。定期要验证这个方案到底还能不能去做切换,所以这个是常态化演练的阶段,而且通过这样的手段,可以进一步一直往前走。

回顾一下

然后我们回顾一下刚才提到的一些高可用建设的方面,包括痛点。

  • 第一、鸡蛋不放一个篮子里面,我们通过多云多机房的方案做一个冗余。

  • 第二、消除单点故障,我们是把ELB、SLB、后端服务、DB这些层的单点故障给消除掉。

  • 第三、关键节点的健壮性,这里是通过多云多线路+DR的手段提高健壮性。

  • 第四、故障之后快速恢复。这里是制定标准运维流程,通过故障演练去验证,一键切换加速了故障的恢复。

这里一些痛点,

  • 手工操作,通过一键切换来解决;
  • 工具可用性,通过工具改造成多活来解决;
  • 可监察性。我们是通过监控告警的手段来验证。这里还要回答一个问题,在故障发生时监控本身能不能保障高可用?现在虽然是做到了,但是还是有一些问题,监控系统其实还有一些依赖,比如服务树。一旦这些服务挂掉,我们会有一个兜底。如果是服务树挂了会有缓存,告警联系人从服务树获取,现在的方案可以写死一批名单;如果服务树也访问不通,告警再发给特定人员。这块还有一段路要走,这方面还没有实现真正的多活和高可用;
  • 伪双活,我们是通过常态化故障演练来验证。

未来

未来是希望站点故障自愈+混沌工程的方法。这其实大家也可以理解,因为故障是不可预料的,今天可能会是SSO挂了,机房断电了弄UPS,比如说WAF炸了,我们遇到过的,当时的办法是登机器改配置,导致站点可用性进一步降低了。
这些不可预知的问题怎么解决呢?我们想通过混沌工程的方式去验证、发现,进而不断迭代。这也是我们未来的一个方向,大家有兴趣可以多多交流。
这里就是我今天分享的所有内容,谢谢大家。

9月25日,GOPS全球运维大会 2020 · 深圳站,近80位演讲大咖,18个名企专场组团来袭~中行、腾讯、阿里、京东、招行、广东移动、神州泰岳,哪个是你的菜?

专场一览⬇️

专场图0824.jpeg

精彩议题 ⬇️

近期好文:

从 MySQL 到 ClickHouse 实时复制与实现

关于 Kubernetes 的这些原理,你一定要了解

“高效运维”公众号诚邀广大技术人员投稿,
投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118.


评论列表暂无评论
发表评论
新浪微博
微信
公司电话:
13910952502