一 概述
近日，SIGCOMM 2020 公布了今年的入选论文，阿里云网络洛神的 “VTrace: Automatic Diagnostic System for Persistent Packet Loss in Cloud-Scale Overlay Network” 是国内历年来唯一一篇云网络方向的入选论文，今年 SIGCOMM 总计收到了 250 篇投稿，成功入选的仅 54 篇，阿里云网络洛神平台的技术实力得到了网络业界顶级会议的认可。
为了方便大家更通俗地理解这篇论文，本文将从技术层面解读云网络面临的问题，以及介绍 VTrace 系统的整体技术架构。
说明：以下介绍的所有技术都已在论文投稿前申请了专利保护。
二 背景
如果把每天在用的手机 App 当成现实生活里的商场，电影院，餐馆的话，云网络就是把这些商场，电影院和餐馆连接在一起的高速公路。在现实社会里，如果驾车去电影院时发现路堵了，可能会导致错过期待已久的电影。同样的，在云网络的世界里，当某个设备发生拥塞或者事故了，会导致各种 APP 应用出现异常、卡顿，视频打不开等。
而随着云网络拓扑日益复杂，承载的网络业务不断增多，虚拟网络承载着用户多种多样的业务功能，如 NAT、带宽等，往往要求频繁更新以满足用户业务变化。承载着基础转发能力的物理网络在转发策略中任何一个小小的问题都可能导致用户在云网络中的数据包丢失。而传统工具如 traceroute 等无法在云网络使用，而人为抓包的方式对运维工程师的专业技能和经验要求较高，排查过程也比较繁琐耗时，往往最终也只能界定丢包位置而难以得到丢包原因。
面对这样的问题，云网络需要一个”交通警察“，每当网络中间有拥塞或者事故了它需要能够及时发现具体位置，然后及时处理，来让整个网络恢复正常。一旦出现卡顿、丢包等问题，云网络的交警需要能在几秒钟内从这张遍布全球数百万的设备里找到原因，是非常大的挑战。
所以，不管是对用户而言，还是对云网络供应商来说，都急需一个可以在高负载、复杂拓扑的云网络下能实现快速响应的、可控的、自动化的丢包问题排查工具，而 VTrace 就是阿里云网络产品设计并推出的一款解决云网络持续性丢包问题的自动化诊断系统，就是我们所说的那个有着超级大脑的超级交警。
三 面临的挑战
动态变化的网络数据流
数据在网络里面的流转就像我们每天驾驶着车子在城市里穿梭一样，唯一的区别是网络里面的红绿灯和每个路口的方向会非常多，并且红绿灯的变化也不固定。用户可以随时修改网络的安全组来让数据包停下来或者通过，也可以通过修改路由来让某个路口增加一个分叉。想象一下在一个有 1000 个分叉，并且红绿灯在不停变换的路口时指挥交通就可以感受网络交警每天的工作压力了。
无处不在的潜在网络丢包点
在数据的传输过程中，一旦在某个地方发生拥塞，或者某个地方红灯了，就停下来无法前进。这个现象在网络里随处可见，对于只有几十个路口的小城镇，找到堵塞的路口可能不需要太久，但是对于云网络，这样的路口可能有上万个，想要快速找到拥塞的路口就非常困难了。
最小化性能影响
为了解决上面的问题，传统的做法会让数据在经过每个路口的时候都给交警发送一条短信，告诉他到哪了，然后现在是红灯还是绿灯，前面排队还有多久。但是这个做法首先成本太高，每天发送的短信可能就需要几千万条，另外，如果这个交警就拿着一部手机一条条记录信息，他也根本忙不过来。如何让网络数据包能以最低的成本最小的代价通知到网络交警，并且能快速处理这些数据包的信息，是需要找到一个很好的解决方法的。
四 设计与技术
目标与要求
基于面临的挑战，我们希望实现以下两个目标：
- 低损耗数据包信息、流量路径和传输质量分析：在不影响用户业务的情况下，分析数据包信息，流量路径以及传输质量，并精准探测网络传输的时延抖动。
- 精准分析丢包原因定位：当丢包发生，VTrace 系统需要快速找到有问题的虚拟网元或物理网元，并提出根本原因及修复丢包的可能。
考虑到云网络环境，对 VTrace 系统有以下几个要求：
- VTrace 能够基于数据包丢失的用户现场进行分析。
- VTrace 的部署和使用不会影响正常的网络功能，对用户无感知。
- 由于存在数百万云用户，VTrace 需要能够支持不同用户的并发使用 。
技术挑战
- 主动探测技术如 pingmesh，适用于网络监控场景，但很难满足基于用户数据丢失现象进行分析的要求，也很可能因为和用户数据包的差异性难以还原丢包路径。
- 被动式网络监控技术如 VeriFlow，对用户有依赖性，无法满足对用户无感知的要求。
- 网络调试技术如 SDN Traceroute、NetAlytics 等，目前不适用一些云网络架构，也无法做到直观地给出丢包原因。而一些旁路分析架构，如新提出的 INT 技术（In-band Network Telemetry），虽可以实现目标，但对网络设备的要求高，同时由于旁路导致的带宽消耗，会影响对用户的网络功能 。
设计思路
1 如何解决多网元节点的数据采集和汇聚？
在采集上我们使用了阿里云上成熟的日志服务产品（SLS），无需开发就能快捷完成日志数据采集、消费等功能，通过其强大的采集能力，将数百万的 VFD（虚拟转发设备）日志汇聚到各地域中心，便于后续的分析处理。
由于日志数据的实时性、分布式存储的地域性以及庞大数据量，需要利用大数据技术将所有数据收集以执行流量路径重建和进一步分析，我们采用了流处理引擎 JStorm，JStorm 具备千万级报文数据实时分析能力，其可扩展性和强大的计算能力有助于帮助潜在的大量 VTrace 任务进行实时的计算分析。
2 如何解决多租户并发的隔离以及探针对转发的性能损耗？
为了降低性能损耗，我们设计让控制器下发规则时，只需要起始转发节点生效，进行报文带内染色，而其他转发节点只需支持基于染色的匹配采集，另外也做了染色的快慢速分离和首包的规则匹配。针对虚拟转发设备则是预置规则，没有动态下发过程，对系统压力小。而在数据采集过程中，做一定的限速保护，并在任务中控制好包的数量，整体过程对转发的性能消耗降到最低，接着探针覆盖丢包位置，就可简单直接地采集到丢包原因。
3 如何解决分布式数据采集的时序问题？
在采集数据时，常会遇到日志流散列在不同地域，时序也无法保证的问题。因此我们在 VTraceApp 和 Jstorm 之间设计了一个三次握手过程，建立了“任务-染色-转发-采集-分析”的体系，确保大量分布式数据采集的正确性和时效性：
新建 VTrace 任务时，VTraceApp 向任务 DB 插入状态为 new 的一条任务。
Jstorm 读到 new 任务，将 new 改为 JStormReady。
VTraceApp 收到 JStormReady 后，向控制器发送下发 VTrace 任务的指令。
4 如何解决复杂转发模型下的自动算路？
首先，我们基于上云和下云的边缘标准设计出一套标准的排序算法，包含首尾节点标识、根据同节点数据的时序性以及不同节点的 NAT 转换关系。这样即使流量经过的设备和设备类型很多，只要虚拟转发设备安装了同款采集探针，不需做任何数据开发和调整，按照统一算法就可以实现路径的自动计算了。再利用安装的探针来采集每个数据包的时间指标，使用路径中时延计算的标准公式，结合可视化技术，实现一键呈现流量路径，快速分析丢包位置、丢包原因和时延情况。
五 覆盖场景
1 VPC 内的流量访问
经典场景：企业上云后，企业生产业务（部署在 ECS 中）往往需要和云上其他云服务如 RDS 数据库进行访问。
2 VPC 与公网之间的流量访问
经典场景：大部分的企业服务都需要被公网访问，如游戏服务等。
3 云上 VPC 与云下客户机房间的访问
经典场景：很多客户的部分服务可能有对外联设备的依赖，会部署在自建机房中，那么和云上环境有互通的需要。
4 不同 VPC 之间的访问（可能涉及跨域）
经典场景：大企业级组网，一般有多地域部署的需要，也会考虑生产环境/日常环境/运维管理区的隔离性，会把不同的环境部署在不同的 VPC 上，不同 VPC 之间互相访问的需要也是比较常见的。
六 总结
目前 VTrace 系统已经在阿里云网络内部大规模普及，效果显著，大大减少了诊断时间，从人为处理的平均几小时下降到分钟级的耗时，现在它已经成为云网络故障排查必不可少的工具，未来将会逐步开放给阿里云用户，让阿里云用户也能体验到 VTrace 带来的极速网络排障能力。
