关于运维:Pingmesh在大规模系统中对多个数据中心环境下进行网络延迟的测量与分析方法

背景

在咱们外部产品中，始终有对于网络性能数据监控需要，咱们之前是间接应用 ping 命令收集后果，每台服务器去 ping (N-1) 台，也就是 N^2 的复杂度，稳定性和性能都存在一些问题，最近打算对这部分进行重写，在从新调研期间看到了 Pingmesh 这篇论文，Pingmesh 是微软用来监控数据中心网络状况而开发的软件，通过浏览这篇论文来学习下他们是怎么做的。

数据中心本身是极为简单的，其中网络波及到的设施很多就显得更为简单，一个大型数据中心都有成千盈百的节点、网卡、交换机、路由器以及有数的网线、光纤。在这些硬件设施根底上构建了很多软件，比方搜索引擎、分布式文件系统、分布式存储等等。在这些零碎运行过程中，面临一些问题：如何判断一个故障是网络故障？如何定义和追踪网络的 SLA？出了故障如何去排查？

基于这几点问题，微软设计开发了 Pingmesh，用来记录和剖析数据中心的网络状况。在微软外部 Pingmesh 每天会记录 24TB 数据，进行 2k 亿次 ping 探测，通过这些数据，微软能够很好的进行网络故障断定和及时的修复。

数据中心网络

常见的数据中心网络拓扑：

网络延时计算形式：server A 发送音讯到 server B 承受音讯的工夫。最终应用 RTT 工夫，RTT 一个益处是相对工夫，与时钟不相干。

在大多数状况下，大家不会去关怀延时具体是什么导致的，都是间接归纳于网络起因，让网络团队去排查，实际上是节约了很多人力老本。延时变高有很多起因：CPU 忙碌、服务本身 Bug、网络起因等等。往往丢包会随同着延时升高，因为丢包意味着会产生重传，所以丢包也是须要察看的重点。

因为 Pingmesh 运行在微软外部，所以依靠于微软本人的基础架构，有自动化管理系统 Autopilot，有大数据系统 Cosmos，也有相似于 SQL 的脚本语言 SCOPE。

设计

依据下面的需要，Pingmesh 先评估了现有的开源工具，不合乎的起因有很多，大多数工具都是以命令行模式出现，个别是呈现故障了去应用工具排查，而且工具提供的数据也不全面，有可能正在运行工具问题曾经解决了。当然这并不是说已有的工具没有用，只能说不适宜 Pingmesh。

Pingmesh 是松耦合设计，每个组件都是能够独立运行的，分为 3 个组件。在设计的时候须要思考几点：

• 因为要运行在所有的 server 上，所以不能占用太多的计算资源或网络资源
• 须要是灵便配置的且高可用的的
• 记录的数据须要进行正当的汇总剖析

Pingmesh 架构设计：

Controller

Controller 次要负责生成 pinglist 文件，这个文件是 XML 格局的，pinglist 的生成是很重要的，须要依据理论的数据中心网络拓扑进行及时更新。

在生成 pinglist 时，Controller 为了防止开销，分为 3 个级别：

1. 在机架外部，让所有的 server 相互 ping，每个 server ping（N-1）个 server
2. 在机架之间，则每个机架选几个 server ping 其余机架的 server，保障 server 所属的 ToR 不同
3. 在数据中心之间，则抉择不同的数据中心的几个不同机架的 server 来 ping

Controller 在生成 pinglist 文件后，通过 HTTP 提供进来，Agent 会定期获取 pinglist 来更新 agent 本人的配置，也就是咱们说的“拉”模式。Controller 须要保障高可用，因而须要在 VIP 前面配置多个实例，每个实例的算法统一，pinglist 文件内容也统一，保障可用性。

Agent

微软数据中心的每个 server 都会运行 Agent，用来真正做 ping 动作的服务。为了保障获取后果与实在的服务统一，Pingmesh 没有采纳 ICMP ping，而是采纳的 TCP/HTTP ping。所以每个 Agent 即是 Server 也是 Client。每个 ping 动作都开启一个新的连贯，次要为了缩小 Pingmesh 造成的 TCP 并发。

Agent 要保障本人是牢靠的，不会造成一些重大的结果，其次要保障本人应用的资源要足够的少，毕竟要运行在每个 server 上。两个 server ping 的周期最小是 10s，Packet 大小最大 64kb。针对灵便配置的需要，Agent 会定期去 Controller 上拉取 pinglist，如果 3 次拉取不到，那么就会删除本地已有 pinglist，进行 ping 动作。

在进行 ping 动作后，会将后果保留在内存中，当保留后果超过肯定阈值或者达到了超时工夫，就将后果上传到 Cosmos 中用于剖析，如果上传失败，会有重试，超过重试次数则将数据抛弃，保障 Agent 的内存应用。

Analysis

拿到了数据就要进行剖析，Pingmesh 会以 10min，1hour，1 天的粒度进行统计汇总，数据的实时性最快也就是 10min，Pingmesh 还借助外部的基础设施可能拿到 5min 级别的数据后果，算是一种“实时”监控吧。

网络情况

依据论文中提到的，不同负载的数据中心的数据是有很大差别的，在 P99.9 时延时大略在 10-20ms，在 P99.99 延时大略在 100+ms。对于丢包率的计算，因为没有用 ICMP ping 的形式，所以这里是一种新的计算形式，（一次失败 + 二次失败）次数 /（胜利次数）= 丢包率。这里是每次 ping 的 timeout 是 3s，windows 重传机制等待时间是 3s，下一次 ping 的 timeout 工夫是 3s，加一起也就是 9s。所以这里跟 Agent 最小探测周期 10s 是有关联的。二次失败的工夫就是（2 * RTT）+ RTO 工夫。

Pingmesh 的判断根据有两个，如果超过就报警：

• 延时超过 5ms
• 丢包率超过 10^(-3)

在论文中还提到了其余的网络故障场景，交换机的静默丢包。有可能是 A 能够连通 B，然而不能连通 C。还有可能是 A 的 i 端口能够连通 B 的 j 端口，然而 A 的 m 端口不能连通 B 的 j 端口，这些都属于交换机的静默丢包的领域。Pingmesh 通过统计这种数据，而后给交换机进行打分，当超过肯定阈值时就会通过 Autopilot 来主动重启交换机，复原交换机的能力。

教训学习

1. 找到可信数据，只有数据起源可信，那么剖析才是无效的
2. 让服务作为 daemon 运行，保障继续的收集数据
3. 松耦合设计，每个组件都能够独立工作

总结

其实咱们本人的零碎是有 Prometheus 这样的监控零碎的，然而当遇到交换机级别的间歇性故障时，Prometheus 也是故障的状态，所以也就不会收集 exporter 汇报的数据，也就更没方法产生告警了。所以如果遇到那种长时间继续的故障反而是坏事，至多咱们有一个足够的状态去排查哪里出了问题，否则真的是间歇性故障仅仅依附 ping, traceroute, iperf, netstat 之类的工具去排查是没什么成果的，只有咱们晓得过来一段时间的网络状况，能力去排查。

参考链接

• https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p139.pdf
• http://ninjadq.com/2017/04/01/linux-rto
• https://yi-ran.github.io/2019/03/27/Pingmesh-SIGCOMM-2015/

本文转载自：论文浏览《Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis》

如果您须要 Pingmesh 的产品，能够 分割咱们。