弃权协议：Clos网络中的根因分析

# 弃权协议：Clos交换结构的RCA（操作系统）  
来源：https://arxiv.org/html/2608.21412  
Madhava Gaikwad Deepak Pandey  
所属机构：Microsoft  

#### 摘要  
大型数据中心网络中的根因分析（RCA）具有挑战性，因为遥测数据存在噪声、部分缺失和异步性。基于评分的方法在这些条件下性能下降，常导致不稳定或错误的归因。我们提出**CoreSec**，一个生产级RCA系统，它用PAM风格的弃权代数替代了加权融合。遥测代理通过控制标志组合，当证据模糊时能产生确定性决策和显式弃权。CoreSec将此代数与拓扑感知配置相结合，能够捕捉Clos交换结构的故障面，并在证据累积时单调收敛。该系统已在超大规模环境中部署，在多样化的环境中提供稳定且可解释的RCA行为，无需重新调优。我们的经验表明，基于结构化组合与弃权机制的框架为现实云网络中的自动化RCA奠定了实用基础。  

## 1 引言  
大型云网络运行过程中存在持续的背景故障。在一个拥有数千台交换机的集群中，服务器到TOR（机架顶交换机）线缆出现CRC错误、交换机间链路间歇性抖动、TOR正在进行升级等情况都很常见。（链路*抖动*指其在上下线状态间快速切换。）Clos拓扑是一种多级交换结构，在任意两个端点间提供多条等价路径（图1）。这些拓扑通过路径多样性吸收故障，使交换结构能继续转发流量。先前对超大规模网络的研究报告了相同的现象[14]。但这种背景噪声使得根因分析变得困难：当客户工作负载出现故障时，许多组件都显示异常，只有一部分与事件相关，大多数是常规的背景故障。  

**图1：三层Clos拓扑**  
服务器连接至TOR，TOR连接至T1汇聚交换机，T1连接至T2 spine交换机。  

准确的RCA之所以重要，原因有二：  
1. 客户期望对连接中断获得精确解释：什么设备故障、是否会重现、以及Azure正在采取什么措施。  
2. 工程团队利用聚合的RCA数据识别固件、光模块和运维流程中的系统性弱点。跨数千事件的模式揭示了哪些硬件系列故障率最高，以及哪些运维变更引入了风险[6,33,7]。  

CoreSec识别的大多数故障并非停机式失效，而是**灰色故障**[18]：部分的、概率性的或间歇性的故障。光模块松动的设备可能在某条链路的单个方向丢弃2%的数据包；有内存位翻转的线卡可能仅损坏哈希到特定ECMP路径的数据流头部；固件缺陷可能周期性重启交换机，并在健康监测器察觉前恢复运行。它们的表面症状融入持续的背景故障率中（§2），新上岗的值班工程师仅凭计数器和探针数据，无法判断特定信号是正在调查的事件引起的，还是交换结构中某处持续发生的众多无关故障之一。  

CoreSec运行在Azure现有的运维管道之上。其许多输入来自CoreSec之前构建和部署的遥测系统，其中两个尤为重要：  
- **Pingmesh**[14]运行在每个服务器上，持续测量跨交换结构的服务器对之间的端到端延迟和丢包。它告诉运维人员*哪个区域*出现问题，但不指明具体故障设备。  
- **NetBouncer**[37]位于更低层级：它主动探测通过Clos交换结构的路径，推断*哪些链路和设备*不健康。  

两者都无法回答我们持续收到的告警请求：针对特定客户服务的具体事件，到底是*哪个网络实体*导致的？在任何时刻，许多实体都可能处于不健康状态，但大多数与调查中的事件无关。CoreSec消费Pingmesh、NetBouncer以及其他代理（设备计数器、流量导出信号、控制平面事件、基础设施健康摘要）的输出，并将其解析为单一归因。我们在§11中详细讨论了与这些系统的关系。  

Azure早期的RCA系统采用遥测信号加权聚合的方式。**遥测代理**是一种软件组件，它观察网络的某个属性（主动探针、设备计数器或流量流），并报告该属性是否健康的逐实体判定。每个代理生成一个评分，权重求和最高的实体被归咎。这种失败方式具有可预测性：背景故障总会贡献一些信号，因此即使网络没有故障，系统也会找出一个“罪魁祸首”。为降低某类故障的误报率而调整权重，会增加另一类故障的误报率。误报率在18%到22%之间波动且无法控制[37,21,14]。  

CoreSec背后的关键观察是，在此情境下的RCA是一个**组合问题**。没有单个遥测代理在所有故障模式下都可靠：主动探针能快速检测链路故障但会遗漏软件缺陷；设备计数器能捕获硬件退化但产生噪声；流量导出信号反映客户影响但覆盖稀疏。我们在§2.2中详细描述了这些代理类别。  

CoreSec为每个代理分配一个**控制标志**，指定其证据是必需的、充分的还是可选的。当证据冲突或缺失时，系统将弃权。这种结构受到**可插拔认证模块（PAM）**[31]的启发，PAM通过将每个独立的认证检查（密码、生物识别、硬件令牌）标记为必需、充分或可选来组合它们。组合问题与我们处理遥测数据面临的问题相同。  

本文做出四项贡献：  
- **可组合的RCA代数与显式弃权机制**。我们将PAM的控制标志模型应用于网络RCA。每个遥测代理被分配一个标志：必要、必需、充分或可选。五个配置并行运行，每个针对Clos拓扑中不同的故障面。该代数在健康和不健康之外引入了第三种结果——当证据缺失或冲突时系统弃权——并产生确定性、可解释的决策。  
- **拓扑感知启发式规则**。通过对多年历史事件[3,30]的分析，我们为服务器到TOR、TOR到T1和集群级归因推导出一小组拓扑阈值（§5描述）。这些阈值位于误差曲线拐点处，无需重新校准即可泛化到各种Azure部署。  
- **三年生产部署**。CoreSec已处理超过70万起事件，将误报率从18-22%降低至1%以下。我们将弃权视为显式假阴性；最近六个月内，该比率从最初的10%降至1.5%。该系统相当于消除了三名全职工程师的人工RCA工作量。  
- **形式化模型**。我们给出了合并算子的代数规范，将其定义为具有短结合性证明的三值格，以及吸收性和共识性（附录A），解释了CoreSec在异步遥测下的确定性和顺序不变性。  

CoreSec在事件发生后被调用，而非作为持续监控系统：外部检测器发出警报，CoreSec从16分钟的遥测窗口中归因该特定事件。其五个配置分别针对Clos拓扑中的一种组件类型（服务器到TOR线缆、TOR、交换机到交换机线缆、T1、T2）。在单个配置内，PAM风格代数将代理判定解析为*健康*、*不健康*或*不确定*；跨配置时，拓扑启发式规则（§5.2）决定当多个配置投票时哪一层负责。如果所有配置均无足够证据，CoreSec将弃权。图2展示了该流程。  

**图2：CoreSec数据流**  
事件触发五个并行配置；层级启发式规则将其投票合并为单一归因或弃权。  

**流程示例**：假设三台服务器故障且指向上游问题。配置2（TOR交换机）将每台服务器的TOR标记为候选。配置4（T1交换机）检查同一T1扇出内是否有足够多的TOR也不健康。如果至少三分之二的TOR异常，T1将投票并抑制各个TOR的候选资格。最终RCA结果为T1故障。具体数值见§5。  

## 2 背景与动机  
### 超大规模网络中的Clos交换结构  
超大规模云网络采用多级Clos拓扑，因为它提供可预测的带宽、均匀延迟和清晰的故障隔离。三层交换结构将服务器连接至TOR交换机，TOR连接至汇聚交换机（T1），T1连接至spine交换机（T2）。每台服务器通常连接一个或多个TOR以实现容错，每个TOR有多条上行链路连接至独立的T1。这种结构创建了许多等价路径，并在链路或设备故障时允许流量快速重新路由[14,30]。  

Clos交换结构经历持续的背景故障率。光模块漂移、线缆累积CRC错误、控制平面进程重启、固件按滚动计划升级。对已部署集群的研究显示，单个区域内每天有数百次瞬态链路故障和数十次设备重启[30]。多路径路由吸收了这些故障，因此它们很少造成可见中断。在任何给定时间，0.3%到1%的链路显示丢包、抖动或光模块性能下降是正常情况[14]。  

这种基线增加了根因分析的难度。客户可见事件通常与多个无关背景故障同时发生。拓扑决定了故障的传播方式：TOR故障通常只影响其机架，而T1故障会在多个TOR上产生关联症状。CoreSec的启发式规则正是基于这些传播模式构建的。  

### 遥测代理与故障信号  
大规模Clos网络依赖多个遥测源来检测和定位故障。每个源从不同视角观察网络，并以不同的时空分辨率报告[37,14,21]。  

- **主动探针**：类似Pingmesh[14]的系统沿控制路径注入合成探针并测量丢包和延迟。主动探针提供快速检测，可定位路径级问题，但依赖探针覆盖。某些链路可能在特定时段探针稀疏或无探针。  
- **设备计数器**：交换机导出CRC错误、链路抖动、FCS丢弃和光功率读数等计数器（例如通过gNMI推送或SNMP拉取）。这些提供硬件问题的直接证据，但更新不规律且对瞬态噪声敏感[30]。设备在控制平面重启或固件升级期间可能停止报告。  
- **流量导出信号**：如NetBouncer[37]等系统分析实际流量的路径，检测行为偏离基线的链路。这些信号反映客户影响，但需要足够的流量。  
- **基础设施信号**：集群健康指标、机架电源故障和冷却异常捕获广泛事件，但以分钟级时间尺度更新，可能到达时已不适合早期RCA。  

没有单个代理在所有故障模式下都可靠。代理间覆盖范围、延迟和噪声的差异使得多代理融合必不可少。  

### 运维要求  
超大规模环境中的网络RCA必须满足四个要求：  
- **可控性**：运维人员必须能够约束误报率。  
- **可解释性**：每个决策必须能根据代理输出解释。  
- **可扩展性**：必须轻松集成具有不同语义和延迟的新代理。  
- **拓扑感知性**：系统必须考虑故障在Clos层级中上下关联的方式。  

先前的故障定位系统解决了部分需求，但没有单一设计涵盖全部[37,21,5]。  

### 从事件到设计  
CoreSec源于对错误RCA的多年回顾。我们最初的尝试很直接：选择最可靠的代理，赋予高权重，让它主导决策。几个月内我们就看到了这样做的问题。可靠捕捉光模块退化的代理并不适合处理固件崩溃，反之亦然。可靠性结果表明是故障特定的，而非代理特定的。我们还必须从决策路径中移除几个基础设施信号，因为它们与CoreSec自身形成反馈环（细节见§5）。  

我们保留的是更少的代理和一种更谨慎的组合方式。从这项工作中提炼出的系统形态，包括从事件复盘中提取的模式，在后续章节中描述。  

## 3 PAM风格的可组合RCA代数  
CoreSec的根因分析逻辑建立在受**可插拔认证模块（PAM）**[31,11]启发的可组合代数上。PAM在透明的决策框架下统一了异构认证源。关键洞察是认证是一个检查序列：有些必须成功，有些在成功或失败时短路，其他则起辅助作用。例如，在典型PAM栈中，成功的生物识别检查可以短路整个栈以授予权限；失败的强制密码检查无论其他栈报告如何都会拒绝访问；可选的使用历史检查仅在强制检查未产生判定时才重要。  

该模型清晰映射到大型Clos交换结构的RCA中，其中遥测信号在粒度、延迟、可靠性和范围上各不相同。生产环境交换结构的遥测数据说明了为何需要可组合方法：故障频繁但很少灾难性。