我们是否可以在大型数据中心网络中随时获得任意两台服务器之间的网络延迟？收集的延迟数据可用于解决一系列挑战：告知应用程序感知延迟问题是否由网络引起，定义和跟踪网络服务水平协议（SLA）以及自动网络故障排除。 我们开发了用于大规模数据中心网络延迟测量和分析的Pingmesh系统，以肯定地回答上述问题。 Pingmesh已在Microsoft数据中心运行了四年多，每天收集数十TB的延迟数据。 Pingmesh不仅被网络软件开发人员和工程师广泛使用，还被应用程序和服务开发人员和运营商广泛使用。
CCS概念
网络->网络测量、云计算、网络监控、计算机系统架构->云计算
关键字
数据中心网络 网络故障排除 无声数据包丢失
在今天的数据中心，有数十万台服务器。这些服务器通过网络接口卡（NIC），交换机和路由器，电缆和光纤连接，形成大规模的内部和内部数据中心网络。 由于云计算的快速发展，数据中心网络（DCN）的规模正在扩大。 在物理数据中心基础设施之上，构建了各种大规模的分布式服务，例如Search [5]，分布式文件系统[17]和存储[7]，MapReduce [11]。
这些分布式服务是庞大且不断发展的软件系统，具有许多组件并具有复杂的依赖性。 所有这些服务都是分布式的，许多组件需要通过网络在数据中心内或跨不同的数据中心进行交互。 在这样的大型系统中，软件和硬件故障是常态而非例外。因此，网络团队面临着一些挑战。
第一个挑战是确定问题是否是网络问题?由于分布式系统的性质，许多故障显示为“网络”问题，例如，某些组件只能间歇性地到达，或者端到端延迟显示在第99百分位处突然增加，每台服务器的网络速度吞吐量从20MB/s降低到5MB/s。我们的经验表明，这些“网络”问题中约有50％不是由网络引起的。 然而，要判断“网络”问题是否确实是由网络故障引起的，这并不容易。
第二个挑战是定义和跟踪网络服务水平协议（SLA）。许多服务需要网络提供某些性能保证。 例如，搜索查询可能会触及数千台服务器，搜索查询的性能由最慢服务器的最后一次响应确定。这些服务对网络延迟和数据包丢失敏感，他们关心网络SLA。需要针对不同的服务单独测量和跟踪网络SLA，因为它们可能使用不同的服务器集和网络的不同部分。 由于网络中的大量服务和客户，这成为一项具有挑战性的任务。
第三个挑战是网络故障排除。当网络SLA因各种网络故障而中断时，会发生“实时站点”事件。 实时站点事件是指对客户，合作伙伴或收入产生影响的任何事件。 现场事件需要尽快被检测，缓解和解决。但数据中心网络拥有数十万到数百万台服务器，数十万台交换机以及数百万条电缆和光纤。因此，检测问题所在的位置是一个难题。
为了应对上述挑战，我们设计并实施了Pingmesh，这是一个用于数据中心网络延迟测量和分析的大型系统。 Pingmesh利用所有服务器启动TCP或HTTP pings,以提供最大延迟测量覆盖率。Pingmesh形成多层次的完整图表。在数据中心内，Pingmesh允许机架内的服务器形成完整的图形，并使用架顶式（ToR）交换机作为虚拟节点，并让它们形成第二个完整的图形。在数据中心之间，Pingmesh通过将每个数据中心视为虚拟节点来形成第三个完整的图形。完整图形和相关ping参数的计算由中央Pingmesh控制器控制。
测量的延迟数据由数据存储和分析管道收集和存储，汇总和分析。根据等待时间数据，在宏级别（即数据中心级别）和微级别（例如，每服务器和每个机架级别）定义和跟踪网络SLA。 通过将服务和应用程序映射到它们使用的服务器来计算所有服务和应用程序的网络SLA。
Pingmesh已经在微软的数十个全球分布式数据中心运行了四年。 它每天产生24TB的数据和超过200亿的探测数据。 由于Pingmesh数据的普遍可用性，因为网络变得更容易回答实时站点事件：如果Pingmesh数据不表示网络问题，则实时站点事件不是由网络引起的。
Pingmesh主要用于网络故障排除，以找出问题所在。 通过可视化和自动模式检测，我们能够回答数据包丢失和/或延迟增加的时间和地点，识别网络中的静默交换机数据包丢失和黑洞。 应用程序开发人员和服务运营商也使用Pingmesh生成的结果，通过考虑网络延迟和数据包丢弃率来更好地选择服务器。
本文作出了以下贡献：我们通过设计和实施Pingmesh，展示了建立大规模网络延伸测量和分析系统的可行性。 通过让每个服务器参与，我们始终为所有服务器提供延迟数据。 我们展示了Pingmesh通过在宏观和微观范围内定义和跟踪网络SLA来帮助我们更好地理解数据中心网络，并且Pingmesh帮助揭示和定位交换机数据包丢弃，包括数据包黑洞和静默随机数据包丢弃，这在以前很少被了解。
2.1 数据中心网络
数据中心网络以高速连接服务器，并提供高服务器到服务器带宽。今天的大型数据中心网络是由商品以太网交换机和路由器构成的。
图1显示了典型的数据中心网络结构。 网络有两部分：内部数据中心（Intra-DC）网络和内部数据中心（Inter-DC）网络。 DC内网络通常是几层Clos网络架构，类似于[1,12,2]中描述的网络。 在第一层，数十个服务器（例如40台）使用10GbE或40GbE以太网NIC连接到架顶式（ToR）交换机并形成一个Pod节点。 然后将数十个ToR交换机（例如，20台）连接到第二层节点（汇聚）交换机（例如，2-8）。 这些服务器和ToR和Leaf交换机组成一个Podset。 然后，多个Podset连接到第三层Spine交换机（数十到数百）。使用现有的以太网交换机，DC内部网络可以连接数万个或更多具有高网络容量的服务器。
一个优秀的数据中心是多个Leaf和Spine交换机提供具有冗余的多路径网络。 ECMP（等价多路径）用于对所有路径上的流量进行负载均衡。 ECMP使用TCP / UDP五元组的哈希值进行下一跳选择。 因此，即使连接的五元组已知，TCP连接的确切路径在服务器端也是未知的。 因此，找到有故障的Spine交换机并不容易（因为路径无法确定？）。
DC间网络用于互连DC内网络并将DC间网络连接到因特网。 DC间网络使用高速长途光纤连接不同地理位置的数据中心网络。 软件定义网络（SWAN [13]，B4 [16]）被进一步引入，以实现更好的广域网络流量工程。
我们的数据中心网络是一个庞大，复杂的分布式系统。 它由数百个服务器，数万个交换机和路由器以及数百万个电缆和光纤组成。 它由我们自行开发的数据中心管理软件堆栈Au-topilot [20]管理，交换机和NIC运行由不同交换机和NIC提供商提供的软件和固件。 在网络上运行的应用程序可能会引入复杂的流量模式。
2.2 网络延迟和数据包丢失
在本文中，我们从应用程序的角度看“网络延迟”。 当服务器上的应用程序A向对等服务器上的应用程序B发送消息时，网络延迟定义为从A发送消息到B接收消息的时间之间的时间间隔。实际上，我们测量往返时间（RTT），因为RTT测量不需要同步服务器时钟。
1.应用程序处理延迟
2.OS内核
3.TCP/IP堆栈
4.驱动程序处理延迟
5.NIC引入的延迟（例如，DMA操作，中断调制）[22]，数据包传输延迟，传播延迟和排队延迟引入组成 通过在路径上的交换机处进行分组缓冲。
有人可能会争论应用程序和内核堆栈引入的延迟并非真正来自网络。 在实践中，我们的经验告诉我们，我们的客户和服务开发人员并不关心。 一旦观察到延迟问题，它通常被称为“网络”问题。 网络团队有责任显示问题是否确实是网络问题，如果问题是，则缓解并解决问题。
用户感知的延迟可能由于各种原因而增加，例如，由于网络拥塞导致的排队延迟，繁忙的服务器CPU，应用程序错误，网络路由问题等。我们还注意到数据包丢失会增加用户感知的延迟，因为丢弃的数据包需要重新传输。 由于各种原因（例如，光纤FCS（帧校验序列）错误，切换ASIC缺陷，交换机结构缺陷，交换机软件错误，NIC配置问题，网络拥塞等），数据包丢失可能发生在不同的地方。我们在生产网络中看到了所有这些类型的问题。
2.3 数据中心管理和数据处理系统
接下来我们介绍Autopilot [20]和Cosmos和SCOPE [15]。 数据中心由集中式数据中心管理系统管理，例如Autopilot [20]或Borg [23]。 这些管理系统提供有关如何管理包括物理服务器在内的资源，如何部署，计划，监控和管理服务的框架。 Pingmesh是在Autopilot的框架内构建的。
Autopilot是Microsoft用于自动数据中心管理的软件堆栈。 其理念是运行软件以自动执行所有数据中心管理任务，包括故障恢复，尽可能减少人力资源。 使用自动驾驶仪术语，集群是由本地数据中心网络连接的一组服务器，由自动驾驶仪环境管理。自动驾驶仪环境具有一组自动驾驶仪服务，包括设备管理器（DM），用于管理机器状态 ，为自动驾驶仪和各种应用程序进行服务部署的部署服务（DS），安装服务器操作系统映像的供应服务（PS），监视和报告各种硬件和软件的健康状况的监视服务（WS），维修服务（RS） ）通过从DM等获取命令来执行修复动作。
Autopilot提供共享服务模式。 共享服务是在每个自动驾驶托管服务器上运行的一段代码。 例如，Service Manager是管理其他应用程序的生命周期和资源使用情况的共享服务，Perfcounter Collector是一种共享服务，它收集本地perf计数器，然后将计数器上载到Autopilot。 共享服务必须重量轻，CPU，内存和带宽资源使用率低，并且它们需要可靠而不会造成资源泄漏和崩溃。
Pingmesh使用我们自己开发的数据存储和分析系统Cosmos/SCOPE进行延迟数据存储和分析。Cosmos是微软的BigData（大数据）系统，类似于Hadoop [3]，它提供了像GFS [17]和MapReduce [11]这样的分布式文件系统。Cosmos中的文件仅附加，文件被拆分为多个“扩展区”，扩展区存储在多个服务器中以提供高可靠性。 Cosmos集群可能拥有数万台或更多服务器，并为用户提供几乎“无限”的存储空间。
SCOPE [15]是一种声明性和可扩展的脚本语言，它构建在Cosmos之上，用于分析海量数据集。 SCOPE设计易于使用。 它使用户能够专注于他们的数据而不是底层存储和网络基础设施。 用户只需要编写类似于SQL的脚本，而不必担心并行执行，数据分区和故障处理。 所有这些复杂性都由SCOPE和Cosmos处理。
3.1 设计目标
Pingmesh的目标是构建网络延迟测量和分析系统，以解决我们在第1节中描述的挑战.Pingmesh需要始终开启，并能够为所有服务器提供网络延迟数据。 它需要始终保持开启，因为我们需要始终跟踪网络状态。 它需要为所有服务器生成网络延迟数据，因为最大可能的网络延迟数据覆盖对于我们更好地理解，管理和排除网络基础架构故障至关重要。
从一开始，我们就将Pingmesh与各种公共和专有网络工具（例如，跟踪器，TcpPing等）区分开来。 我们意识到网络工具对我们不起作用，原因如下。 首先，这些工具并不总是开启，它们只在我们运行时生成数据。 其次，他们生成的数据没有所需的覆盖范围。 由于这些工具并非始终处于开启状态，因此我们无法指望它们跟踪网络状态。 当已知源目标地址时，这些工具通常用于网络故障排除。 然而，这对于大规模数据中心网络并不适用：当网络事件发生时，我们甚至可能不知道源目地址（发生事故的地方）。 此外，对于瞬态网络问题，在运行工具之前问题可能已经消失（网络组的痛点）。
3.2 Pingmesh架构
根据其设计目标，Pingmesh需要满足以下要求。 首先，因为Pingmesh旨在从应用程序的角度提供尽可能大的覆盖范围和测量网络延迟，因此每台服务器都需要Pingmesh Agent。 必须小心这样做，以便Pingmesh Agent引入的CPU，内存和带宽开销很小且价格合理。
其次，Pingmesh Agent的行为应该受到控制和配置。 需要高度可靠的控制平面来控制服务器应如何执行网络延迟测量。
第三，应该近乎实时地汇总，分析和报告延迟数据，并将其存储和存档以进行更深入的分析。 根据要求，我们设计了Pingmesh的体系结构，如图2所示.Pingmesh有三个组件，如下所述。
1.《Pingmesh控制器》。 它是整个系统的大脑，因为它决定了服务器应该如何相互探测。 在Pingmesh Controller中，Pingmesh Generator为每个服务器生成一个pinglist文件。 pinglist文件包含对等服务器列表和相关参数。 pinglist文件基于网络拓扑生成。 服务器通过RESTful Web界面获取相应的pinglist。
2.《Pingmesh代理》。 每台服务器都运行Pingmesh代理。 代理从Pingmesh Controller下载pinglist，然后启动TCP / HTTP ping到pinglist中的对等服务器。 Pingmesh代理将ping结果存储在本地内存中。 一旦计时器超时或测量结果的大小超过阈值，Pingmesh Agent会将结果上载到Cosmos进行数据存储和分析。 Pingmesh代理还公开了一组性能计数器，这些计数器由Autopilot的Perfcounter聚合器（PA）服务定期收集。
3.《数据存储和分析（DSA)》。 Pingmesh代理的延迟数据在数据存储和分析（DSA）管道中存储和处理。 保护数据存储在Cosmos中。 开发SCOPE工作来分析数据。 SCOPE作业是用类似于SQL的声明性语言编写的。 然后将分析的结果存储在SQL数据库中。 根据此数据库和PA计数器中的数据生成可视化，报告和警报。
3.3 Pingmesh控制器
3.3.1 pinglist生成算法
Pingmesh控制器的核心是它的Pingmesh 控制器。 Pingmesh 控制器运行一个算法来决定哪个服务器应该ping哪组服务器。 如前所述，我们希望Pingmesh拥有尽可能大的覆盖范围。 最大可能的覆盖范围是服务器级完整图，其中每个服务器都会探测其余服务器。 但是，服务器级完整图是不可行的，因为服务器需要探测n-1个服务器，其中n是服务器的数量。 在数据中心中，n可以达到数百个。 此外，服务器级完整图不是必需的，因为数十台服务器通过相同的ToR交换机连接到世界其他地方。
然后，我们提出了多层次完整图形的设计。 在Pod中，我们让同一个ToR交换机下的所有服务器形成一个完整的图形。 在DC内部级别，我们将每个ToR交换机视为虚拟节点，并让ToR交换机形成完整的图形。 在DC间级别，每个数据中心充当虚拟节点，并且所有数据中心形成完整的图形。
在我们的设计中，只有服务器执行ping操作。 当我们将ToR称为虚拟节点时，它是ToR下执行ping的服务器。 同样，对于作为虚拟节点的数据中心，数据中心中的所选服务器会启动探测。
在DC内部，我们曾经认为我们只需要选择可配置数量的服务器来参与Pingmesh。 但是如何选择服务器成为一个问题。 此外，少量选择的服务器可能不能很好地代表其余的服务器。 我们终于想出让所有服务器都参与其中的想法。 DC内算法是：对于任何ToR对（ToRx，ToRy），让ToRx中的服务器i ping ToRy中的服务器i。 在Pingmesh中，即使两台服务器位于彼此的pinglist中，它们也会分别测量网络延迟。 通过这样做，每个服务器都可以在本地和独立地计算自己的丢包率和网络延迟。
在DC间级别，所有DC形成另一个完整的图形。 在每个DC中，我们选择多个服务器（从每个Podset中选择多个服务器）。
结合三个完整的图，Pingmesh中的服务器需要根据数据中心的大小ping 2000-5000对等服务器。 Pingmesh控制器使用阈值来限制服务器的探测总数以及源目标服务器对的两个连续探测的最小时间间隔。
3.3.2 Pingmesh控制器实现
Pingmesh控制器实现为自动驾驶仪服务，并成为自动驾驶仪管理堆栈的一部分。 它通过运行Pingmesh生成算法为每个服务器生成Pinglist文件。 然后将这些文件存储在SSD中，并通过Pingmesh Web服务提供给服务器。 Pingmesh Controller为Pingmesh代理提供了一个简单的RESTful Web API，以分别检索其Pinglist文件。 Pingmesh代理需要定期向Controller询问Pinglist文件，Pingmesh Controller不会将任何数据推送到Pingmesh代理。 通过这样做，Pingmesh Controller变得无状态且易于扩展。
作为整个Pingmesh系统的大脑，Pingmesh Controller需要服务数十万个Pingmesh Agent。因此，Pingmesh控制器需要具有容错性和可扩展性。我们使用软件负载均衡器（SLB）[14]来提供容错和可扩展性
Pingmesh控制器。有关SLB如何工作的详细信息，请参见[9,14]。 Pingmesh Controller在单个VIP（虚拟IP地址）后面有一组服务器。 SLB将来自Pingmesh代理的请求分发到Pingmesh Controller服务器。每个Pingmesh控制器服务器都运行相同的代码，并为所有服务器生成相同的Pinglist文件集，并且能够处理来自任何Pingmesh代理的请求。然后，Pingmesh Controller可以通过在同一VIP后面添加更多服务器来轻松扩展。此外，一旦Pingmesh控制器服务器停止运行，它将自动从SLB中旋转。我们在两个不同的数据中心集群中设置了两个Pingmesh控制器，使控制器在地理上更具容错能力。
3.4 pingmesh 代理
3.4.1 Pingmesh 代理设计注意事项
Pingmesh代理程序在所有服务器上运行。 它的任务很简单：从Pingmesh控制器下载pinglist; ping pinglist中的服务器; 然后将ping结果上传到DSA。
根据Pingmesh需要能够区分用户感知延迟增加是否由网络引起的要求，Pingmesh应使用应用程序生成的相同类型的数据包。 由于我们数据中心的几乎所有应用程序都使用TCP和HTTP，因此Pingmesh使用TCP和HTTP而不是ICMP或UDP进行探测。
因为我们需要区分“网络”问题是由于网络还是应用程序本身，Pingmesh Agent不会使用应用程序使用的任何网络库。 相反，我们开发了自己的轻量级网络库，专门用于网络延迟测量。
Pingmesh代理可以配置为发送和响应除TCP SYN / SYN-ACK数据包之外的不同长度的探测数据包。 结果，Pingmesh代理需要充当客户端和服务器。 客户端部分启动ping，服务器部分响应ping。
每次探测都需要是新连接并使用新的TCP源端口。 这是为了尽可能地探索网络的多路径特性，更重要的是，减少Pingmesh创建的并发TCP连接的数量。
3.4.2 Pingmesh代理实现
虽然任务很简单，但Pingmesh Agent是最具挑战性的部分之一。 它必须符合以下安全和性能要求。
首先，Pingmesh代理必须是失效关闭的，不能创建实时站点事件。 由于Pingmesh代理在每台服务器上运行，因此如果它发生故障（例如，使用大部分CPU和内存资源，产生大量探测流量等），它有可能将所有服务器关闭。 为了避免发生不良事件，PingMesh代理实现了以下几个安全功能：
1.Pingmesh Agent的CPU和最大内存使用量受操作系统的限制。 一旦最大内存使用量超过上限，Pingmesh代理将被终止。
2.任何两台服务器之间的最小探测间隔限制为10秒，探测有效负载长度限制为64千字节。 这些限制在源代码中是硬编码的。 通过这样做，我们对Pingmesh可以带入网络的最坏情况流量进行了硬性限制。
3.如果Pingmesh代理无法连接到其控制器3次，或者控制器已启动但没有可用的pinglist文件，则Pingmesh代理将删除其所有现有ping对等项并停止其所有ping活动。 （它仍然会对ping做出反应。）由于这个功能，我们可以通过简单地从控制器中删除所有pinglist文件来阻止Pingmesh Agent工作。
4.如果服务器无法上传其延迟数据，它将重试几次。 之后它将停止尝试并丢弃内存中的数据。 这是为了确保Pingmesh代理使用有界内存资源。 Pingmesh代理还将延迟数据作为日志文件写入本地磁盘。 日志文件的大小限制为可配置的大小。
其次，Pingmesh Agent需要通过设计启动ping到数千台服务器。 但作为共享服务，Pingmesh代理应尽量减少其资源（CPU，内存和磁盘空间）的使用。 它应该使用接近零的CPU时间和尽可能小的内存占用，以便最大限度地减少对客户应用程序的干扰。
为了实现性能目标并提高Pingmesh的延迟测量精度，我们使用C ++而不是Java或C＃来编写Pingmesh Agent。 这是为了避免公共语言运行时或Java虚拟机开销。 我们专门为Pingmesh开发了一个网络库。 该库的目标仅用于网络延迟测量，它设计为轻量级并处理大量并发TCP连接。 该库直接基于Winsock API，它使用Windows IO完成端口编程模型进行高效的异步网络IO处理。 该库充当客户端和服务器，并将探测处理负载均匀地分配给所有CPU核心。
我们已经进行了大量测量，以了解和优化Pingmesh Agent的性能。 图3显示了典型服务器上Pingmesh Agent的CPU和内存使用情况。 在测量过程中，这个Pingmesh Agent正在积极探测大约2500台服务器。 该服务器具有128GB内存和两个In-tel Xeon E5-2450处理器，每个处理器有8个内核。 平均内存占用量小于45MB，平均CPU使用率为0.26％。
我们注意到Pingmesh代理生成的探测流量很小，通常为几十Kb/s。 作为比较，我们的数据中心网络在数据中心的任何两台服务器之间提供几个Gb/s的吞吐量。
3.5 数据存储和分析
对于Pingmesh数据存储和分析，我们使用完善的现有系统，Cosmos / SCOPE和Autopilot的Perfcounter聚合器（PA）服务，而不是重新发明轮子。
Pingmesh代理会定期将聚合记录上传到Cosmos。 与Pingmesh控制器类似，Cosmos的前端使用负载平衡器和VIP进行扩展。 同时，Pingmesh 代理对延迟数据执行本地计算，并生成一组性能计数器，包括50%至90%的丢包率和网络延迟等。所有这些性能计数器都被收集，汇总和存储在Autopilot的PA服务。
一旦Cosmos收到结果，我们就会运行一组SCOPE作业进行数据处理。 我们的定时任务为10分钟，1小时，1天。 10分钟的工作是我们近乎实时的工作。 对于10分钟的作业，从生成延迟数据到消耗数据的时间（例如，警报触发，仪表板图形生成）的时间间隔大约为20分钟。 1小时和1天的管道用于非实时任务，包括网络SLA跟踪，网络黑洞检测，丢包检测等。我们的所有工作都由作业管理员自动并定期提交给SCOPE 用户干预。 SCOPE作业的结果存储在SQL数据库中，从中生成可视化，报告和警报。
实际上，我们发现这20分钟的延迟对于系统级SLA跟踪工作正常。 为了进一步减少响应时间，我们并行使用Autopilot PA管道来收集和聚合一组Pingmesh计数器。 Autopilot PA管道是一种分布式设计，每个数据中心都有自己的管道。 PA计数器收集延迟为5分钟，比我们的Cosmos / SCOPE管道更快。 PA管道比Cosmos / SCOPE更快，而Cosmos / SCOPE比PA更具表现力以进行数据处理。 通过使用它们，我们为Pingmesh提供了比其中任何一个更高的可用性。
我们将Pingmesh作为一个永远在线的服务与一组定期运行的脚本区分开来。 Pingmesh的所有组件都有监视器来监视它们是否正常运行，例如，是否正确生成了pinglists，CPU和内存使用是否在预算范围内，是否报告和存储pingmesh数据，DSA是否报告 及时的网络SLA等。此外，Pingmesh Agent旨在以轻量级和安全的方式探测数千个对等体。
所有Pingmesh代理每天都会向Cosmos上传24 TB的延迟测量结果。 这超过了2Gb / s的上传速率。 虽然这些看起来像是大数字，但它们只是我们的网络和Cosmos提供的总容量中可忽略不计的一小部分。
在本节中，我们将介绍Pingmesh如何帮助我们更好地了解网络延迟和数据包丢失，定义和跟踪网络SLA，以及确定实时站点事件是否是由于网络问题。 我们在本节中描述的所有数据中心都具有与我们在图1中介绍的类似的网络架构，尽管它们的大小可能不同，并且可能在不同的时间构建。
4.1网络延迟
图4显示了美国西部的两个代表性数据中心DC1和美国中部的DC2的DC内延迟分布。 DC1由分布式存储使用，MapReduce和DC2由交互式搜索服务使用。 DC1中的服务器是吞吐量密集型的，平均服务器CPU利用率高达90％。 DC1中的服务器大量使用网络，并且始终平均发送和接收数百Mb / s数据。 DC2对延迟敏感，服务器具有高扇入和扇出，因为服务器需要与大量其他服务器通信才能为搜索查询提供服务。 DC2中的平均CPU利用率适中，平均网络吞吐量较低但流量突发。
图4中的CDF是根据一个正常工作日的延迟数据计算的，此时没有检测到网络事件，也没有因网络引起的现场事件。 我们使用和不使用TCP有效负载跟踪pod内和pod间延迟分布。 如果没有特别提及，我们在本文中使用的延迟是无负载的pod-pod TCP SYN / SYN-ACK RTT。
图4（a）显示了整体的pod间延迟分布，图4（b）显示了高百分位的pod间分布。 我们曾经预计DC1的延迟应该远大于DC2，因为DC1中的服务器和网络负载很高。 但事实证明，90％或更低百分位数的延迟并非如此。
但是如图4（b）所示，DC1在高百分位数下确实具有更高的延迟。 在P99.9，DC1和DC2的内部延迟分别为23.35ms和11.07ms。 在P99.99，pod间延迟变为1397.63ms和105.84ms。 我们的测量结果表明，即使服务器和网络在宏时间尺度上都是轻载的，也难以在三或四个9s处提供低延迟（例如，亚毫秒级别）。 这是因为服务器操作系统不是实时操作系统，而且网络中的流量是突发的。 即使平均网络利用率低至中等，我们也会看到10-5内部网络通信的丢包率（第4.2节）。
图4（c）比较了pod内和pod之间的分布，图4（d）研究了有无负载的荚间延迟，所有这些都在DC1中。 对于使用有效负载的延迟测量，在TCP连接设置之后，我们让客户端发送消息（通常在一个数据包中为800-1200字节）。 客户端收到来自服务器的回送消息后，测量有效负载延迟。
如图4（c）所示，pod内的延迟总是小于pod之间的延迟，如预期的那样。 DC1的第50（P50）和第99（P99）节点内和节点间延伸为（216us，1.26ms）和（268us，1.34ms）。 P50和P99的差异分别为52us和80us。 这些数字表明，由于排队延迟，网络确实引入了数十微秒的延迟。 但排队延迟很小。 因此，我们可以确定网络提供足够的网络容量。
图4（d）显示了有无负载的延迟差异。 使用有效载荷时，P50的延迟从268us增加到326us，P99的延迟从1.34ms增加到2.43ms。 增加主要是因为传输延迟1增加以及接收服务器回显消息的用户空间处理开销。 在大多数情况下，有无负载的延迟分布是相似的。 我们引入了有效负载ping，因为它可以帮助检测与数据包长度相关的数据包丢失（例如，光纤FCS错误和切换与误码率相关的SerDes错误）。
基于Pingmesh数据，我们不仅可以计算数据中心的延迟分布，还可以计算所有应用程序和服务的延迟CDF。 从这些结果中，我们能够始终跟踪所有这些结果的网络延迟。
4.2 丢包率
Pingmesh不直接测量丢包率。 但是，我们可以从TCP连接建立时间推断数据包丢弃率。 当第一个SYN数据包被丢弃时，TCP发送器将在初始超时后重新发送数据包。 对于其余的连续重试，TCP每次都会使超时值加倍。 在我们的数据中心中，初始超时值为3秒，发送方将重试SYN两次。 因此，如果测量的TCP连接RTT约为3秒，则有一个数据包丢弃; 如果RTT大约是9秒，则有两个丢包。 我们使用以下启发式来估计丢包率 ：
(probes_with_3s_rtt + probes_with_9s_rtt)/total_successful_probes
请注意，我们仅使用成功TCP探测的总数而不是总探测作为分母。 这是因为对于失败的探测器，我们无法区分丢包和接收服务器故障。 在分子中，对于9秒RTT的每个连接，我们只计算一个数据包丢弃而不是两个数据包丢弃。 这是因为连接中的连续数据包丢失不是独立的：如果第一个SYN是我们在数据中心的交换机上禁用了直通交换，则第二个SYN被丢弃的概率要高得多。 这是为了阻止FCS错误传播。 我们通过计算NIC和ToR数据包丢弃来验证单个ToR网络的启发式算法的准确性。
在我们的网络中，SYN数据包的处理方式与其他数据包相同。 因此，SYN分组的丢弃率可以被认为是正常条件下其他数据分组的代表性丢弃率。 然而，当分组丢弃率与分组大小相关时（例如，由于FCS错误），该假设可能不正确。 我们确实看到较大尺寸的数据包在FCS错误相关事件中可能会遇到更高的丢弃率。 在下文中，我们提出的结果是网络处于正常状态。
我们的网络不区分不同IP协议的数据包（例如，TCP与UDP）。 因此，我们的数据包丢弃计算也适用于非TCP流量。
表1 显示了五个数据中心的数据包丢弃率。 我们显示了pod内和pod之间的数据包丢弃率。 对于pod内丢包，这些丢弃在ToR交换机，NIC和终端主机网络堆栈中。 除了ToR，NIC和终端主机堆栈之外，pod之间的数据包丢弃可能来自Leaf和Spine交换机以及相应的链路。
从
表1中可以得出几个观察结果。 首先，丢包率在0.0001%-0.001%的范围内。 我们每天跟踪所有数据中心的数据包丢弃率，除非发生网络事件，否则我们发现丢弃率在此范围内。 其次，pod之间的数据包丢弃率通常比pod内高几倍。 这表明大多数数据包丢弃都发生在网络而不是主机中。 第三，pod内丢包率约为0.0001%，比我们预期的要大。
我们的经验告诉我们，由于许多原因可能会发生数据包丢失，例如，交换机缓冲区溢出，NIC接收缓冲区溢出，光纤FCS错误，交换ASIC故障等。虽然我们的测量结果表明数据包丢弃率处于正常状态 在0.0001%-0.001%左右，理解为什么它保持在这个范围内,我们仍然处于早期阶段。
许多数据中心应用程序（例如，搜索）可以同时使用数百甚至数千个TCP连接。 对于这些应用，由于使用了大量连接，因此高延跟踪成为常态。 应用程序已经引入了几种应用程序级技巧来处理数据包丢弃[10]。
从每服务器延迟数据，我们可以计算和跟踪服务器，pod，podset和数据中心级别的网络SLA。 同样，我们可以计算和跟踪各个服务的网络SLA。
4.3 这是网络问题吗？
在大型分布式数据中心系统中，许多部件可能出错。 当发生现场事件时，要识别导致问题的部分并不容易。 有时候所有组件看起来都很好，但整个系统都被打破了。 如果网络无法证明它是无辜的，那么这个问题就会被称为“网络问题”：我没有对我的服务做任何错误，它一定是网络的错。
然后，网络团队开始调查。 典型的程序如下。 网络呼叫工程师询问正在经历详细症状和源 - 目的地对问题的服务; 然后，他登录到源服务器和/或目标服务器，并运行各种网络工具来重现该问题; 他也可能会看到异常可能路径上的开关计数器; 如果他不能复制，他可能会要求更多的源 - 目的地对。 该过程可能需要多轮迭代。
上述方法对我们来说效果不佳，因为它是一个手动过程而且不能扩展。 如果问题不是由网络造成的，那么服务所有者就会浪费时间与错误的团队合作。 如果问题确实是由于网络问题，则手动过程会导致长时间检测（TTD），缓解时间（TTM）和解决时间（TTR）。
Pingmesh改变了这种情况。 由于Pingmesh从所有服务器收集延迟数据，因此我们始终可以提取Pingmesh数据，以判断特定服务是否存在网络问题。 如果Pingmesh数据与应用程序感知的问题无关，那么它不是网络问题。 如果Pingmesh数据显示它确实是网络问题，我们可以进一步从Pingmesh获取详细数据，例如，问题的规模（例如，受影响的服务器和应用程序的数量），源 - 目标服务器IP地址和TCP端口号 ，进一步调查。
我们将网络SLA定义为一组指标，包括丢包率，第50百分位数和第99百分位数的网络延迟。 然后，可以使用Pingmesh数据在不同的范围内跟踪网络SLA，包括每个服务器，每个pod / podset，每个服务，每个数据中心。 在实践中，我们发现了两个网络SLA指标：第99百分位的数据包丢弃率和网络延迟对于判断问题是否是由网络引起很有用。 图5显示了一个正常周的服务的这两个表。 数据包丢弃率约为0.04%，数据中心的第99百分位延迟为500-560us。 （延迟显示了一种周期性模式。这是因为该服务定期执行高吞吐量数据同步，这会增加第99百分位延迟。）如果这两个指标发生显着变化，那么这就是网络问题。
我们目前使用基于阈值的简单方法进行网络SLA违规检测。 如果数据包丢弃率大于0.1%或第99百分位延迟大于5毫秒，我们会将其归类为网络问题和火灾警报。 0.1%和5ms远大于正常值。 我们保留Pingmesh历史数据2个月，我们在Pingmesh数据之上运行各种数据分析，以跟踪不同数据中心和客户的网络SLA。 使用数据挖掘和机器学习有很多机会从Pingmesh数据中获得更多价值。
在第5节中，我们将详细研究一个特定的数据包丢弃：交换机静默数据包丢弃。
在本节中，我们将介绍Pingmesh如何帮助检测交换机静默数据包丢弃。 当发生静默数据包丢失时，由于各种原因，交换机不会显示有关这些数据包丢弃的信息，并且交换机看起来是无辜的。 但应用程序遭受延迟和数据包丢失的影响。 如何快速识别是否由于交换机无声数据包丢失导致正在进行的实时站点事件变得至关重要。
过去，我们已经确定了两种类型的交换机静默数据包丢包：数据包黑洞和静默随机数据包丢弃。 接下来，我们将介绍如何使用Pingmesh来检测它们。
5.1 数据包黑洞
数据包黑洞是一种特殊类型的交换机数据包丢弃。 对于正在经历分组黑洞的交换机，通过交换机确定性地（即，100％）丢弃满足某些“模式”的分组。 我们已经确定了两种类型的分组黑洞。 在第一种类型的黑洞中，具有特定源目的地IP地址对的分组被丢弃。 症状如下：服务器A无法与服务器B通信，但它可以正常与服务器C和D通信。 所有服务器A-D都很健康。
在第二种类型的黑洞中，丢弃具有特定源目的地地址和传输端口号的分组。 请注意，对于此类型的黑洞，具有相同源目标地址对但源目标端口号不同的数据包将以不同方式处理。 例如，服务器A可以使用源端口X与服务器B的目标端口Y通信，但不能与源端口Z通信。
第一类黑洞通常由开关ASIC中的TCAM缺陷（例如，奇偶校验错误）引起。 TCAM表中的某些TCAM条目可能会被破坏，并且损坏仅导致丢弃具有某些源和目标地址模式的数据包。 （由于只有目标地址用于IP路由的下一跳查找，因此可能想知道为什么源IP地址起作用。我们的猜测是TCAM条目不仅包括目标地址，还包括源地址和其他元数据。）
我们对第二类黑洞的根本原因知之甚少。 我们怀疑这可能是因为与ECMP相关的错误，它使用源和目的地IP地址和端口号来决定下一个转发跳。
根据我们的经验，可以通过重新加载交换机（开关）来修复这两种类型的包黑洞。 因此问题就变成了如何检测带有黑洞的交换机（开关）。
我们设计了一种基于Pingmesh数据的ToR开关黑洞检测算法。 该算法的想法是，如果ToR交换机下的许多服务器遇到黑洞症状，那么我们将ToR交换机标记为黑洞候选，并为其分配一个分数，即服务器与黑洞交互的比率汤姆。 然后，我们选择黑洞得分大于阈值的开关作为候选者。 在一个pod-set中，如果只有部分ToR遇到黑洞症状，那么那些ToR就是黑洞数据包。 然后，我们调用网络修复服务以安全地重新启动ToR。 如果podset中的所有ToR都遇到黑洞症状，则问题可能出现在Leaf或Spine图层中。 网络工程师会收到进一步调查的通知。
我们设计了一种基于Pingmesh数据的ToR交换机黑洞检测算法。 算法的想法是，如果ToR交换机下的许多服务器遇到黑洞症状，那么我们将ToR交换机标记为黑洞候选者，并为其分配一个分数，即服务器与黑洞症状的比率。 然后，我们选择黑洞得分大于阈值的交换机作为候选者。 在一个podset中，如果只有部分ToR遇到黑洞症状，那么那些ToR就是黑洞数据包。 然后，我们调用网络修复服务以安全地重新启动ToR。 如果podset中的所有ToR都遇到黑洞症状，则问题可能出现在Leaf或Spine层中。 网络工程师会收到进一步调查的通知。
图6显示了算法检测到的带有黑洞的ToR交换机的数量。 从图中可以看出，一旦算法开始运行，带有数据包黑洞的开关数量就会减少。 在我们的算法中，我们将算法限制为每天最多重新加载20个交换机。 这是为了限制交换机重启的最大数量。 我们可以看到，经过一段时间后，检测到的交换机数量每天只下降到几个。
我们想要注意的是，Pingmesh Agent的TCP源端口因每次探测而异。 通过大量的源/目标IP地址对，Pingmesh扫描整个源/目标地址和端口空间的很大一部分。 在Pingmesh黑洞检测上线后，我们的客户不再抱怨数据包黑洞了。
5.2 无声随机数据包丢弃
交换机位于网络中的层越高，它开始丢弃数据包时将产生越严重的影响。 当Spine交换机静默丢弃数据包时，将影响数万台服务器和许多服务，并将触发高严重性的实时站点事件。
在这里，我们介绍Pingmesh如何帮助定位Spine交换机的静默随机数据包丢弃。 在一个事实中，数据中心的所有用户开始在第99百分位(不知道怎么翻译)时遇到增加的网络延迟。 使用 Pingmesh，我们可以确认该数据中心的数据包丢失率显着增加，并且丢弃率不确定。 图7显示了服务的丢包率变化。 在正常情况下，延迟百分比应该在0.01%-0.001%左右。 但它突然跳升到0.2%左右。
使用Pingmesh，我们很快就会发现只有一个数据中心受到影响，其他数据中心也没问题。 ToR和Leaf层的数据包丢失不会导致所有客户的延迟增加，因为它们下面的服务器数量要少得多。 图8（d）中所示的延迟增加模式将问题指向Spine交换机层。
但是我们在这些交换机上找不到任何数据包丢弃提示（
FCS错误，输入/输出数据包丢弃，系统日志错误等）。 然后我们怀疑这可能是无声数据包丢失的情况。 下一步是找到丢弃数据包的交换机。
再次，通过使用Pingmesh，我们可以找出几个经历了大约1％-2％随机数据包丢弃的源和目标对。 然后，我们针对这些对启动了TCP路由跟踪，最后确定了一个Spine交换机。 在我们将交换机从服务实时交换机中分离出来之后，无声随机数据包丢失了。 交换机提供商的事后分析显示数据包丢失是由于该交换机的结构模块的位翻转(bit flips of a fabric module)造成的。
上面的案例是我们遇到的第一个无声随机数据包丢弃案例之一，我们花了很长时间才解决。 之后我们遇到了更多案例，我们改进了Pingmesh数据分析和其他工具，以实现更好的自动随机静默数据包丢弃检测。 我们的经验告诉我们，随机静默数据包丢失可能是由于不同的原因，例如，交换结构CRC校验和错误，切换ASIC缺陷，线路卡不能正常等等。这些类型的交换机静默数据包丢失无法通过交换机重新加载来修复 必须RMA（退货商品授权）有故障的交换机或组件（退货说的这么委婉？ ^-^）。
与由于网络拥塞和链路FCS错误导致的数据包丢失相比，数据包黑洞和无声随机数据丢弃是新的，我们对它们了解甚少。 由于Pingmesh的整个覆盖范围和永远在线的属性，我们能够确认交换机静默数据包丢弃确实在现实世界中发生并对不同的静默数据包丢弃类型进行分类，并进一步定位静默数据包丢弃的位置。
Pingmesh旨在提供可扩展性。 我们知道并非所有网络都符合我们的规模。 我们相信，我们从Pingmesh学到的经验教训对大小规模的网络都是有益的。 我们吸取的教训之一是全覆盖的可信延迟数据的价值。 如果数据不值得信任，那么构建在其上的结果就不可信。 我们的经验告诉我们并非所有SNMP数据都值得信赖。 即使SNMP告诉我们一切正常，交换机也可能丢弃数据包。 我们信任Pingmesh数据，因为我们编写了代码，经过测试并运行它。 当有bug时，我们修复了它们。 经过几次迭代，我们知道我们可以信任这些数据。 由于其延迟数据的完全覆盖和可靠性，Pingmesh可以执行准确的黑洞和静默数据包丢弃检测。 作为比较，仅使用交换机SNMP和系统日志数据不起作用，因为它们没有告诉我们有关数据包黑洞和静默丢弃的信息。
在下文中，我们将介绍我们从构建和运行Pingmesh中学到的其他几个经验教训，我们相信它们也可以应用于不同规模的网络。
6.1 Pingmesh作为永远在线的服务
从项目开始，我们认为Pingmesh需要覆盖所有服务器并始终保持开启状态。 但不是每个人都同意。 有人认为应该只按需收集延迟数据; 我们应该只让少数选定的服务器参与延迟测量，以减少开销。 我们不同意他们两个。
从本质上讲，第一个论点是永远在线和按需。 如果不使用永远在线的延迟数据，有人可能会认为这是浪费资源，因此我们只应在需要时收集延迟数据。这个论点有两个问题。 首先，我们无法预测何时需要延迟数据，因为我们不知道何时会发生实时站点事件。 当发生现场事件时，手头有网络延迟数据而不是在那时收集它们是一个更好的选择。 其次，当发生不好的事情时，我们通常不知道哪些网络设备造成了麻烦，因此我们甚至没有源目标对来启动延迟测量。
仅使用少量选定的服务器进行延迟测量会限制Pingmesh数据的覆盖范围，并对应选择哪些服务器带来挑战。 正如我们在本文中所展示的那样，让所有服务器参与为我们提供最大可能的覆盖范围，并轻松平衡所有服务器之间的探测活动。 正如我们在本文中所展示的那样，Pingmesh引入的CPU，内存和带宽开销是可以承受的。
拥有永远在线的延迟数据带来了我们在开始时无法识别的好处。 在由于数据包黑洞(packet black-hole)和交换机静默数据包丢失(switch silent packet drops)而经历一些现场事件后，我们发现我们可以使用Pingmesh数据自动检测这些类型的交换机故障，因为它具有完整的覆盖范围和永远在线性质 Pingmesh数据（第5节）。
6.2 松散耦合的组件有助于发展
Pingmesh受益于松散耦合的系统设计。 Pingmesh Controller和Pingmesh Agent仅通过标准Web API通过pinglist文件进行交互，这些文件是标准XML文件。 Pingmesh Agent将延迟数据作为CSV文件和标准性能计数器提供。
由于其松散耦合设计，Pingmesh可以分三个阶段逐步建造。
第一阶段，我们专注于Pingmesh Agent。 我们构建了一个简单的Pingmesh Controller，它使用简化的pinglist生成算法静态生成pinglist文件。 延迟数据只是在没有自动分析的情况下被放入Cosmos中。 这一阶段证明了Pingmesh的可行性。 在此阶段结束时，延迟数据已用于网络SLA计算。
第二阶段，我们构建了一个完整的Pingmesh控制器，一旦更新网络拓扑或调整配置，它就会自动更新pinglists。 通过在地理分布式数据中心中设置多个控制器，新版本的Pingmesh Controller还具有更高的容量和更强的容错能力。
第三阶段，我们专注于数据分析和可视化。 我们构建了一个数据处理管道，可以分别在10分钟，1小时，1天内自动分析收集的延迟数据。 然后将处理后的结果存储在数据库中，以便进行可视化，报告和警报服务。
这三个阶段的主要任务已于2012年6月完成。之后，Pingmesh中添加了许多新功能：
数据中心内Pingmesh。Pingmesh最初为数据中心内部工作。但是，扩展它以覆盖数据中心很容易。 我们扩展了Pingmesh 控制器的pinglist生成算法，以便从每个数据中心中选择一组服务器，让他们执行数据中心内 ping并完成工作。 Pingmesh代理没有单行代码或配置更改。 我们确实添加了一个新的数据中心间数据处理管道。
QoS监控。 在部署Pingmesh之后，网络QoS被引入我们的数据中心，该数据中心基于DSCP（差异化服务代码点）区分高优先级和低优先级数据包。 同样，我们扩展了Pingmesh Generator，为高优先级和低优先级类生成pinglists。 在这种情况下，我们确实需要对Pingmesh代理进行简单的配置更改，以便让它侦听为低优先级流量配置的其他TCP端口。
VIP监控。 Pingmesh最初设计用于测量物理网络的网络延迟。 在我们的数据中心，广泛使用负载平衡和IP地址虚拟化。 地址虚拟化向用户公开逻辑虚拟IP地址（VIP），VIP映射到一组物理服务器。 这些服务器的物理IP地址称为DIP（目标IP）。 在我们的负载平衡系统中，有一个控制计划维护VIP到DIP映射，以及一个数据计划，通过数据包封装将目标为VIP的数据包传递给DIP。 当Pingmesh部署完毕后，Pingmesh可以通过自然扩展来监控VIP的可用性。 这再次通过扩展Pingmesh生成算法来覆盖作为目标的VIP，而不触及Pingmesh管道的其余部分。
无声数据包丢弃检测。 正如我们在第5节中讨论的那样，我们一直在使用Pingmesh进行静默数据包丢弃检测。 由于延迟数据已经存在，我们只需要找出检测算法并在DSA管道中实现该算法，而无需触及其他Pingmesh组件。
服务的网络指标。 服务开发人员使用两种Pingmesh技术来设计和实现更好的服务。 Pingmesh代理为每个服务器提供两个PA计数器：第99个延迟和丢包率。 服务开发人员可以使用第99个延迟来更好地了解服务器级别的数据中心网络延迟。 多服务器已将每服务器数据包丢弃率用作服务器选择的度量标准之一。
对于上述扩展，仅设计了DC间Pingmesh和QoS监控，其余三个刚好超出了我们的预期。 由于Pingmesh的松散耦合设计，所有这些功能都可以顺利添加，而无需调整其架构。
6.3 模式发现的可视化
我们在Pingmesh数据分析和可视化方面投入了大量资金。 我们的快乐发现是数据不言而喻，可视化有助于我们更好地理解和检测各种延迟模式。
图8显示了几种典型的可视化延迟模式。 在该图中，一个小的绿色，黄色或红色块或像素显示源 - 目标pod对之间第99百分位的网络延迟。 绿色表示延迟小于4毫秒，黄色表示延迟在4-5毫秒之间，红色表示延迟大于5毫秒。 白色块表示没有可用的延迟数据。
图8（a）显示了（几乎）全绿色模式，这意味着网络工作正常。 虽然看起来很简单，但这种全绿色图案是Pingmesh最广泛使用的功能之一。 使用这种模式，我们可以轻松地告诉网络的全球健康状况。
图8（b）显示了白十字图案。 白色十字的宽度对应于Podset，其包含大约20个豆荚。 此模式显示Podset-down方案。 Podset-down通常是由于整个Podset的功率损失。
图8（c）显示了红十字的图案。 红十字的宽度再次对应于Podset。 红叉显示来自Podset的高网络延迟。 此模式显示Podset中存在网络问题，因为其他Podset的网络延迟是正常的。 Podset红叉可能有多种原因。 如果Leaf和ToR交换机都是L3交换机，则至少有一个Leaf交换机正在丢弃数据包。 如果整个Podset是L2域，那么它可能是由广播风暴引起的，例如，由于某些交换机丢失了它们的配置。
图8（d）示出了沿对角线具有绿色方块的红色图案。 每个小绿色方块都是一个Podset。 它表明Podset中的网络延迟是正常的，但是跨Podset延迟都是网络SLA之外的。 它显示Spine交换机层的网络问题。
可视化的成功超出了我们的预期。 我们很多人习惯于定期打开可视化门户网站，看看网络是否正常。 可视化门户网站不仅被网络开发人员和工程师使用，而且还被我们的客户用于了解是否存在网络问题。 我们还观察到了一个有趣的使用模式：当可视化系统首次投入使用时，网络团队通常会使用它来向我们的客户“证明”网络状况良好。 现在，我们的客户通常使用可视化来显示存在正在进行的网络问题。 这是我们很高兴看到的使用模式更改。
6.4 Pingmesh限制
在运行Pingmesh期间，我们没有涵盖Pingmesh的两个限制。 首先，尽管Pingmesh能够检测到故障网络设备所在的层，但它无法确定准确的位置。 在我们的网络中，Spine层有几十到几百个交换机。 知道Spine层正在经历一些问题但是还不够。 我们需要尽可能快地定位和隔离故障设备的方法。 这从一开始就是Pingmesh的一个已知限制。 如第5.2节所述，我们将Pingmesh和TCP traceroute结合起来解决此问题。
第二个限制来自Pingmesh目前的延迟测量。 虽然Pingmesh Agent可以发送和接收高达64 KB的探测消息，但我们只使用SYN / SYN-ACK和单个数据包进行单个RTT测量。 单数据包RTT擅长检测网络可达性和数据包级延迟问题。 但它不包括需要多次往返的情况。 我们最近遇到了由TCP参数调整引起的实时站点事件。 我们的TCP参数配置软件中引入的错误将TCP参数重写为其默认值。 因此，对于我们的一些服务，初始拥塞窗口（ICW）从16减少到4.对于长距离TCP会话，如果会话需要多次往返，则会话结束时间增加几百毫秒。 Pingmesh没有发现这一点，因为它只测量单个数据包RTT。
- 相关工作
我们运行世界上最大的数据中心网络之一的经验告诉我们，包括应用程序，操作系统内核，NIC，交换ASIC和固件以及光纤在内的所有组件都可能导致通信故障。 有关可能导致网络分区的各种故障的摘要，请参见[4]。
[21]和[6]通过收集网络跟踪来研究不同类型数据中心的流量和流量特性。 Pingmesh专注于网络延迟，是对这些工作的补充。
Pingmesh和[18]都旨在检测网络中的数据包丢失。 两者都使用主动探测包并且能够覆盖整个网络。 然而，这些方法是不同的。 [18]使用RSVP-TE基源路由来精确定位探测数据包的路由路径。 因此，需要提前创建路由路径和地图。 这也意味着探测数据包在不同于非探测数据包所使用的LSP（标签交换路径）中穿越网络。 其次，RSVP-TE基于MPLS，虽然广泛用于WAN流量工程，但并未在数据中心内使用。 Pingmesh可用于DC内和DC间网络。 使用源路由确实提供了一个优势：[18]可以直接查明丢弃数据包的交换机或链路。 我们在5.2节中展示了Pingmesh可以将故障设备与traceroute一起定位。
Cisco IPSLA [8]也使用活动数据包进行网络性能监控。 IPSLA配置为在Cisco交换机上运行，并且能够发送ICMP，IP，UDP，TCP和HTTP数据包。 IPSLA收集网络延迟，抖动，数据包丢失，服务器响应时间甚至语音质量分数。 结果存储在交换机上，可以通过SNMP或CLI（命令行界面）检索。 Pingmesh在几个方面与IPSLA不同。 首先，Pingmesh使用服务器而不是交换机进行数据收集。 通过这样做，Pingmesh成为独立于网络设备，而IPSLA仅适用于Cisco设备。 其次，Pingmesh专注于测量和延迟数据分析。 为了实现其目标，Pingmesh不仅具有用于数据收集的Pingmesh Agent，还具有用于集中控制和数据存储和分析管道的控制平面。 IPSLA没有这样的控制平面和数据存储和分析管道。
NetSight [19]通过在交换机上引入明信片过滤器来跟踪数据包历史，以生成称为明信片的捕获数据包事件。 NetSight可以构建多种网络故障排除服务，nprof，netshark，netwatch，ndb。 与Net-Sight相比，Pingmesh基于服务器，因为它不需要在交换机中引入额外的规则。 此外，Pingmesh能够检测交换机静默数据包丢弃。 目前尚不清楚如何为NetSight编写静默数据包丢弃规则，因为事先不知道可以丢弃哪种类型的数据包。
ATPG [25]确定一组最小的探测包，涵盖所有网络链接和转发规则。 Pingmesh不会尽量减少问题的数量。 只要开销是可以承受的，我们宁愿让Pingmesh一直运行。 此外，尚不清楚ATPG如何处理无法预先确定黑洞规则的数据包黑洞。
Pingmesh专注于物理网络，它通过在服务器中安装Pingmesh Agent来使用活动探测。 但是，对于第三方虚拟机和虚拟网络，安装Pingmesh代理可能不可行。 在这种情况下，可以使用VND [24]探索的被动流量收集
- 结论
我们介绍了Pingmesh的设计和实现，用于数据中心网络延迟测量和分析。 Pingmesh始终处于启动状态，它提供所有服务器和所有服务器的网络延迟数据。 Pingmesh已经在Microsoft数据中心运行了四年多。 它可以帮助我们解决服务问题是否由网络引起，在宏观和微观层面定义和跟踪网络SLA，它已成为网络故障排除不可或缺的服务。
由于其松散耦合的设计，Pingmesh变得易于扩展。 在Pingmesh的架构仍然相同的情况下，添加了许多新功能。 通过研究Pingmesh延迟数据并通过可视化和数据挖掘从延迟模式中学习，我们能够不断提高网络质量，例如，通过自动修复数据包黑洞和检测交换机静默随机数据包丢弃。
by aprilmadaha 20190327