[解决方案] 深入解析 Google Cloud 网络：Protective ReRoute 如何提升网络韧性

**发布时间:** 2025-11-15 **厂商:** GCP **类型:** BLOG **原始链接:** https://cloud.google.com/blog/products/networking/how-protective-reroute-improves-network-resilience ---  [解决方案] 深入解析 Google Cloud 网络：Protective ReRoute 如何提升网络韧性   # 解决方案分析：Google Cloud Protective ReRoute (PRR) ## 解决方案概述该解决方案旨在解决超大规模网络中，传统路由协议因**慢收敛 (slow convergence)** 或 **收敛失败 (convergence failure)** 导致的路由中断问题。这类问题对实时应用，尤其是对丢包极其敏感的大规模 **AI/ML 训练** 作业会造成严重影响，可能导致数百万美元的计算时间浪费。 **Protective ReRoute (PRR)** 是一种创新的、基于 **主机 (host-based)** 的故障恢复机制。其核心思想是将快速故障恢复的责任从集中式的网络核心转移到分布式的通信端点（主机）本身。PRR利用Google网络中固有的丰富路径多样性，在主机检测到当前通信路径发生故障（如丢包或高延迟）时，能智能地将流量 **重新引导 (re-steer)** 至一条健康的并行路径，从而在网络路由协议完成全局收敛之前恢复通信。这一设计将网络可靠性模型从传统的 **串行模型**（系统可靠性随网络直径/跳数增加而降低）转变为 **高度并行的路径系统**（系统可靠性随可用路径数量的指数级增长而提升），从根本上规避了慢收敛对业务的冲击。 ## 实施原理 PRR机制包含三个核心功能组件，构成了一个完整的主机侧快速恢复流程： 1. **端到端故障检测** - 通信主机持续监控路径健康状况。在Linux系统中，标准机制是利用 **TCP重传超时 (RTO)** 来作为潜在故障的信号。故障检测时间通常是网络往返时延 (RTT) 的个位数倍。 2. **主机侧报文头修改** - 一旦检测到故障，发送方主机会修改报文头中的特定字段来影响数据包的转发路径。Google率先在Linux内核 (4.20+) 中贡献并使用了修改 **IPv6 Flow-Label** 的机制来实现这一点。 - 对于 **IPv4流量** 和非Linux主机，Google的 **软件定义网络 (SDN)** 层会通过修改网络覆盖层 (overlay) 的外部报文头来执行检测和路径重选，从而提供同等保护。 3. **PRR感知转发** - Google Cloud网络中的路由器和交换机能够识别并遵从这种报文头的修改，将数据包转发到另一条可用的、能够绕过故障组件的路径上。 ## 方案客户价值 - **提升AI/ML训练效率** - 对于跨大量加速器（GPU/TPU）的分布式训练任务，PRR可提供超高可靠的数据分发，避免因短暂的网络中断导致的高昂计算资源浪费和作业重启。 - **保障数据完整性与存储** - 通过将中断窗口缩至最短，PRR显著减少了丢包，从而降低了数据损坏和丢失的风险，保障了应用性能和数据完整性。 - **优化实时应用体验** - 满足游戏、视频会议、语音通话等对网络中断容忍度极低的应用场景，将故障恢复时间缩短至远快于传统网络收敛的水平。 - **增强高频短连接应用的可靠性** - 确保依赖大量、频繁、短生命周期连接的应用能够可靠地完成通信，不受网络瞬时故障的影响。 - **显著降低网络中断影响** - 经过Google内部生产环境验证，PRR可有效恢复高达 **84%** 由慢收敛事件引起的跨数据中心网络中断。 ## 实施选项与要求 Google Cloud客户可以通过两种模式从PRR中受益： - **Hypervisor模式 (自动启用)** - 自动保护跨Google数据中心的流量，无需对客户虚拟机操作系统进行任何更改。 - 为中等扇出规模的流量提供秒级的恢复能力。 - **Guest模式 (可选增强)** - 专为关键的、性能敏感的、高扇出的应用（如AI/ML）设计，提供最快的恢复时间和最大的控制力。 - 启用要求： - [ ] 虚拟机运行现代Linux内核 (4.20+)。 - [ ] 应用使用TCP协议。 - [ ] 应用流量使用IPv6。对于IPv4流量保护，应用需要使用 **gVNIC** 驱动。 ## 涉及的相关产品与技术 - **Linux Kernel (4.20+)**: PRR的核心机制已贡献给Linux主线内核，体现了其开放性。 - **Google Cloud SDN**: 负责实现网络层的PRR感知转发，并为IPv4等复杂场景提供覆盖层支持。 - **gVNIC (Google Virtual NIC)**: 在Guest模式下为IPv4流量提供PRR保护所必需的虚拟网卡驱动。 - **Compute Engine**: PRR技术所应用的虚拟机（VM）环境。 ## 技术评估 - **技术优势** - **架构创新**: 从传统的网络侧恢复转向主机侧恢复，从根本上改变了解决网络故障的范式，将故障处理的主动权交给了最先感知到问题的端点。 - **极速恢复**: 恢复时间通常为RTT的个位数倍，远快于传统路由协议的秒级甚至分钟级收敛时间。 - **高有效性**: 经过Google全球网络超过五年的生产环境部署和验证，效果显著，证明了其在超大规模环境下的稳定性和可靠性。 - **开放性**: 核心机制已开源并合入Linux内核，降低了社区和客户的采用门槛，并推动了整个行业网络可靠性技术的发展。 - **潜在限制与依赖** - **路径多样性依赖**: PRR的有效性高度依赖于底层物理网络具备丰富的多路径冗余。这是Google等超大规模云厂商的优势，但在路径单一的网络环境中效果会受限。 - **Guest模式特定要求**: 客户若想获得最佳性能，其应用和操作系统环境需满足特定的技术栈要求（Linux版本、TCP、IPv6/gVNIC），可能需要对现有应用环境进行适配。   # 深入解析 Google Cloud 网络：保护性重路由 (Protective ReRoute) 如何提升网络弹性 **原始链接:** [https://cloud.google.com/blog/products/networking/how-protective-reroute-improves-network-resilience](https://cloud.google.com/blog/products/networking/how-protective-reroute-improves-network-resilience) **发布时间:** 2025-11-15 **厂商:** GCP **类型:** BLOG --- 网络 # 深入解析 Google Cloud 网络：保护性重路由 (Protective ReRoute) 如何提升网络弹性 2025 年 11 月 15 日 ##### Victor Moreno 云网络解决方案负责人 ##### Yaogong Wang 主任软件工程师 ##### 试用 Gemini 2.5 我们最智能的模型现已在 Vertex AI 上提供 [立即试用](https://console.cloud.google.com/vertex-ai/studio/freeform) 云基础设施的可靠性是基石，然而，即使是最高级的全球网络也可能面临一个关键问题：**从路由中断中恢复缓慢或失败**。在像 Google 这样行星级规模的庞大网络中，路由器故障或复杂、隐藏的状况可能会阻碍传统的路由协议 (routing protocols) 快速恢复服务，有时甚至完全无法恢复。这些短暂但代价高昂的中断——我们称之为 **慢收敛 (slow convergence)** 或 **收敛失败 (convergence failure)**——会严重影响对丢包容忍度低的实时应用，尤其对当今大规模、敏感的 AI/ML 训练任务影响最为严重，一次短暂的网络抖动就可能浪费数百万美元的计算时间。为了解决这个问题，我们开创了 **保护性重路由 (Protective ReRoute, PRR)**，这是一项根本性的转变，它将快速故障恢复的责任从集中的网络核心转移到分布式的端点 (endpoints) 自身。自五年多前将其投入生产以来，这种基于主机的机制 (host-based mechanism) 极大地增强了 Google 网络的弹性，并证明在恢复由慢收敛事件导致的数据中心间网络中断方面，其有效率高达 **84%**¹。拥有对丢包敏感的工作负载的 Google Cloud 客户也可以在他们的环境中启用该功能——请继续阅读以了解更多信息。 ### **网络内恢复的局限性** 传统的路由协议对网络运行至关重要，但它们的速度往往不足以满足现代实时工作负载的需求。当路由器或链路发生故障时，网络必须重新计算所有受影响的路由，这一过程被称为 **重新收敛 (reconvergence)**。在 Google 规模的网络中，这个过程会因拓扑结构的庞大规模而变得复杂，导致延迟从数秒到数分钟不等。对于具有广泛扇出 (fan-out) 通信模式的分布式 AI 训练任务而言，即使是几秒钟的丢包也可能导致应用失败和代价高昂的重启。这是一个规模问题：随着网络规模的增长，这些复杂故障场景出现的可能性也在增加。 ### **保护性重路由 (Prote-ctive ReRoute)：一种基于主机的解决方案** 保护性重路由是一个简单而有效的概念：**授权通信端点 (即主机) 检测故障，并智能地将流量重新引导到健康的并行路径上。** PRR 没有等待全局网络更新，而是充分利用了我们网络中内置的丰富路径多样性 (path diversity)。主机会检测到当前路径上的丢包或高延迟，然后通过修改精心选择的数据包头字段来立即启动路径变更，从而告知网络使用一条备用的、预先存在的路径。这种架构代表了网络可靠性思维的根本性转变。传统网络依赖于并行和 **串行可靠性 (series reliability)** 的结合。组件的串行化会降低系统的可靠性；在具有多个转发阶段的大直径网络中，可靠性会随着直径的增加而下降。换句话说，每一个转发阶段都会影响整个系统。即使某个网络阶段设计了并行可靠性 (parallel reliability)，在并行阶段重新收敛的过程中，它也会对整个网络产生串行影响。通过在网络边缘添加 PRR，我们将网络视为一个 **由多条路径构成的高度并行系统，这些路径整体表现为单一阶段**，其整体可靠性随着可用路径数量的指数级增长而增加，从而有效规避了大直径网络中慢网络收敛的串行化效应。下图对比了启用 PRR 的网络与传统网络的系统可靠性模型。传统网络的可靠性与转发阶段的数量成反比；而使用 PRR 后，同一网络的可靠性与复合路径的数量成正比，复合路径的数量又与网络直径成指数级正比。 ![https://storage.googleapis.com/gweb-cloudblog-publish/images/1-Protective_ReRoute.max-1100x1100.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/1-Protective_ReRoute.max-1100x1100.png) ### **保护性重路由 (Protective ReRoute) 的工作原理** PRR 机制包含三个核心功能组件： - **端到端故障检测：** 通信主机持续监控路径健康状况。在 Linux 系统上，标准机制使用 **TCP 重传超时 (retransmission timeout, RTO)** 来发出潜在故障信号。检测到故障的时间通常是网络往返时间 (round-trip time, RTT) 的个位数倍。此外，还有其他速度和成本各不相同的端到端故障检测方法。 - **主机端数据包头修改：** 一旦检测到故障，发送方主机会修改一个数据包头字段来影响转发路径。为实现这一点，Google 开创并贡献了在 Linux 内核 (4.20+ 版本) 中修改 **IPv6 流标签 (flow-label)** 的机制。至关重要的是，Google 软件定义网络 (software-defined network, SDN) 层通过在网络覆盖 (overlay) 的外部报头 (outer headers) 上执行检测和重路由，也为 **IPv4 流量和非 Linux 主机** 提供了保护。 - **PRR 感知转发：** 多路径网络中的路由器和交换机能够识别这种报头修改，并将数据包转发到另一条可用的、能够绕过故障组件的路径上。 ### **效果证明** PRR 并非理论；它是一个 7x24 小时持续部署的系统，保护着全球范围内的生产流量。其影响力令人信服：PRR 已被证明可将由慢收敛和收敛失败造成的网络停机时间减少高达前述的 **84%**。这意味着，每 10 次本应由路由器故障或缓慢的网络级恢复引起的网络中断中，有多达 8 次现在被主机避免了。此外，由主机发起的恢复速度极快，通常在 RTT 的个位数倍时间内解决问题，这远快于传统的网络重新收敛时间。 ### **超高可靠性网络的主要用例** 在现代应用需求的推动下，对 PRR 的需求日益增长： - **AI/ML 训练和推理：** 大规模工作负载，特别是那些 **分布在多个加速器 (accelerators)** (GPU/TPU) 上的工作负载，对网络可靠性尤为敏感。PRR 提供了超高可靠的数据分发能力，确保这些高价值的计算任务不间断运行。 - **数据完整性和存储：** 大量丢包不仅会降低吞吐量，还可能导致 **数据损坏 (data corruption)** 和 **数据丢失 (data loss)**。通过缩短中断窗口，PRR 提高了应用性能并有助于保障数据完整性。 - **实时应用：** 游戏、视频会议和语音通话等应用，即使是短暂的连接中断也无法容忍。PRR 缩短了网络故障的恢复时间，以满足这些严格的实时要求。 - **频繁的短生命周期连接：** 依赖大量、频繁的短生命周期连接的应用，在网络即使短暂不可用时也可能失败。通过缩短预期的中断窗口，PRR 帮助这些应用可靠地完成其所需的连接。 ### **为您的应用激活保护性重路由 (Protective ReRoute)** 向基于主机的可靠性架构转型是 Google Cloud 客户可以采用的一项技术。其核心机制是开源的，并且是 Linux 主线内核 (4.20 及更高版本) 的一部分。您可以通过两种主要方式从 PRR 中受益： - **虚拟机监控程序 (Hypervisor) 模式：** PRR 自动保护跨 Google 数据中心运行的流量，无需对客户机操作系统 (guest OS) 进行任何更改。对于网络特定区域中扇出程度适中的流量，虚拟机监控程序模式可在个位数秒内实现恢复。 - **客户机 (Guest) 模式：** 对于具有高扇出且位于网络任何部分的关键、性能敏感型应用，您可以 **选择启用客户机模式的 PRR**，这可以实现最快的恢复时间和最大的控制力。这是要求严苛的关键任务应用、AI/ML 任务以及其他延迟敏感型服务的最佳设置。要为关键应用激活客户机模式的 PRR，请遵循 [文档](https://cloud.google.com/compute/docs/networking/tcp-optimization-for-network-performance-in-gcp-and-hybrid#use-prr-for-network-resiliency) 中的指导，并确保满足以下条件： - 您的虚拟机运行现代 Linux 内核 (4.20+)。 - 您的应用使用 TCP。 - 应用流量使用 IPv6。对于 IPv4 保护，应用需要使用 gVNIC 驱动程序。 ### **开始使用** 保护性重路由的可用性对各种 Google 和 Google Cloud 用户都具有深远的影响。 - **对于拥有关键工作负载的云客户：** 评估并为对丢包敏感且需要最快恢复时间的应用 (如大规模 AI/ML 任务或实时服务) 启用客户机模式的 PRR。 - **对于网络架构师：** 重新评估您的网络可靠性架构。考虑设计丰富的路径多样性并授权端点智能地绕过故障所带来的好处，将您的模型从串行可靠性转变为并行可靠性。 - **对于开源社区：** 认识到主机级网络创新的力量。为所有主流操作系统贡献并倡导类似的可靠性功能，为每个人创建一个更具弹性的互联网。 --- *1. [https://dl.acm.org/doi/10.1145/3603269.3604867](https://dl.acm.org/doi/10.1145/3603269.3604867)* 发布于 - [网络](https://cloud.google.com/blog/products/networking)