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