摘要
2026年7月14日 10:00 PT，Google Cloud VMware Engine（GCVE）的拉伸集群（Stretched Cluster）在悉尼、墨尔本、法兰克福、多伦多等多个区域同时出现跨区通信中断，持续约 11 小时 46 分（部分来源记 20:40 PT 恢复）。根因是一次部署到基础网络控制平面的网络配置更新：配置负载本身结构合法，却暴露了控制面路由逻辑的实现缺陷，导致底层网络主机错误编程路由表，丢弃了 GCVE 拉伸集群所用私有地址空间的流量，跨区链路被切断、触发 VMware HA 故障转移。受影响虚拟机的计算与存储本身始终在运行，却因跨区链路断开而不可访问、部分失去可写数据。谷歌通过将错误配置回滚至上一已知正常状态恢复。属官方已发布根因的「配置变更致级联」典型事故。
时间线
10:00 PT 7/14GCVE 拉伸集群跨区通信故障开始，悉尼/墨尔本/法兰克福/多伦多受影响
13:24 PT 7/14 (20:24 UTC)谷歌首条状态更新，定性为拉伸集群网络连接问题，强调计算与存储未受波及
16:05 PT 7/14 (23:05 UTC)确认底层跨区通信故障 + witness 设备不可达 + BGP 会话震荡，集群区域无法安全同步状态
后续调查锁定一次「近期网络配置更新」为跨区中断的可能原因
21:46 PT 7/14 (07/15 04:46 UTC)回滚至上一已知正常配置，跨区连接恢复（持续约 11h46m）
07:14 UTC 7/24状态页出现一条 <1 分钟的 GCVE 复核记录，非独立中断，不单列
根因
一次意图为「为新能力准备云网络基础设施」的网络配置更新被部署到基础网络控制平面。配置负载在结构上合法、通过了初始载荷校验，却暴露了控制面路由逻辑的一个实现缺陷：底层网络主机据此错误地编程了路由表，导致发往 GCVE 拉伸集群所用私有 IP 地址空间的流量被丢弃。拉伸集群依赖该私有地址空间建立跨区路由会话，流量丢弃随即切断了集群活跃区域之间的通信，触发 VMware HA 故障转移。由于 BGP/BFD 等标准路由健康检查的控制面会话运行在相互隔离的地址空间、保持健康，标准故障转移机制未能察觉数据面这一选择性丢弃；自动防护也未阻断本次部署——因为配置通过了初始载荷校验。影响仅在更新开始将实际数据流量路由经特定受影响 IP 段后才显现。
放大因素
- 拉伸集群的核心卖点（单站点故障下保持应用连续）完全依赖跨区网络链路；链路一断，韧性归零
- 虚拟机计算与存储健康却因链路断开而不可访问、部分失去可写数据——典型「控制面/数据面解耦失效」
- BGP/BFD 健康检查在独立地址空间运行 → 数据面静默失效未被标准故障转移侦测
- 配置变更通过了载荷校验，却命中未被测试覆盖的代码路径（GCVE 专属网络拓扑不在测试环境）
- 仅拉伸集群客户受影响，而这类客户恰恰是医院、银行等最关键负载
缓解措施
- 识别可用网络路径，部署配置变更重新路由流量、恢复连接
- 将错误配置回滚至上一已知正常状态
- 建议受影响客户在支持协助下将 VM 迁移至健康次要区域
- 事后：将 GCVE 网络拓扑加入测试环境；实现主动探测隧道流量空间的服务级数据面故障转移
经验教训
- 配置变更的爆炸半径可超过硬件故障——秒级全球传播，而硬件本地失效
- 拉伸集群若无独立可靠的跨区链路，并非真正韧性
- 数据面健康必须独立于控制面（BGP）存活状态单独探测
- 控制面网络变更前，必须在预发环境覆盖产品专属网络拓扑
- 真正关键系统应考虑异步地理隔离 + 多云，而非单厂商拉伸集群
检查清单
- 控制面网络变更前，针对 GCVE 拉伸集群等产品专属拓扑在预发环境验证
- 数据面存活探测与 BGP/BFD 控制面健康解耦，独立告警
- 为拉伸集群负载定义不依赖跨区链路的、经演练的故障转移
- 保留上一已知正常配置快照，支持快速回滚
- 关键系统评估异步地理隔离 + 多云，降低单厂商网络控制面依赖