网络前沿技术讲座报告（顶会论文虚拟网络探测技术的探索与实践）

作者：吕彪 阿里云网络齐天负责人

云网络由物理网络和虚拟网络共同组成，两者都会影响网络性能。过去的研究主要集中于解决物理网络探测，而在虚拟网络探测领域的相应研究则较少。本文将为大家分享一种专为大规模多租户虚拟网络设计的主动探测系统Zoonet，从技术层面解读Zoonet系统的设计背景、面临挑战、技术架构，以及大规模部署的经验分享。

近日，阿里云洛神云网络的一篇论文“Zoonet: A Proactive Telemetry System for Large-Scale Cloud Networks” 被 ACM CoNEXT 2022 会议录取。今年CoNEXT总计收到了151篇投稿，成功入选28篇，录取率仅为18.5%。该论文在大规模虚拟网络探测领域作出了全球领先的研究探索，并且基于该研究的Zoonet网络探测系统已在阿里云全球数据中心部署应用。

为了方便大家更通俗地理解这篇论文，本文将从技术层面解读Zoonet系统的设计背景、面临挑战、技术架构，以及大规模部署的经验分享。

一、背景介绍

如今的公共云已成为整个社会的基础设施，可以同时为数百万租户提供服务。其中，云网络可以帮助每个租户构建可靠以及租户隔离的网络环境，使得租户可以互不干扰地运行自己的应用程序以及互相通信。云网络由底层的物理网络（physical network）和上层的虚拟网络（virtual network）共同组成。物理网络主要提供基础网络的连接能力，而虚拟网络可以为租户提供更高级的网络服务，比如网络地址空间隔离、虚拟路由转发、多IP共享带宽、Internet访问接入、租户级跨地域网络、租户级混合云网络等。由于物理网络和虚拟网络都会影响租户的网络性能，因此云厂商有必要对两层网络都进行探测，以保障租户的服务水平协议（SLA）。

通过文献调研，我们发现之前的研究主要解决物理网络探测的问题，比如Pingmesh[SIGCOMM'15]、Everflow[SIGCOMM'15]、007[NSDI'18]、dShark[NSDI'19]、NetBouncer[NSDI'19]等。而在虚拟网络探测领域，相应研究非常少。我们调研发现只有一篇VNET Pingmesh[IMC'18, short paper]尝试做虚拟网络探测。但是它只做了初步的方案设计和部署，并没有探讨以及解决大规模虚拟网络探测所面临的问题，比如虚拟网络的快速更新、对异构中间件（middlebox）的支持、租户级公网以及跨地域网络探测、完整的VM-VM探测链路覆盖等等。

因此本文提出一种专为大规模多租户虚拟网络设计的主动探测系统Zoonet。该系统包含云网络全网的覆盖性探测以及针对异常链路的按需探测。覆盖性探测以有限的带宽开销提供高路径覆盖，对冗余路径和路由/ACL限制路径进行剪枝，然后使用最简单的端到端探测模式。而按需探测实现网络异常的快速定位，对异常路径启动逐跳模式的探测。特别的，Zoonet在如下几个方面有亮点设计：

• Zoonet支持异构的中间件。云网络中存在大量的异构中间件，因此Zoonet设计了一套通用探测模型，可以帮助这些中间件快速适配Zoonet。
• Zoonet虚拟网络快速拓扑更新。为了处理频繁的拓扑更新，Zoonet订阅了拓扑变化的信息，并采用了一系列优化策略以提高更新效率。而对于更新不及时带来的测量噪音，Zoonet通过验证最新拓扑的方式来进行过滤。
• Zoonet通过不断扩展探测边界来发现更多的虚拟网络场景问题。除了普通的私网、跨地域等场景，Zoonet还支持对公网、有状态中间件、虚拟机“最后一公里”等场景的探测。

Zoonet已经在阿里云部署了两年多，覆盖了数十个地域。在部署期间，Zoonet 发现了许多有趣的案例，包括虚拟网络协议栈错误、虚拟网络拥塞、虚拟路由异常、物理网络故障和虚拟机“最后一公里”异常。由于很多疑似网络问题并不是真正由网络引起的，Zoonet帮助云厂商在最大程度上实现了自证清白。

二、物理网络探测局限

多数人直观的感觉是可以通过物理网络探测结果来推测虚拟网络的状况，但是接下来我们会具体分析物理网络探测存在的局限，说明我们为什么必须要做虚拟网络探测。

2.1 物理网络探测无法覆盖虚拟网络协议栈问题

如上图所示，在物理主机上，物理网络协议栈和虚拟网络协议栈是分开实现的。物理网络协议栈基于内核转发的。在阿里云早期，虚拟网络协议栈是在用户空间和内核空间共同支持实现的。如今，为了实现更高性能的转发，虚拟网络协议栈完全在用户空间实现，使用基于DPDK的内核旁路模型。这样虚拟转发路径就与内核空间完全解耦了。由于物理网络探测仅通过物理网络协议栈发送探测，因此无法检测虚拟网络协议栈的问题。

2.2 虚拟网络和物理网络之间没有精确的拓扑映射

上图给出了一个拓扑映射的例子。虚拟网络中一个简单的VM到VM路径对应于物理网络的四个底层ECMP路径。在这个例子中，即使物理网络检测到一条路径已经中断，也很难推断虚拟网络是否有问题，因为流量可能会旁路底层中断的路径（例如，flow 2）。更糟糕的是，即使我们注意到一个flow正在虚拟网络中丢包（例如，flow 1），我们也无法确定有故障的物理路径位置，因为四个ECMP路径弄乱了虚拟和物理拓扑之间的映射关系。

2.3 物理网络探测可能会旁路中间件

上图显示了阿里云的物理网络拓扑，其中包含物理服务器、交换机、地域边界网关和挂载在负载均衡器下的各种中间件。在这样的拓扑中，中间件被部署为远离物理服务器和交换机的独立设备。将流量转发到这些中间件需要在发送方额外重写数据包目标地址。也就是说，依赖于主机启动的端到端探测方法将绕过这些“off-the-path”中间件。

2.4 物理网络探测无法覆盖基于租户粒度的跨地域网络或Internet边界

一个阿里云的租户可以购买多个VPC，分布在不同地域，通过跨地域网络连接。然而，地域内的物理网络探测无法覆盖地域边界网关以及租户粒度的跨地域网络，无法为特定租户提供跨地域端到端故障排除。同样的，虚拟机与互联网之间存在巨大的流量需求，因此云厂商需要解决租户对网络故障发生在云端还是ISP端的疑问。因此，网络探测应该覆盖云和Internet之间的边界，以消除这种疑问。然而，物理网络探测无法完成这个需求。

三、虚拟网络探测挑战

进行虚拟网络探测，尤其是像阿里云这样大规模的虚拟网络探测面临非常多独特的挑战，照搬物理网络探测的方法是不可行的。接下来我们简单介绍一下具体的虚拟网络探测挑战。

3.1 在超大规模虚拟网络上实现低开销的探测

一个大的云地域在物理网络中包含数十万台服务器。然而，虚拟网络通常包含更多的虚拟节点。首先，一台物理服务器可以虚拟成数百个虚拟机（如果使用ENI trunking技术，一个虚拟机可以进一步托管多达1024个容器）。其次，虚拟网络为海量租户提供服务，例如一个地域服务数百万租户。第三，对于大的租户，单个VPC可以容纳超大规模的虚拟节点（例如，大于50万个虚拟机）。根据我们的分析，在这样大规模的虚拟网络下进行探测，采用传统探测方案的开销将比物理网络探测高出三个数量级。

3.2 适应虚拟网络拓扑的快速更新

物理网络的拓扑相对稳定。根据我们的经验，阿里云物理网络的更新频率大约是每月几千次。相比之下，由于大量的活跃租户以及灵活的管理API，虚拟网络的拓扑结构变化非常快。如上图所示，租户的资源分配和释放在云地域中每小时触发数万次虚拟网络拓扑更新。对于探测系统，频繁的虚拟网络更新会导致额外的开销：1）基于租户配置的实时拓扑重新计算；2）根据拓扑更新实时计算端到端探测路径；3）从控制器实时下发探测路径带来的大规模带宽开销。

3.3 多服务和多中间件覆盖

对于物理网络中的二层和三层设备，一般是基于无状态转发规则的数据包转发，比较方便实现出、入双向探测。但是，虚拟网络包含多种有状态的中间件，他们就不能实现简单的出、入双向探测。比如基于会话（session）的中间件，在客户端发送会话的第一个数据包之前，这些中间件中没有会话关系，因此来自服务器的数据包不能通过中间件正确转发。例如，虚拟机依赖SNAT（由NAT网关提供）访问互联网，但互联网无法主动访问虚拟机，除非建立SNAT会话。此外，不同的中间件可以有不同的实现，甚至可以在不同的平台（例如，裸机、NFV、FPGA、ASIC）中构建相同功能的中间件。因此虚拟网络探测框架需要适应中间件的异构性。

3.4 租户无感的VM到VM探测

对于物理网络，端到端意味着主机到主机，而对于虚拟网络，端到端意味着虚拟机到虚拟机。对于物理网络探测，可以在终端主机上的操作系统进程中实现探测任务生成或数据采集功能。但是同样的方法不能直接应用于租户的VM，因为云厂商不能侵入租户的虚拟机，必须要保护用户隐私。但是，如果没有VM嵌入式探针，端到端路径的“最后一公里”将无法轻松覆盖。我们下文中会讨论使用ARP Ping来解决这个问题。

3.5 区分虚拟和物理网络问题

当网络发生异常时，需要区分是虚拟网络问题和物理网络问题，以缩小故障范围。在物理网络中，我们可以依靠traceroute进行逐跳的测量诊断。然而，将traceroute扩展到虚拟网络时，即使它返回了虚拟网络中与精确跳数相关的丢包，我们仍然无法确认是到底是虚拟设备问题还是底层物理设备问题，因为在两个相邻的虚拟网络设备之间存在物理网络域。在本文中我们通过专门设计的Zoonet逐跳模式来解决这个问题。

四、Zoonet解决方案4.1 整体设计

如上图所示，Zoonet由数据平面和控制平面组成。数据平面接收来自控制平面的探测任务，然后主动注入探测数据包来检测虚拟网络。一个探测任务的探测路径是从vSrc通过多个vBox到达vDst。vSrc和vDst是虚拟探测点，由Zoonet-agent（自主开发的运行在宿主机上的程序，独立于VM hypervisor）实现。vBox是指一系列虚拟网络中间件（如管理程序、负载平衡器、NAT网关、Internet网关等）。在Zoonet中，对vBox的特殊支持可用于异常路径的快速定位。为了覆盖Internet探测，Zoonet通过在云边界设置探测点pDst来扩展探测边界到ISP。pDst可以模拟Internet对探测包进行回包。

控制平面由三个模块组成：探测任务规划器（Telemetry task planner）、探测拓扑分析器（Telemetry topology analyzer）和探测数据分析器（Telemetry data analyzer）。探测任务规划器负责常态化探测和按需诊断探测的任务规划。探测拓扑分析器负责所有租户的虚拟网络拓扑计算和潜在的探测路径分析。它还必须根据租户的拓扑更新操作来更新拓扑和路径。探测数据分析器负责从数据平面收集探测数据以进行深入分析，并在发现异常时发送告警。为了消除更新不及时导致的无效探测任务，需要在告警前读取最新的拓扑进行一致性校验。

4.2 Zoonet数据面4.2.1 探测任务

Zoonet 的数据面接收并执行控制平面下发的探测任务。一个探测任务被定义为：

Task=Probing(vSrc,vDst,options,modes)

其中vSrc和vDst是一个探测任务的源点和结束点，它会经过多个中间节点(vBox)。在大多数情况下，vSrc和vDst就是指VM，vBox是指虚拟网络中间件。为了实现租户无感，Zoonet的端到端探测开始和结束于VM代理（即Zoonet agent）。在Internet探测中，vDst也可以是Internet网关的VIP或放置在Internet边界附近的物理探测设备pDst。options定义如何封装和发送探测数据包，例如间隔、数量、探测包大小、协议等。modes定义vBox如何对探测数据包作出回应。使用options和modes，控制平面可以编程实现如何探测数据平面。

Zoonet包含如下三种类型探测数据包：

• 请求数据包（Request packet），从vSrc到vDst的探测包；
• 回复数据包（Response packet），从vSrc到vDst的探测包；
• 报告数据包（Report packet），携带探测数据的报文，vBox在收到请求或回复数据包时有可能会发送报告数据包。

同时，为了简化vBox上的探测逻辑，端测的vSrc会负责所有与控制平面交互，包括探测数据包的生成与注入、计算探测的延迟和丢包等。vBox只负责执行探测包转发和报文回复。

4.2.2 探测模式

简单的端到端探测不足以涵盖所有云探测场景：

1）云网络有大量的有状态中间件，而无状态探测只能从一个方向监控虚拟路径；

2）现有解决方案只提供地域内的探测覆盖，而互联网边界是目前探测的盲点；

3）端到端探测可以检测异常路径，但故障发生时，无法定位确切的故障点（即设备/链路）。

为了满足这些探测需求，Zoonet开发了三对原子探测模式，如上表所示。在这些模式中，One-Way和PingPong模式表示单向或双向探测，Non-Transparent和Transparent模式表示是否把探测边界从vDst扩展到pDst，End-to-End和Hop-by-Hop模式表示转发路径上的每个vBox是否会参与探测过程。三对探测模式有8种组合，我们在下面举例说明其中4种常见组合用例，以及对应常见的云网络探测场景：

举例一：常态化探测，无状态中间件。在常态化探测用例中（OW EE NT的模式组合），vSrc发送请求探测数据包，该数据包经过端到端路径到达vDst。vDst然后向vSrc发送report报文。请注意，在常态化探测情况下，vBox只转发探测报文。对于全网虚拟路径覆盖，默认情况下启用常态化探测。

举例二：常态化探测，有状态中间件。在有状态探测用例（采用PP EE NT的模式组合）中，除了报告数据包，vDst还会发送一个回复数据包。此类用例主要用于对有状态中间件（如 SNAT）进行探测。请注意，PingPong不等同于双向进行的两个单独的单向探测。因为在有状态中间件建立会话前，数据包从反向进入会被丢弃。

举例三：常态化探测，Internet边界。在Internet边界探测用例（OW EE TR模式组合）中，我们依赖Transparent模式和pDst进行Internet边界探测覆盖。探测包会在通过vDst之后进一步转发到pDst。在这里，我们并没有将pDst放置在Internet上（例如，在ISP的机房中），主要是因为Internet上的pDst是云厂商无法控制的，即使监控到路径故障，我们也无法确定网络异常是发生在云端还是ISP网络。在Zoonet中，我们将pDst放置在Internet边界附近的公共云中。

举例四：按需诊断探测。在按需诊断用例（OW HH NT的模式组合）中，与前面用例不同的是，从vSrc发送的请求包将触发转发路径上的每个vBox回复报告包。这种Hop-by-hop的方式与traceroute类似，但具有更清晰和更通用的设计。具体来说，报告数据包由vBox发送两次，一次在ingress方向，一次在egress方向。这种设计可以快速区分链路故障和节点故障。假设来自ingress和egress的两个报告数据包遇到不同的问题，则故障发生在该节点。否则，肯定是中间一段链路发生了故障。由于一条虚拟链路对应一个物理网络域，因此Zoonet的Hop-by-Hop模式可以区分出物理网络与虚拟网络问题。Hop-by-Hop在vBox和控制平面上都是计算密集型的。因此，最好先使用End-to-End进行网络覆盖探测，然后使用Hop-by-Hop进行异常定位。

4.2.3 其它数据面支持

• Zoonet协议：我们自研了一套虚拟网络探测协议，该协议的数据包格式已在论文中公开。
• Zoonet agent：自研开发的收发包代理软件，部署在VM宿主机上，是一个独立进程，并且有专门绑CPU控制核。这样可以有效避免对租户以及租户VM造成干扰和影响。
• VM hypervisor：识别Zoonet数据包之后，主要封装、解封装隧道包头，以及打上一些标记位。
• 中间件：软件中间件比较好支持Zoonet。对于一些可编程中间件，比如Tofino芯片，由于它们的片上资源有限，一般会把Zoonet数据包送给控制面处理。
• 最后一公里探测：从Zoonet agent发出的探测包无法覆盖从VM到hypervisor这一小段容易被忽视的链路，我们使用ARP探测解决这个问题。之所以选用ARP探测，是因为ARP协议是非常底层且基础的协议，一般的VM都默认支持。

4.3 Zoonet控制面

Zoonet的控制面主要解决如下三个问题：

• 探测任务产生的巨大测量开销；
• 频繁拓扑更新带来的问题；
• 探测数据采集与消费的巨大开销。

4.3.1 分层探测路径规划

在讨论Zoonet如何计算探测路径之前，我们先来看一下云网络的拓扑结构。上图显示了阿里云中一个租户的虚拟网络概况。我们可以看到VM是挂载在虚拟交换机上的（虚拟交换机是一个逻辑节点，理论上承载的虚拟机数量是无限的）。一个地域内的虚拟交换机之间的链路是全互通的。分布在不同地域的多个VPC可以通过跨域链路连接。此外，虚拟机还可以通过公网IP或SNAT访问Internet。接下来我们讨论Zoonet如何通过分层探测的方法降低探测开销。

• 层次一：同一个虚拟交换机下的VM 成对探测。如果每个虚拟交换机下的VM可以fullmesh相互探测，会导致O(n^2)探测复杂度，其中n表示虚拟机数量。而对于虚拟网络，虚拟交换机下的虚拟机数量是理论上是无限的（我们在实际部署中已经观测到了数千个虚拟机连接到同一个虚拟交换机）。因此，fullmesh探测会遇到探测复杂度问题。Pingmesh可以在同一ToR下的服务器之间进行fullmesh探测，是由于每个物理ToR都有固定数量的端口，所以探测复杂度得到了很好的控制。为了减少探测开销，在每个虚拟交换机上，我们将VM分成两组，每组数量相等，并进行VM成对探测，这将探测复杂度从O(n^2) 降低到O(n/2)。此外，我们有意根据虚拟机在不同服务器上的分布对虚拟机进行区分，以保证最大程度的跨物理服务器探测。
• 层次二：虚拟交换机之间的fullmesh探测。为了完全覆盖虚拟网络，一个直接的解决方案是对虚拟网络中的每个端到端VM进行fullmesh探测。然而，这样的fullmesh探测开销太大了。为了降低复杂性，我们使用了聚合探测。具体来说，fullmesh探测可以从聚合级别的虚拟交换机发起，而不是从叶节点的VM发起。
• 层次三：跨地域路径剪枝。租户会在地域边界网关设置路由/ACL配置以限制跨地域流量。这样一来，虽然跨地域通信的underlay网络是fullmesh，但是overlay网络流量不会走所有的路径。根据这种overlay网络特点，我们基于路由表和ACL规则进行跨地域路径剪枝，以进一步降低跨地域探测的复杂度。
• 层次四：VM到VM的top-N热点路径探测。我们发现云网络流量遵循二八定律，即大多数流量由少数路径承载。利用这一点，我们可以进一步优化探测策略。具体来说，我们可以定期分析流量日志，选择前N个VM到VM热点路径作为关键探测路径，这样可以经济高效地覆盖大部分流量。top-N路径覆盖可以很好的补充之前的路径规划策略。

4.3.2 频繁拓扑更新

上图显示了拓扑更新的过程。租户更新操作将影响虚拟网络的所有方面，例如：

• 虚拟网络实例，如VPC、虚拟交换机、VM等；
• 地域内、跨地域、接入Internet/IDC的路由；
• 其它如ACL、每个租户的Internet带宽等。

当虚拟网络配置发生变化时，它们将被推送到探测拓扑分析器。由于更新频率很高，不可能在每次更新到达时都做出响应。因此，Zoonet使用消息队列来缓冲最近到达的更新，并以一定的时间间隔批量读取。在处理更新时，我们执行以下策略来提高效率和准确性：

• 策略一：删除与拓扑无关的更新。有一些租户的变更不会影响虚拟网络的拓扑，例如租户调整上网带宽。这样的更新会从消息队列中移除。
• 策略二：删除add-del更新。对于从消息队列中读取的一批更新，如果有相同实例、路由或其他配置的先加后删或先删后加，我们会识别并一起移除。
• 策略三：按 VPC 粒度聚合更新。探测拓扑分析器从设备控制器订阅拓扑更新。设备控制器是为了高可用性而分布式实现的，这可能会导致更新的无序到达。例如，探测拓扑分析器可能会收到在 VPC 中创建 VM 的更新，但相应的 VPC 创建事件可能会在下一轮才能从队列中读取，这将导致更新错误。我们的解决方案是按照VPC粒度聚合所有从队列中读取的更新。

4.3.3 探测数据采集与消费

Zoonet 使用分布式流处理框架Flink来实时处理云规模的探测数据。通过部署更多计算单元，Zoonet可以轻松地扩展数据分析器以应对不断增长的工作负载。最初，我们利用一个统一的用户定义函数（UDF）来解决所有探测模式的数据处理。然而，不同探测模式的计算复杂度差异是很大的。在分析了不同探测模式调用频率和计算开销之后，我们为Hop-by-Hop模式设计了一个专用的UDF，为其他模式设计了一个更简单的Flink SQL。当这样的计算逻辑分离之后，Zoonet的计算成本降低了75%。

五、线上部署发现的问题

Zoonet已经在阿里云生产系统大规模部署超过两年的时间。在此期间帮助我们发现以及修复了很多网络问题。下面我们将根据其中一个月内基于Zoonet发现的307异常案例来进行分享。我们总共将其划分为6个大类：

5.1 虚拟网络协议栈错误

由于物理网络探测不通过虚拟网络协议栈，所以Zoonet检测到了很多物理网络探测方法无法发现的虚拟网络协议栈错误，这些错误又可以细分为如下三类：

• 终端主机上的错误。云网络是高度动态的，每小时在一个地域产生数万个拓扑更新。当发生拓扑更新时，终端主机也需要更新它们的配置表。在实际部署中，Zoonet帮助检测到许多在终端主机的控制和数据平面之间存在配置不一致的情况，其中大部分会影响租户VM的流量转发。例如，Zoonet曾经检测到由于带宽配置错误导致的VM数据包丢失。我们当然可以在每台终端主机上启动表项对比发现此类错误，但由于表项数量很多，表项对比时间会很长。Zoonet可以更及时地帮助我们发现此类问题。
• 中间件上的错误。在中间件的开发过程中，会不可避免地引入系统错误。虽然我们会在中间件上线前做大量的测试，但是对于一些灰色故障（gray failures），尤其是那些只涉及特定租户、虚拟机或流量的故障，我们要花很长时间去定位，甚至很多时候无法发现。借助Hop-by-Hop模式，通过不同参数的海量任务，Zoonet极大提高了发现灰色故障的概率。最近一个月，Zoonet帮助我们发现了10起因SDN控制程序错误导致的中间件配置错误。这些错误仅由特定租户触发，使用传统方法极难定位。例如，Zoonet检测到一个租户的SNAT哈希函数配置错误，导致该租户无法建立新的SNAT会话。
• 虚拟网络升级程序的错误。云网络对外提供灵活的网络业务，为不断适应新的网络业务，通常会经历频繁的升级。其中一小部分使用冷升级，我们有足够的时间来验证升级是否成功。但是大部分虚拟设备使用热升级。由于热升级带来的业务短暂中断或升级失败有时候是在所难免的。但是我们希望可以尽早发现它，然后通过快速回滚或绕过故障点以减少损失。有了Zoonet之后，我们会在升级过程中通过持续不断的Zoonet带内监控来反映当前的网络服务质量，一旦发现问题就可以快速响应。

5.2 虚拟网络拥塞

租户在公共云上构建租户互相隔离的网络环境，进而独立运行应用。但是虚拟网络拥塞可能会通过耗尽底层共享资源来打破这种隔离性。在所有网络拥塞情况中，CPU过载是最常见的一种。许多虚拟设备基于CPU转发。但是由于单核性能有限（例如1Mpps），大量突发流量可能会耗尽CPU并导致虚拟网络拥塞。虽然通过监控CPU利用率很容易检测到此类问题，但如何准确评估影响范围（例如，有多少受影响的租户/VM/服务）是一个未解决的问题。Zoonet通过将异常探测任务与租户信息匹配到拥塞组件来解决这个问题。例如，在一个线上案例中，当中间件的CPU内核过载时，Zoonet精确检测到157个相关任务出现丢包（通过该中间件任务总数的3%）。

5.3 虚拟路由异常

虚拟网络会为引流对外发布几种类型的虚拟IP(VIP)。具体来说，中间件集群会将VIP发布给云的其余部分，而公共云会将公共IP通告给ISP。通常情况下，这些VIP发布对租户是透明的。但有时，异常的路由通告（如路由配置错误）会影响租户的流量转发。在一个案例中，互联网服务中间件集群的VIP发布异常导致少数租户网络转发的静默丢包。Zoonet通过检测多个Internet实例的明显丢包来帮助识别此类异常。

5.4 虚拟链路故障/物理网络故障

Zoonet可以区分虚拟节点故障和虚拟链路故障。在实际部署中，Zoonet帮助检测到很多虚拟链路故障。由于虚拟链路由多个物理交换机和链路组成，它们也可以叫物理网络故障。物理网络探测可以检测到这些网络故障，但是，物理网络探测无法将它们与租户/虚拟机/服务相关联。例如，如果物理网络探测检测到ToR switch down事件，则无法确认该事件是否影响某个租户业务的包转发，因为有可能故障ToR的流量被静默切换到备份ToR。在这种场景下，如果Zoonet检测到相应的虚拟链路有明显的丢包，Zoonet可以更准确地推断出ToR down事件影响了租户的数据包转发。

5.5 VM“最后一公里”异常

VM和hypervisor之间的“最后一公里”主要有两种问题，即VM异常和virtual-queue（VM和hypervisor之间的队列）异常。通常此类问题是由底层协议栈和隐藏的错误引起的，一旦发生就会影响成千上万的终端主机。我们使用ARP Ping来覆盖“最后一公里”。在实际部署中，我们发现ARP Ping延迟不稳定，受VM和宿主机的CPU使用率影响。因此，我们主要依靠ARP Ping的丢包率来检测问题。上图显示了VM内存异常事件期间的ARP Ping延迟和丢包率。可以看出ARP Ping的延迟在100~300微秒左右抖动，而丢包率在确切的异常点达到100%。

5.6 自证清白

租户投诉的疑似网络问题，实质原因是租户的流量超过了购买的带宽/会话配额、或是自身配置错误以及自己的应用问题。我们也遇到过疑似网络问题最终被诊断为VM问题或ISP网络问题。这些案例虽然不是网络问题，但在我们的异常排查工单中占据了很大一部分，消耗了大量的研发人力。Zoonet通过大范围虚拟网络主动探测覆盖虚拟网络路径，提高了云网络主动性自证清白的能力。并且我们一直在将探测边界进行扩展，预期可以实现更高范围的自证清白。

六、经验分享

经验一：虚拟网络拓扑更新有非常多的corner case。在Zoonet的设计之初，我们考虑了可能导致虚拟拓扑变化的事件，例如VM关闭、VM释放、VM迁移等。但是，云服务的复杂性导致很多corner case令我们根本没想到。例如，一种情况是VPC之间的VM迁移，这最初被认为是不可能的，因为VM总是被认为与其VPC绑定。另一个没有考虑的情况是，如果检测到虚拟机有网络攻击行为（或被攻击），其虚拟IP将被封禁。上图显示了由于corner case覆盖不全而导致的异常探测任务（即探测噪声）的比例。Zoonet经历了先小规模部署，再大规模部署。随着隐藏的错误暴露，探测噪音随着部署规模迅速增长。经过一个月的bug-fix之后，探测噪音最终收敛了。

经验二：Zoonet控制平面多重优化。虚拟网络配置最初存储在关系型数据库中。Zoonet在拓扑计算之前需要读取多个关系表，例如VPC资源表、VPC路由表、VM-server映射表、VM-pubIP映射表等。但是，关系型数据库的读写速度有限，扩展性差。因此，我们开发了一个带有键值内存数据库的虚拟网络拓扑缓存以进行加速。此外，我们使用基于地域的数据库分片等技术进一步扩展Zoonet控制平面。

经验三：通过诊断树进行自动化故障诊断。Zoonet运行常态化的网络探测，并在检测到网络异常时向网络运营人员发出告警。网络运营人员负责分析告警以及根因定位。在部署初期，我们被“告警风暴”淹没了，于是我们开始编写用于故障诊断的自动化脚本。逐渐地，脚本数据库成长为一棵诊断树，每个叶节点都包含一个根因。有了诊断树之后，发现异常时会首先遍历这棵树，然后找到叶节点通知网络运营人员。这件事的收益是非常大的，例如，它将VPC团队中从事网络故障排查的人员从11人减少到1.5人。

七、总结

阿里云洛神云网络尝试去解决在实际运营云网络时面临的两大难题：一是如何说明一个问题不是网络问题，另一个就是快速发现以及定位影响范围很小的网络问题。Zoonet采取了实时常态化轻量级的探测方法，配合众多虚拟网络节点对探测协议的广泛支持，比较好的解决了上述问题。该系统耗费了数十位研发同学的心血打磨而成，并且该系统已在大规模云网络系统上得到了充分的验证。希望Zoonet的分享可以对业界以及学术界带来重要参考价值。

扩展阅读

Zoonet论文原文：

https://dl.acm.org/doi/pdf/10.1145/3555050.3569116

,