‍‍

针对光网络故障实时定位这个挑战，现有的光网络管控系统是否最优？针对硬件设备的异构性，能否实现统一并直接的管控？针对光层瞬发事件，SNMP技术是否还有用武之地？针对大规模故障实时定位，传统的管控软件是否还能应对？本文展示了一个全新的系统，来解答上述几个问题。

在即将举行的计算机网络顶会 NSDI 2022 上，腾讯网络平台部设计并实现大规模光网络实时管控系统TOOP(又名OpTel)，通过开放解耦合实现设备统一管控，光层流式遥测实现高精度数据采集，腾讯云平台实现海量数据分析和故障实时定位。该系统不仅能发现光层瞬发事件，而且将故障定位效率提升2个数量级以上，相关成果已被 NSDI2022 接收为 Oral 论文。

论文地址：

https://www.usenix.org/conference/nsdi22/presentation/miao

01 / 背景介绍

云服务提供商（如腾讯、谷歌和微软等）通过在多个区域建立尽可能多的数据中心从而支持具有不同带宽和延迟需求的应用程序。数据中心光网络作为连接各个数据中心的基础设施，对数据中心间数据传输的可靠性起着至关重要的作用。在底层，光网络基础架构主要由光学硬件（如光转发设备、放大器、波分复用设备等）和光纤组成。任何组件的故障（即光层事件）都会影响数据中心间的连接性，影响云服务的SLA。因此，提高光网络的可靠性和可用性，及时发现并定位光层事件至关重要。

图1 （a）现有guang kong系统；（b）TOOP

不幸的是，现有的光网络管控系统并不是为实时检测和定位的光层事件而设计的。具体而言，现有系统从光学硬件中采集采样或聚合的光层性能数据，但这种粗粒度的数据既无法检测光层瞬发事件，也不适合云租户快速定位光层事件。图1(a)说明了现有管控系统的局限性。举例而言，持续几十秒的瞬发光层事件造成客户侧视频体验质量下降（如视频卡顿等）。现有云提供商通过管控系统采集15分钟粒度的光层数据，无法检测或定位这种瞬发的光层事件。另外，现有系统在检测和定位长期事件也很慢。云提供商构建多层管控架构从各个供应商特定的控制器查询数据来拼接底层光网络的整体视图，该方式既复杂又容易出错。我们对故障工单数据集的分析表明，对光学硬件故障进行故障定位往往需要花费数小时到数天的时间。

现有管控系统的局限性可归因于三个关键因素。

01

首先，光网络碎片化的管控设计。构建光网络的设备出自于多家供应商，现有管控系统通过结构连接各家供应商管控软件的北向接口实现光层数据访问。尽管供应商的多样性对于云提供商阻止垄断和避免并发性故障至关重要，但这种碎片化的管控设计并不可取，容易造成光层数据无法直接访问以及很难拼凑出同一时刻的网络视图。

02

其次，SNMP协议的局限性。现有管控系统依赖于SNMP协议从设备收集数据。SNMP通过在设备侧执行各种数据管理任务，如创建本地 MIB 数据库，支持对数据库的读写操作等。更快的读写会导致设备侧更高的CPU使用率，影响设备性能。鉴于设备侧有限的资源，基于SNMP 协议很难实现高精度的数据轮询。

03

最后，管控软件的局限性。供应商提供的管控软件往往为管理设计的，并不一定适用于大规模高精度的数据采集。同时，这类管控软件往往部署在固定计算和内存资源的单服务器端。随着光网络规模的扩大或数据采集频率的增加，现有软件会遭遇诸多瓶颈。

本研究采用的方案：我们设计并实现基于光层流式遥测的TOOP系统。该系统可以通过设备模型标准化实现对异构设备性能数据的直接访问，通过光层流式遥测实现高精度数据采集，最后基于腾讯云平台实现海量数据分析和光层故障实时定位（图 1（b））。

02 / 技术创新

TOOP系统的核心创新：

01

与供应商无关的集中控制。TOOP 将光网络的多层控制架构简化为单层控制架构，实现对厂商异构设备的性能数据直接访问。为了实现这种设计，我们为光学设备构建标准化模型，使得厂商异构设备能够完成统一抽象。该标准化模型由两个基本部分组成：逻辑模型和数据模型。

02

简化设备侧遥测管道。TOOP采用“基于推送”的光层流式遥测取代了“基于拉取”SNMP方式，将计算密集型的数据管理任务从光学设备侧卸载到基于云的控制器侧，实现更高频率性能数据数据。具体而言，光层流式遥测主要由以下关键部分组成：Telemetry Manager、Telemetry Agent、Cache和Aggregator。其中，Telemetry Manager模块与集中控制器交互，负责从控制器接收配置并配置其他组件。Telemetry Agent模块从不同的模块读取数据并将它们存储到本地Cache，Aggregator负责将缓存中的数据推送至集中控制器。

03 / 实现细节

图2: TOOP系统架构图

图 2 展示了 TOOP的系统架构。

01

与供应商无关的集中控制(Vendor-agnostic Centralized Control)：在开放解耦合系统中，通过构建光层标准化模型以抽象供应商的实现细节，实现与供应商无关的方式直接管控光学设备。

• 光学设备标准化模型(Standardized Model for Optical Devices)

在多供应商光网络中，不同光学设备在功能上是相似的，但其具体实现逻辑和工作流程却因供应商而异，这种异构性使得对不同供应商提供的设备管控变得复杂。因此，我们通过构建光层标准化模型，以抽象出供应商特定的实现细节。该模型主要由两部分组成：逻辑模型和数据模型。

逻辑模型(Logic model)。第一个挑战是每个供应商的物理组件及其工作流程都是不同的。为了应对这一挑战，组件逻辑模型首先确定一组逻辑组件，这些组件在不同的供应商设备之间是通用的，然后模型进一步标准化这些组件之间的工作流程。

数据模型(data model)。第二个挑战是设备内部物理组件在功能相同的情况下提供的能力因供应商而异。例如，供应商 1 提供的光放大器的增益范围为 15-25 dB，而供应商 2 可能为 20-30 dB。这种异质性使得设备管理变得复杂。组件数据模型包含每个组件可配置参数的具体描述。当每个设备连接到控制器时，控制器从设备获取数据表并初始化相应的可配置参数值。

• 集中式数据收集(Centralized Data Collection)

标准化模型允许集中控制器直接访问异构设备，实现对各厂商设备的统一管控。TOOP的集中控制器由三个关键模块组成：全局管理组件、弹性数据采集组件和实时分析组件，用于及时大规模地检测和排除光学事件。

全局管理组件(Global manager)由两部分组成：设备管理器（DevMgr）和拓扑管理器（TopoMgr）。DevMgr 负责配置光学设备，利用相关的标准化模型以与供应商无关的方式配置设备。这个过程是通过Netconf协议向设备发送 Yang 文件实现。TopoMgr 维护光设备的物理拓扑，以提供全局光网络视图。

弹性数据采集组件(Scalable collector)由多个采集器节点组成的集群，旨在弹性地提供计算和存储资源以适应不同的采集频率和网络规模。借助腾讯云的弹性资源池，该组件可按需进行性能扩展。同时，该方式依靠负载均衡器在集群内各个采集器之间分配负载，有效应对单点故障问题。

实时分析组件(Real-time analytics)结合来自采集组件的光层数据和来自全局管理组件的拓扑信息来实现光层事件快速检测和定位的任务。实时分析组件的工作流程由两部分组成：事件检测和故障定位。为了检测劣化或故障事件，该组件实时监控光层性能指标的值，并在该值超过阈值时发出警报。同时，它会启动故障定位过程，该过程是基于预先采集的故障指纹来进行的。

图3: 光层流式遥测

02

流线型遥测管道(Streamlined Telemetry Pipeline)实时光层事件检测和定位需要从光学设备采集细粒度的数据。SNMP由于在资源受限的光学设备本地执行各种数据管理任务，无法实现细粒度的数据采集。相比之下，TOOP 通过基于推送的遥测管道将计算密集型数据操作从光学设备卸载到集中控制器，实现以更高频率收集光层数据。图 3 描述了基于推送的光层流式遥测架构。该流程主要由以下关键部分组成：遥测管理器、遥测代理、缓存组件和聚合组件。下面，我们将详细介绍它们。

• 遥测管理器(Telemetry manager)：将计算密集型数据管理任务从光学设备卸载到控制器往往需要在设备上进行初步配置。遥测管理器首先从集中控制器获取 YANG 文件，解析该文件以配置遥测代理和聚合器。聚合器配置为周期性地发起连接以将光层数据从本地缓存推送到控制器。遥测代理侧主要有三个部分配置：数据的目的地（即缓存），数据源（即线卡中的模块）和遥测代理应该推送的周期数据。

• 遥测代理(Telemetry agent)：一旦经过配置完成后，遥测代理会定期通过供应商特定的内部协议执行线卡级数据收集，并将数据推送到本地缓存。数据主要有两种产生方式：实时值和累积值。

  • 实时值是给定时间间隔内的采样数据。接收器捕获物理光信号并将其转换为模拟电流，模数转换器用于将模拟电流转换为电压的数字值，并进一步存储在 RAM 中。遥测代理定期读取 RAM 以通过供应商特定协议收集数据。

  • 累计值是给定时间周期内累积的计数值。数字信号处理器接收到的数字信号并以某种方式进行判定，将结果其累存入至寄存器中。

• 缓存组件(Cache)：该组件存储从遥测代理接收的性能数据，然后将数据以设备级进行捆绑。缓存组件可以兼容不同遥测代理在不同频率下推送的性能数据。

• 聚合组件(Aggregator)：该组件定期启动连接以从本地缓存中获取批量数据。由于缓存组件提供的数据更细粒度，聚合组件通过合并数据以获得具有代表性的统计信息，并通过 gRPC 协议将数据推送至控制器。

04 / 实验效果

综合评估

01

数据采集开销评估

图 4显示了在不同采集频率和不同性能指标下设备侧的 CPU 使用率。可以看出，采集频率从 1 秒增加到 0.1 秒，基于 SNMP 的方法会导致设备侧 CPU 使用率从 34% 提高到 96%，凸显了 SNMP 难以应对如此高频率的数据采集请求。相比之下，基于推送的光层流式遥测Telemetry方法，其导致设备侧 CPU的 使用率增长平缓，从 19% 增加到 25%，证明了基于推送的光层流式遥测Telemetry方法有效性。与此类似，对于不同数量的性能指标的采集，其光层流式遥测Telemetry方法依旧有效。

图4 设备侧CPU使用量

02

光层事件检测的有效性

Ephemeral Degradation (E-D)是短期劣化, Persistent Degradation (P-D)是长期劣化, Ephemeral Interruption (E-I)是短期中断，Persistent Interruption (P-I) 为长期中断。图 5和表1显示了在不同采集频率下检测到的事件数量和基于1秒和15分钟数据粒度下事件检测的正确性。从图5可以看出，随着采集频率从 15 分钟增加到 1 秒，检测出的事件数量会提升。对于E-I和E-D事件，粗粒度的数据往往无法检测到短暂光层事件。但对于长期中断和长期劣化事件，基于1秒粒度的数据检测出的事件量却小于15秒粒度数据检测出的事件量。这是由于基于粗粒度的数据无法检测出短暂光层事件。如表1所示，基于粗粒度的数据往往会把短暂光层事件误识别为长期事件。

图 5：不同采集频率下检测到的事件数量

表1：基于1秒和15分钟数据粒度下事件检测的正确性

03

光层事件定位的实时性

表 2显示了传统系统和TOOP系统定位事件的时间比较。可以看出，TOOP不仅能够将定位事件时间缩短至1分钟以内，相比于原来系统有2个数量级的提升。同时，TOOP能够发现一些抖动和劣化事件，这是传统系统无法比拟的。

表2：传统系统和TOOP系统定位事件的时间比较

04

光层事件的可预测性

图6显示了光层中断事件的可预测性。可以看出，对于5秒的窗口，如果该窗口内发生了 E-D 事件，则 P-I事件发生的概率会增加到 20% 左右，而对于1分钟的窗口，概率会增加到 40%，这表明 E-D 事件与未来的 P-I 事件密切相关。类似地，P-D 事件与未来的 P-I 事件密切相。另一个观察结果是，过去的 P-I 事件对未来 P-I 事件的预测性较低，这表明 P-I 事件是无记忆的。

图 6：光层中断事件的可预测性

05 / 总结

本文介绍了TOOP，通过标准化模型实现多厂商异构设备的集中控制，通过将数据管理任务从设备卸载到控制器实现秒级光层数据采集。通过近半年的部署，与现有系统相比，TOOP可准确检测出2倍以上光层事件。同时，TOOP实现秒级故障定位，相较原系统提升了2个数量级以上。

‍

‍

超强干货来袭 云风专访：近40年码龄，通宵达旦的技术人生