故障周第二弹:谷歌云平台全局负载均衡服务发生中断

Posted 架构头条

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了故障周第二弹:谷歌云平台全局负载均衡服务发生中断相关的知识,希望对你有一定的参考价值。

编辑 | 无明,张婵
本周故障频发,前脚亚马逊Prime Day出了点问题,后脚谷歌云平台发生网络事故。

美国当地时间 7 月 17 日中午 12 点 17 分,谷歌云平台遭遇服务故障,全局负载距衡器 (Global Load Balancer,GLB) 返回 502 状态码,Google Cloud, App Engine 以及 Stackdriver 等依赖云 HTTP 负载均衡的服务均受到影响。Snapchat,Pokemon Go 和 Spotify 等使用谷歌云服务的流行应用程序和站点也受到影响。

在事故发生约 28 分钟,谷歌工程团队找到了事故原因,并开始部署修复程序。在 12:55,服务已经完全恢复。截止 13:05,问题已经解决,所有受影响的用户服务都恢复了正常。

7 月 19 日,谷歌云平台官方发布了事故分析报告,阐述了问题始末和事故原因,用户补偿以及预防措施。以下是谷歌云平台的分析报告:

问题概要

本周二,也就是 2018 年 7 月 17 日,谷歌云应用引擎(Google Cloud App Engine)、谷歌 HTTP(S) 负载均衡器或 TCP/SSL 代理负载均衡器的用户经历了长达 32 分钟的故障,他们分别收到了 33%至 87%不等的错误率。用户可以看到 502 状态码或连接被重置的错误。对于在此次事件中服务或业务受到影响的用户,我们深表歉意。与此同时,我们正在采取措施改善平台的性能和可用性。我们也将为受该事件影响的用户提供 SLA 补偿。

事件细节

太平洋时间 2018 年 7 月 17 日 12 点 17 分到 12 点 49 分,一些发送到谷歌云 HTTP(s) 负载均衡器的请求返回了 502 状态码。在此期间,返回的 502 状态码的比例从 33%到 87%不等。自动监控系统在 12 点 19 分向谷歌工程团队发出告警。12 点 44 分,工程团队找到了可能的根本原因,并部署了修复程序。12 点 49 分,修复生效,502 错误率迅速恢复到正常水平。伴随着流量回升和缓存逐渐起效,服务经历了几分钟的降级延迟。12 点 55 分,服务完全恢复,与云 TCP/SSL 代理负载均衡器的连接被重置。依赖云 HTTP 负载均衡的云服务(如谷歌云应用引擎应用程序服务、谷歌云 Function、Stackdriver Web UI、Dialogflow 和 Cloud Support Portal/API)在事件期间均受到影响。

由于位于云 HTTP(s) 负载均衡器后面的服务对云 CDN URL 的引用减少,以及无法更新过时的缓存条目或在缓存未命中时插入新的内容,云 CDN 缓存的命中率下降了 70%。于是,运行在谷歌 Kubernetes 引擎上并使用 Ingress 资源的服务返回了 502 状态码。通过云负载均衡器提供服务的谷歌云存储的流量也受到了影响。

其他的谷歌云平台服务未受影响。例如,直接使用 VM 或网络负载均衡的应用程序和服务不受影响。

根本原因

谷歌的全局负载均衡器是基于双层架构的谷歌前端(Google Front End,GFE)而构建的。GFE 的第一层负责响应就近用户的请求,以便在建立连接期间最大限度地提高性能。这些 GFE 将请求路由到距离目标服务最近的第二层 GFE。这种架构可以降低客户端的连接延迟,同时可以利用谷歌的全球网络将请求发送给后端,不管它们位于哪个区域。

GFE 开发团队正在为 GFE 添加新的特性,用以提升安全性和性能。这些特性已经被引入到第二层 GFE 的代码库中,但尚未投入使用。其中有一个特性包含了一个会导致 GFE 重启的 bug,这个 bug 在测试和首次部署中未被检测出来。在事件刚发生时,生产环境中的一个配置变更会间歇性地触发这个 bug,导致受影响的 GFE 反复重启。由于重启无法在瞬间完成,第二层 GFE 的可用容量就减少了。虽然一部分请求得到了正确的响应,但也有一部分请求被中断(连接被重置)或由于等待 GFE 重新上线而被拒绝服务。

补救和预防

谷歌工程师在 3 分钟内收到告警,并立即着手调查原因。太平洋夏令时间 12 点 44 分,工程团队发现了根本原因,并迅速回滚了配置变更,受影响的 GFE 停止了重启。随着所有 GFE 恢复服务,流量也恢复到正常水平。

除了修复问题之外,我们还将通过以下几项措施来防止和减少此类故障的影响:

  • 我们正在添加额外的安全措施来禁用不在使用中的功能。

  • 我们计划加强 GFE 的测试栈,降低二进制文件中可能包含会导致任务重启的 bug 的风险。

  • 我们还将对 GFE 池的不同分片进行额外的隔离,以减少故障的影响范围。

  • 最后,为了加快诊断速度,我们计划为 GFE 池创建配置变更仪表盘,让工程师可以更轻松、更快地查看、关联和识别有问题的系统变更。

对于此次事件对用户及其业务造成的影响,我们再次深表歉意。对于影响服务可用性和可靠性的事件,我们都非常重视,尤其是跨地区的事故。我们正在对事件进行彻底的调查,并将调查结果作为 GCP 工程的首要参考。

有网友说,谷歌出问题几乎等于互联网瘫痪,这很有趣,也很可怕。的确,在云计算时代,我们能以更低廉的成本更灵活地利用云中的各种资源,但是一旦“云”出了故障,就会牵一发而动全身,造成大范围的影响。对于故障,只能尽量降低发生率,谁又能完全避免出现故障呢?

近期大规模故障回顾:




活动推荐

8 月 18 日,InfoQ 将举办一场面向技术人的区块链大会!超过二十个区块链落地案例,区块链前沿技术剖析,区块链生态、服务盘点和解读,尽在 BCCon2018!点击查看原文进入大会官网了解更多信息。

以上是关于故障周第二弹:谷歌云平台全局负载均衡服务发生中断的主要内容,如果未能解决你的问题,请参考以下文章

谷歌云负载均衡器是单点故障吗?我们可以有一个备用副本吗?

谷歌云负载均衡器 + GKE 入口

通过谷歌云存储和负载均衡器服务反应应用程序,将任何网址映射到索引?

谷歌云负载均衡器是不是合规

谷歌云,如何重写存储桶服务的负载均衡器主机和路径,这样我就不必将文件嵌套在下面,例如:/files/public?

谷歌云计算负载平衡和自动缩放信息不是为系统管理员类型编写的