背景
当今的数字化世界离不开无处不在的网络连接。无论是日常生活中的社交媒体、电子商务，还是企业级应用程序和云服务，咱们对网络的依赖水平越来越高。然而，网络的可靠性和性能往往是一个简单的问题，尤其是在具备大规模分布式架构的零碎中。
在过来，网络监控次要依赖于传统的点对点（point-to-point）形式，通过独自的监控工具对网络门路进行测试。然而，这种办法往往只能提供无限的信息，并且无奈全面评估整个网络的健康状况。为了更好地理解网络的运行状况以及及时发现潜在的问题，Pingmesh 技术应运而生。
Pingmesh 的提出最后是来自微软，在微软外部 Pingmesh 每天会记录 24TB 数据，进行 2000 亿次 ping 探测，通过这些数据，微软能够很好的进行网络故障断定和及时的修复。
上面是 Flashcat Pingmesh 的页面样例，能够清晰地看到各个机房之间的网络状况，也能够看到各个机柜或交换机之间的状况：
业界计划
业界对Pingmesh的实现大都基于微软的一则论文为根底，做出了一些革新和降级。原微软Pingmesh论文地址：
《Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis》。
常见的数据中心网络拓扑：
在这样的架构中，有多个数据中心，数据中心之间有专线连通，在数据中心外部有多个Spine、Leaf、ToR交换机，在一些架构中，leaf交换机也会间接充当ToR作为服务器接入交换机，在 ToR 交换机下有大量服务器连贯；
因而，pingmesh 能力就分为3 个级别：
- 在机架外部，让所有的 server 相互 ping，每个 server ping 机架内其余 N-1 个 server
- 在机架之间，则每个机架选几个 server ping 其余机架的 server，保障 server 所属的 ToR 不同
- 在数据中心之间，则抉择不同的数据中心的几个不同机架的 server 来ping
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 的内存应用。
网络情况
依据论文中提到的，不同负载的数据中心的数据是有很大差别的，在 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 来主动重启交换机，复原交换机的能力。
Flashcat-Pingmesh 计划
业界计划大都实现了各自的ping-agent的能力，但对于controller生成pinglist的能力并未有好的开源计划。同时咱们和一些客户交换，理解到目前数据中心架构与传统的leaf-tor-server架构不太一样，传统一个机顶交换机下server都在一个机柜下，当初数据中心一个交换机下机器可能在不同机柜，这种状况如果还是按交换机维度进行探测，当server机器探测故障后，无奈疾速定位到机器地位。因而，咱们在开发之前就针对Tor以及机柜维度进行了设计。
Pimgesh应具备哪些能力？
- 具备最根底的Ping探测能力，即ICMP协定反对，同时也应反对TCP、UDP等协定的端口探测；
- 简化页面用户配置，用户只需配置数据中心名字、交换机CIDR值，数据中心反对的探测协定和端口等要害信息；
- 数据中心会有很多机柜、交换机和机器，如何防止ping风暴，因而需反对配置选取局部机柜、替换和机器进行探测，及探测比例配置，用户可灵便配置数据中心参加探测的交换机或机柜比例数，以及每个交换机或机柜下参加探测的Server比例数；
- 每个数据中心外部、默认所有机柜或交换机之间进行探测(Server比例数仍旧失效)
- 每个数据中心之间，用户可配置默认规定，即两两数据中心之间，依照配置的协定进行探测。当然，用户也可自定义哪些数据中心之间依照所选协定进行探测，此时机柜或交换机以及Server比例数仍旧失效；
- 探测后果进行无效聚合展现，多个数据中心有很多机柜或交换机以及机器，分三层构造展现探测后果，第一层展现所有数据中心之间的探测链路拓扑以及探测值、第二层展现数据中心外部每个机柜或交换机之间的探测拓扑和后果、第三层展现机柜或交换机上面所选Server之间的探测拓扑和后果；
- Ping故障一键进行探测的止损能力；
- 探测机器故障后，主动从新选替补机器能力；
- 数据中心配置变更后，能及时主动以新配置从新生成pinglist；
- 反对简便地配置报警规定；
- 探测后果写入反对prometheus协定的时序库中；
交换机和机柜模式配置差别
- 交换机模式，页面用户只需配置替换CIDR值即可，无需手动注册Server IP，咱们会借助 Categraf 的心跳性能，主动判断出server ip应归属哪个交换机。
- 机柜模式，这种形式个别实用于客户环境中有本人的CMDB零碎，可将其CMDB零碎中的数据中心、机柜和机器关系通过OpenApi注册到Pingmesh零碎中。
Pingmesh 架构设计：
Apiserver
提供OpenApi:
- 用于注册、变更、查问数据中心原信息、探测规定(如：数据中心、探测协定、Tor交换机CIDR/机柜名、机器IP和机器名(机柜形式)、 探测百分比设置、数据中心之间探测规定设置 )。
- 数据中心三层构造拓扑图展现，以及历史探测曲线图、报警规定配置、一键降级等API。
- 提供给Categraf应用的查问pinglist接口。
Controller
生成pinglist的外围控制器逻辑，它须要定时从DB中查问最新的配置和规定，判断是否有产生变更，如果产生变更则从新执行pinglist生成逻辑。
从DB中查到配置后，判断是机柜模式还是交换机模式，因为这两种形式，其筛查Server IP的逻辑会有差别，之后需计算出每个数据中心，待探测的机柜或交换机是哪些，以及其下的Server Ip别离是多少，做好数据筹备工作。接下来查看探测规定（数据中心内、数据中心之间），依据这些规定咱们对每一台发动探测的Server 生成探测配置，并记录到DB中(因为咱们底层真正执行探测工作的是Categraf Agent，需依据不同协定所应用的插件，生成不同的配置文件)。
此外，咱们需新起一个协程，定时去比照新用户配置和已生成的pinglist是否统一，因为可能在咱们生成新的pinglist后的一段时间内，用户变更或新增、删除了数据中心配置和规定，那须要将已生成的pinglist进行比照清理，防止用户配置变更后，仍旧应用老的配置去探测，导致数据不准问题。
实现过程中还须要思考另一个问题，数据中心有很多机器，但不是所有机器都装有categraf，或装有categraf但过程退出了等状况，如果咱们只是单纯地按所有的机器数量去筛选一堆Server IP，那很有可能选出的机器都没有装agent，那也就无奈进行探测和发现问题了，因而咱们须要联合categraf本身的心跳上报的能力，来过滤出可用的Server IP。到了这里，咱们可能会想到另一个问题，因为咱们是按比例筛选机器的，而当某台机器down掉后，本来选了10台，当初只有9台可用机器了，这就会和用户配置的参加探测的服务器比例呈现diff。呈现这种状况，那咱们就须要从新选一台可用机器补上去。当抉择进去这批机器后，前面都须要始终用这些机器，除非遇到从新选的状况，这样能够保障咱们指标量是固定的，同时也能满足探测的比例需要。
探测Agent
Pingmesh底层真正执行探测逻辑的是咱们的Categraf，它是一个开源的我的项目，插件丰盛、配置简略，这里就不做过多介绍了，大家可在github上搜寻下即可。Categraf 会定时来核心端拉取本机的采集插件配置，当然，可能部署categraf的集群很多，这里核心端会将配置文件缓存到Redis中，升高对DB的查问压力，并晋升接口查问效率。最终categraf会拿到最新的插件配置并进行探测，之后将探测后果上报给核心端，用于数据展现和报警配置应用。
额定说一点，如果存在边缘机房，那categraf能够将探测后果上报给边缘机房的 n9e-edge 模块，之后报警就可在这边缘机房外部闭环了，而且edge 会主动将指标转发给时序库，用于页面展现应用。
小结
Pingmesh 在简单网络问题的排查中施展了微小的作用，本文分享了 Pingmesh 的实现思路，欢送大家 分割咱们试用。
发表回复