背景
在咱们外部产品中，始终有对于网络性能数据监控需要，咱们之前是间接应用 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 个级别：
- 在机架外部，让所有的 server 相互 ping，每个 server ping（N-1）个 server
- 在机架之间，则每个机架选几个 server ping 其余机架的 server，保障 server 所属的 ToR 不同
- 在数据中心之间，则抉择不同的数据中心的几个不同机架的 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 来主动重启交换机，复原交换机的能力。
教训学习
- 找到可信数据，只有数据起源可信，那么剖析才是无效的
- 让服务作为 daemon 运行，保障继续的收集数据
- 松耦合设计，每个组件都能够独立工作
总结
其实咱们本人的零碎是有 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 的产品，能够 分割咱们。