7.2 咱们机房断网了!怎样办
1、背景
2024 年 7 月 2 日 10:04,我站机房 A 公网物理光缆终止,造成机房 A 公网无法访问。本文将从 DCDN 架构及多活控制的视角,剖析本次缺点中咱们发现的疑问和控制优化措施。
2、止损环节
缺点出现后,SRE与网工接纳到少量专线终止、公网探测告警,极速拉起线上会议协同启动缺点定位及止损操作;
在此时期外围业务(如介绍、播放等)因在 DCDN 侧性能了源站机房级别智能容灾失效,未受影响;
首先定位到的是单个运营商线路存在少量丢包意外,优先将该运营商用户流量切向具备专线回源的 CDN 专线节点,此时这局部用户流量复原,但全体业务未齐全复原;
继续定位到整个机房 A 公网齐全无法访问,而从机房 B 外围业务场景因智能容灾失效存在流量回升且观测业务 SLO 反常,决策口头全站多活业务切流至机房 B 止损。此时多活业务成功止损,非多活业务仍有损;
继续对非多活业务流量口头升级,将用户流量切向 CDN 专线节点回源,此时非多活业务流量成功止损。
3、疑问剖析
图1:南北向流量架构图 / 0702缺点逻辑图
先繁难引见一下 B 站源站架构,从上图1可以看出,B 站在线业务有两个外围机房,每个机房都有两个互联网接入点(公网 POP ),且这两个互联网接入点散布在不同的省市。这样设计的外围理路:网络接入(以下统称为 POP )和算力中心(以下统称为机房)解耦,到达接入层缺点可容灾的成果。
同时从图2可知,为了优化自建 CDN 节点到源站外围机房的回源稳固性和效率。咱们成功了 B2-CDN 环网的设计和树立,成功了从边缘 L1 & L2 自建 CDN 节点经过该环网启动回源,丰盛了业务从边缘节点回外围源站失掉数据的路径。其实 B2-CDN 环网的设计初衷是为了给各 L1 & L2 自建CDN节点在处置边缘冷流、温流、热流时能有更多的手腕,以探求愈加适宜有 B 站业务特色的边缘网络调度形式。B2-CDN 环网底层经过二层 MPLS-VPN 技术成功各节点 Full-Mesh,并在此基础上经过三层路由协定(OSPF、BGP) 成功各节点与源站外围机房之间的互联互通。同时各业务保管经过公网回源外围机房的才干,做为 B2-CDN 环网出现极其缺点状况下的兜底回源方案。
B 站接口类恳求关键经过 DCDN 减速回到源站,DCDN 节点分为两种类型,经过公网回源的公网节点和经过专线回源的专线节点。反常状况下 DCDN 公网节点可经过双公网 POP 回到源站,DCDN 专线节点则经过内网专线回到源站。并且在 DCDN 层面,有针对源站的 Health Check 性能,会智能摘除探测意外的源站 IP。比如当 DCDN 节点恳求回源 POP A 出现意外时,会重试到 POP B。DCDN 公网节点常态可经过双 POP 交叉回源站,应答 DCDN 到某一个源站 POP 点出现丢包或终止,容灾方案智能失效,对业务简直无影响。
但是本次缺点中双 POP 至机房 A 缺点,相当于机房 A 公网脱网。不同于单 POP 缺点,惯例双 POP 之间相互容灾方案无法失效。除了几个外围业务场景因前置性能了机房级别的缺点容灾战略未受影响外,非智能容灾的多活业务须要口头机房维度切流启动止损。由于DCDN 专线节点可以经过 B2-CDN 环网专线回源不受本次缺点影响,最终成为了非多活业务的逃生通道。
回忆整个止损环节,咱们发现了以下疑问:
4、优化措施
针对本次缺点中遇到疑问,咱们从新评价了单机房缺点的预案及改良措施,可以看到多活业务全体的止损预案是分歧的,重点关注智能容灾失效及手动切流的效率;而非多活的业务须要有多种逃熟手腕:经过DCDN内网节点回源、或经过API网关跨机房转发。
机房极其网络缺点预案
如上文所述,源站有双公网POP加专线三个入口,所以逻辑上马意两个入口意外,都依然无时机保证业务可用性。因此咱们做了如下措施:
图3:DCDN流量调度架构:日常态 / 容灾态
多活树立继续推动及常态化演练
我站业务关键为同城多活架构,如图4所示,咱们将多个机房逻辑上划分为两个可用区,每个可用区日常承当50%的流量,将全体多活架构分层来看:
关于成功多活革新的业务,咱们树立了多活管控平台对业务多活元信息启动一致保养,支持业务南北向及物品向多活切流管控。平台侧支持切流预案的保养,支持单业务、多业务、全站保养的极速切流。同时平台提供多活关系危险巡检才干,从多活流量比、业务容量、组件性能、跨机房调用等角度常态巡检危险,支持关系危险的控制运营。
前置成功启动预案保养微危险控制后,咱们活期启动单个业务、多个业务组合南北向切流演练,验证服务自身、其依赖组件、其依赖下游的容量、限流等资源负载状况,常态保证多活的有效性,常态可切换可容灾。
机房级别智能容灾
关于用户强感知的场景触及的外围服务,在DCDN侧功动力站机房级别的容灾战略,应答单个源站机房入口缺点时可以智能将流量路由至另一个机房成功止损。
多活业务的智能容灾原先没有自动全性能,优先保证了介绍、播放关系等主场景,其他业务场景依据资源池水位状况口头切流。咱们资源池平均CPU应用率已达35%+,在线业务平均峰值CPU应用率凑近50%,咱们曾经对全站业务切流单机房的资源需求启动梳理,同时多活切流也将联动平台启动HPA战略调整,以及预备资源池的极速弹性预案,确保大盘资源的肥壮。后续将支持对社区互动、搜查、空间等更多用户强感知场景智能容灾战略性能。在遇到机房级别缺点时刻无需人工干预,多活业务可间接容灾止损。
图5:多活业务南北向流量架构:日常态 / 容灾态
非多活流量逃生
局部业务是没有多机房多活部署的,仅在一个机房可以处置流量;因此在原来的方案中,这局部非多活业务流量只会回源至机房 A,无法应答机房 A 公网入口缺点。似乎本次意外中,非多活业务流量无法切流止损,依赖升级走CDN专线节点。
为了应答单机房公网入口、四层负载、七层负载缺点等场景,咱们方案在DCDN侧为非多活业务规定也功动力站级别智能容灾,在七层负载SLB成功多机房多集群的路由性能兼并一致,确保非多活业务的流量在缺点时可进入机房 B 路由至API网关;在API网关侧判别接口能否多活,非多活接口经过内网专线启动流量转发,成功流量逃生。
图6:非多活业务南北向流量架构:日常态 / 容灾态
5、总结
单个机房级别的缺点,十分考验多活革新的完整性和有效性,同时必需须要缺点演练来启动验证,下半年咱们会继续重点关注多活危险控制,除了常态的切流演练外也会启动南北向、物品向的断网演练。