魏 航

（思科系统（中国）网络技术有限公司，北京 100022）

0 引言

随着数字化转型企业对云计算基础架构依赖程度的提高，融合了大数据和人工智能最新发展的智能运维（AIOps）逐渐成为提高基础架构服务质量的关键[1]。Gartner在AIOps的研究报告[2]中指出，AIOps平台应由监测（Observe）、处理（Engage）和行动（Act）三个部分结合大数据和机器学习组成一个闭环结构，而监测是触发整个闭环反馈的基础和关键，没有高质量的监测，就缺乏人工智能所需的大数据基础，因而也无法形成智能化的处理和相应的主动运维行为。但在性能飞速提升的数据中心，数据平面监测是一直以来的难点。本文将探讨在高速网络环境中进行数据平面监测的方法和发展趋势，为智能运维系统的建设提供参考。

1 传统方法的问题

长期以来监测数据中心网络采用的也是传统网络常见的周期轮询、周期探测、事件触发异常告警或事件触发主动探测等手段，其共同特点是采用从一个网管中心出发主动向被管节点拉取（Pull）数据的模式，能够以最低开销和可控数据规模收集一个管理模型所需的基本数据，SNMP（简单网络管理协议）网管、Syslog、Ping、Traceroute、SLA探针以及流量镜像分析工具等本质上都属于此类数据收集方式。其开销低、使用广泛，但缺点是不能展示业务流量的全貌，在轮询周期内或是探测包发送的间隙，都是数据收集的盲点；其次以CPU运行软件的方式，也无法在高速数据平面中更密集和更多维度的提供测量，导致在大型云数据中心内普遍出现的闪断丢包、流量微突发、延迟抖动等网络异常无法被侦测，累积形成的故障无法预警和溯源，这都对追求极致体验的数字化转型类业务构成了较大的威胁。

2 新兴的带内遥测技术

更适合大数据平台的数据采集方式不能以某个数据采集点为中心构建，而应当充分利用大规模分布式处理的思维，把从被管节点被动收集的Pull模式转变为被管节点主动向收集器推送（Push）数据的模式。该模式特点是充分发挥每个被管节点本地的处理能力，以更密集的时间粒度和更多维度的管理状态把本地信息向外报告，数据采集能力随着数据中心规模的扩展同步增长。这种分布式数据采集方法也称为“遥测”（Telemetry）。但即便采用分布式处理后，面对现代数据中心高密度、高带宽的带内数据平面的采集需求，仍然面临处理性能的巨大考验。因而普遍需要借助被管节点的大规模专用集成电路（ASIC），同时在收集和后续处理上使用由大量服务器构成的大数据分布式处理集群。下面将着重探讨在被管节点一侧的遥测技术。

在数据中心场景中被管节点往往是网络交换机，因而为网络设备制定硬件可编程语言标准的开源组织P4（p4.org）对带内网络的遥测（In-band Network Telemetry，INT）做了功能分类和定义[3]，基本涵盖了主流的INT技术实现方式。

2.1 INT eMbed Data（INT MD）

“内嵌数据”（MD）方式是指在用户带内业务数据包中内嵌管理数据，这样当数据包经过各个被管节点时便把路径上的状态信息附着在数据包中。到末端节点时，全路径上的管理信息会在数据包内形成一个逐跳堆叠起来的管理数据堆栈，末端节点再将该数据堆栈取出，封装到连接收集器集群的隧道中完成信息的推送。

在工程实践中，为避免附加数据堆栈给用户关键业务数据包带来额外的处理和转发延迟，也为避免MTU溢出风险和改动业务包负载引起的安全合规顾虑，往往采用不触碰原始数据包，而是在起始节点将原始数据包的包头克隆出来形成新包，将逐跳的管理信息附着在新包上。这样由于包头相同，新的管理包仍沿与业务数据包一致的路径收集信息，达到与后者收集信息近似的效果。

MD方式的优点是获取了全路径上最接近用户实际传输状态的第一手信息，而且信息载量理论上可以非常大，因而功能强大且可扩展。但这种机制也有明显缺陷，首先网络异常出现频率相比数据包转发频率相距悬殊，因而逐包携带信息的冗余度非常大，大量重复的数据对末端节点的导出和收集器的分析也是巨大的压力；但采用抽样的方式又可能错过各种突发和趋势变化等重要信息；而且也要考虑到数据包可能因为安全策略、队列拥塞等原因被中途丢弃，因而没有一定程度抽样密度是达不到大数据所需的数据量要求的。

因而MD方式在起始节点要精心设计算法，过滤出对业务有潜在冲击、值得逐包监控的流，同时对携带的信息类型也要做权衡；在末端节点还需有复杂的去重机制以减轻自身和收集系统的压力，比如通过统计分析算法得出更加明确的异常事件而非将每一个包的全量监测信息上报。整个机制增加了网络边缘设备的资源占用和处理的复杂性，而边缘往往是低端接入设备，硬件成本是极大挑战。

2.2 INT eMbed instruct(X)ions（INT MX）

如果沿业务流路径携带的并非管理数据本身，而是管理指令（信令），被携带数据量可大幅缩减，甚至可直接嵌入到用户数据流包头字段而无需复制现有数据流，这种方式称为“内嵌指令”（MX）。明显MX对设备的处理能力和资源要求都较低，但指令必须与设备自身功能配合，也限制了管理的通用性，因而更多被用于对特定关键指标的测量，比如端到端的丢包与延迟。

与传统Pull模式引入外来探测包的测量方式不同，MX方式通过嵌入指令实现用真实用户数据包作为测量探针，不仅避免引入干扰，也让数据更为真实。常用“周期着色”法，比如每30秒对起始节点发出的数据包打上特定测量标记，同时所有末端节点对流入的有特定标记的包进行统计，然后收集器对发出和收到的标记包数进行差值计算，就可精确的确定单位周期真实的丢包数量。由于不同周期的标记不同，所以不同周期的计数不会因为传输延迟而混叠。如果该过程加入了高精度时间同步协议（PTP），则可在初始节点和末端节点验证时间戳差值而统计出延迟和抖动。

MX方式用较低的开销实现了全路径、全流量的测量，但其功能有限，比如丢包延迟的精确位置、原因等信息无法给出。

2.3 INT eXport Data（INT XD）

“输出数据”（XD）方式则力求在开销和功能之间找到平衡点。XD方式不将管理信息携带在每个用户数据包内，而是由每个被管节点直接把管理信息推送给收集器。这样做的优势是将处理分散到所有中间转发节点而非集中在起始和末端，每个转发节点尽可能简化处理，比如无须分析大量历史数据，而是仅处理一个短时间周期（如1秒）的信息；无须处理端到端全路径信息，而仅处理本跳局部信息；无须逐包处理，而是对归并后的流（比如按五元组归并）处理管理信息，这样可以大大降低每个节点的资源占用和处理复杂度，而全景化的汇总、关联、拼接、分析等工作交给收集器所在的大数据集群完成。所以XD理论上可以提供较高的信息载量和灵活的功能扩展，却不过多消耗节点资源，因而可以在包括低端接入设备在内的全网内全时、全量开启，更具实用价值。

XD也有一些制约，其信息碎片化程度高，大数据集群在关联拼接时需要网络有预设的拓扑或具备PTP时间戳以便排序；在分类批次设计中五元组流表与转发流水线的硬件整合也是难点，一方面需要对关键指标完成实时统计、事件触发和流表记录，同时对资源占用和处理性能要求要能适于部署在低端边缘设备上，这些都需要更高水准的硬件芯片设计来实现。

3 商用化现状和未来发展

INT MD功能全面，但对资源和处理性能要求高，商用化多实现在12.8T-25.6Tbps级别的单芯片系统上；INT MX相对轻量化，但功能有限，对系统功能整合度要求高，多实现在厂商特定功能集内；INT XD做到了功能和开销的相对平衡，但对芯片设计要求高，采用不同权衡策略的芯片功能差异也较大，需要不同企业在AIOps设计时根据需求详细考查。从未来发展上看，通用企业数据中心会偏重将带内遥测通过XD方式实现，而运营商和互联网企业在升级到100/200G接入或普遍引入智能网卡之后，会重点考虑MD功能。当然工程上的实现并不绝对，不同解决方案会走向某种模式为主、其他模式补充的混合形态，以追求性能、功能与代价的最优平衡。