重磅！解读国内唯一入选全球顶会SIGCOMM的阿里云网络论文 -一个渣渣

凌云时刻 · 技术

导读：SIGCOMM对论文要求极高，成功入选率不足25%。近日，SIGCOMM 2020公布了今年的入选论文，阿里云网络产品的《VTrace: Automatic Diagnostic System for Persistent Packet Loss in Cloud-Scale Overlay Network》是国内历年来唯一一篇云网络方向的入选论文。

作者 | 阿里云网络

来源 | 凌云时刻（微信号：linuxpk）

SIGCOMM

SIGCOMM，全称Special Interest Group on Data Communication，是美国计算机协会(ACM)组织在通信网络领域的旗舰型会议，也是目前国际通信网络领域的顶尖会议，由ACM SIGCOMM组织举办。

SIGCOMM对论文的质量和数量要求极高，要求具有基础性贡献、领导性影响和坚实系统背景，由于SIGCOMM录用的论文大多数都会被广泛引用、具有非常大的影响力，因此能在SIGCOMM年会上发表论文是通信网络研究者的非常高的荣誉。

在阿里云网络团队之前，云网络碰到类似问题只能用网工三板斧来处理: 抓包、ping、trace。这个方式在云网络上无论是性能上还是可操作性上都非常差，这也是让所有云网络工程师在排查问题时头疼的地方，传统的方式玩不转了。

阿里云网络产品团队首次采用大数据结合染色报文的方式，通过大数据技术给这个交警配备了一个超强的大脑，让他能实时处理千万级网络数据，同时，结合染色报文技术让所有网络里面的数据包信息实时传递给我们的云网络交警。最后的结果就是这个云网络交警能实时感知到整个云网络每台设备的丢包和拥塞情况。

阿里云网络产品团队给这个交警取了一个名字，叫vTrace。当用户在上网过程中碰到网络问题时，vTrace能很快找到对应链路上出现问题的节点在哪里，解决了云网络排查问题难的痛点，加快用户网络问题恢复过程。

论文详解

1. 概述

阿里云网络产品的” VTrace: Automatic Diagnostic System for Persistent Packet Loss in Cloud-Scale Overlay Network”是国内历年来唯一一篇云网络方向的入选SIGCOMM 2020文，今年SIGCOMM总计收到了250篇投稿，成功入选的仅54篇，阿里云网络产品洛神平台的技术实力得到了网络业界顶级会议的认可。

为了方便大家更通俗地理解这篇论文，本文将从技术层面解读云网络面临的问题，以及介绍VTrace系统的整体技术架构。

2. 背景

如果把每天在用的手机App当成现实生活里的商场，电影院，餐馆的话，云网络就是把这些商场，电影院和餐馆连接在一起的高速公路。在现实社会里，如果驾车去电影院时发现路堵了，可能会导致错过期待已久的电影。同样的，在云网络的世界里，当某个设备发生拥塞或者事故了，会导致各种APP应用出现异常、卡顿，视频打不开等。

而随着云网络拓扑日益复杂，承载的网络业务不断增多，虚拟网络承载着云租户多种多样的业务功能，如NAT、带宽等，往往要求频繁更新以满足租户业务变化。承载着基础转发能力的物理网络在转发策略中任何一个小小的问题都可能导致租户在云网络中的数据包丢失。而传统工具如traceroute等无法在云网络适用，而人为抓包的方式对运维工程师的专业技能和经验要求较高，排查过程也比较繁琐耗时，往往最终也只能界定丢包位置而难以得到丢包原因。

面对这样的问题，云网络需要一个”交通警察“，每当网络中间有拥塞或者事故了它需要能够及时发现具体位置，然后及时处理，来让整个网络恢复正常。一旦出现卡顿、丢包等问题，云网络的交警需要能在几秒钟内从这张遍布全球数百万的设备里找到原因，是非常大的挑战。

所以，不管是对云租户而言，还是对云网络供应商来说，都急需一个可以在高负载、复杂拓扑的云网络下能实现快速响应的、可控的、自动化的丢包问题排查工具，而VTrace就是阿里云网络产品设计并推出的一款解决云网络持续性丢包问题的自动化诊断系统，就是我们所说的那个有着超级大脑的超级交警。

3. 面临的挑战

如何计算租户流量的云网络拓扑？

如何计算租户流量的云网络拓扑？

云网络中的虚拟网元数以万计，数据包流量可能跨越多个数据中心分布在世界各地，而丰富虚拟网元（vSwitch、vRouters、vBRouters（虚拟边界路由器）、SLB等），使得租户在云上的组网可以灵活多变，而即便同一个租户不同的数据流也可能有不同的流量路径，例如SLB（负载均衡器）让流量路径无法预测，这些原因都对确定流量路径提供了不小的难度。

如何得到持续丢包问题的原因？

如何得到持续丢包问题的原因？

在云网络上的丢包，很多都来源于租户的个人配置或者误操作，而租户的行为和目的，对云网络提供商来说往往是难以分析的，由于租户体量庞大，云网络系统是动态多变的，云上的问题层出不穷，新问题不断出现，因此通过特征提取和建模来探索根本原因并不适用，也需要考虑成本等因素，以最小代价得到结果。

本身对网络转发性能的影响？

本身对网络转发性能的影响？

针对如此庞大体量的虚拟网元，由于问题可能发生在任何地方，为了达到诊断的目的可能需要修改大量网元设备，这种变化无可避免会影响网络功能，例如数据包转发、数据处理等，由于云网络租户共享云基础架构，系统应考虑对生产网络的影响，以防对服务质量产生影响。

4. 系统设计及实现

设计目标与要求

设计目标与要求

基于我们面临的挑战，具体来说，应该来实现以下两个目标：

在正常情况下，显示数据包信息及流量路径，没绝对的丢包也不代表没问题的，网络传输的时延抖动也是网络的常见问题之一，所以还需要分析数据包的传输质量
当丢包发生，VTrace需要找到有问题的虚拟网元（由此也能分析出物理网元），并提出根本原因及修复丢包的可能

在云网络系统中，可能有多种方式实施这样的系统，但是考虑到云网络环境，对VTrace系统有以下几个要求：

VTrace能够基于数据包丢失的用户现场进行分析
VTrace的部署和使用不会响应正常的网络功能，对用户无感知
由于存在数百万云租户，VTrace需要能够支持不同租户的并发使用

VTrace体系结构

VTrace体系结构

基于目标和要求我们设计了VTrace架构如图所示，整个系统由应用服务，控制器，虚拟转发设备（VFD），日志（代理）服务，JStorm流处理引擎及数据库组成。采用“任务-匹配-染色-采集-分析”的模式来实现能力，由应用服务来生成VTrace任务，控制器给起始转发节点（VFD1）下发染色规则，起始转发节点（VFD1）基于流信息与规则进行匹配，对用户报文进行染色，所有VFD都预定义规则，能够基于染色标识来采集数据包信息和设备上的丢包信息，日志服务借助日志代理能力自动同步设备上的采集日志，而使用Jstorm流处理引擎的目的是抓取VTrace任务和日志流，最后通过对VTrace任务和日志流的分析，实现流量路径的计算，丢包信息的呈现以及时延数据的分析。

数据生成与采集

数据生成与采集

在“任务-匹配-染色-采集-分析”的核心思想中，元数据的生成至关重要，这是分析流量路径、丢包信息及时延的基础。由于要在转发模块中考虑对网络性能高的影响，我们采用了动态下发染色规则给起始转发节点（VFD1），由VFD1来进行流匹配-报文染色的动作，这个模块只需要在安装在上云和下云边缘的VFD上，并且利用了缓存的能力实现规则匹配的最小消耗，而所有的VFD都预置了统一的规则，实现了快速识别-采集日志的能力，并尽可能的覆盖转发逻辑的出入口软件位置和已知丢包位置，在这些位置采集出关键的信息。

在采集上我们使用了阿里云上成熟的日志服务产品（SLS），无需开发就能快速地完成日志数据采集、消费等功能，通过其强大的采集能力，将数百万的VFD日志汇聚到各地域中心，便于后续的分析处理。

由于覆盖了软件转发路径，我们可以实现基于数据包丢失的用户现场进行采集，而这样的设计，染色和采集对网络性能损耗很小，能很好的满足对VTrace的部署和使用不会响应正常的网络功能、对用户完全无感知的要求，而实现不同租户可并发使用，就涉及到VTrace系统的数据分析模型了。

数据收集与分析

数据收集与分析

由于日志数据的实时性、分布式存储的地域性以及庞大数据量，因此，必不可少的需要一项任务将所有数据收集以执行流量路径重建和进一步分析。我们采用了流处理引擎JStorm，JStorm具备千万级报文数据实时分析能力，其可扩展性和强大的计算能力有助于帮助潜在的大量VTrace任务进行实时的计算分析，如图所示，我们VTrace设计中加入了两种采集器，VTraceTaskSpouts和LogSpouts分别负责实时提取VTrace任务数据库中的任务流和日志服务中的日志流，特别注意由于要实现可追踪任意云网络中的任务数据流，LogSpouts从Log收集日志流数据很可能是散列在不同地域。

根据云网络特性我们设计了多级Bolt分析模式，当VTraceTaskBolt被任务激活时，就开始收集任务相关的日志数据，对日志数据进行预处理（即过滤，转换，和分组），预处理后的数据会根据关键信息进行排序、算路、时延分析以及关联物理网元等信息，WriteBolt将结果存储起来，最后借助可视化的页面将结果呈现给用户，用户可以一目了然的看到问题数据流的流量路径及丢包详细信息。

其中由于考虑云网络转发中NAT属性，Bolt分析中的排序和算路等会涉及到一些复杂的算法这里不一一陈述，此文主要以系统模型和实现方案来进行解读介绍。