technology

PPIO边缘云面对非标异构的海量节点如何实现快速自动巡检？

面对非标、异构、碎片化的环境，PPIO仍然提供安全、可靠、有保障的云计算服务

随着云游戏、超低延时直播、VR/AR、自动驾驶等场景的出现，延时标准从秒级进入毫秒级，超低延时将成为必然趋势，数据数量将呈指数级增长。

不断增加的终端设备和所在的应用场景对于低延时和带宽都提出了更高的要求，而边缘计算更靠近设备端，靠近用户，可以减少计算和传输延迟。

从下面这张图可以看出来，边缘云从基础设施、技术架构、硬件配置、网络环境与中心云有很大的不同。

在这样的背景下，PPIO基于共享经济的商业模式，结合大数据、云原生、分布式计算技术，汇聚网络边端侧的专业服务器资源，构建出首个覆盖全国所有省市区县的分布式云服务，为下一代低时延、高带宽、可靠安全的边缘计算场景服务。

过去3年，PPIO技术团队基于云原生架构开发了K8s@Edge这个分布式容器编排系统，可以将大规模容器分布式地运行在异构非标的边缘侧。基于人工智能和大数据系统，在硬件或网络出现故障之前，主动地将任务迁移到其他稳定的服务器上，并且迁移调度的速度可以达到秒级，从而保证了整个边缘云服务的可靠和稳定。目前已在全国30余个省，超1000个县市及区域建立了广泛覆盖的边缘节点。

而这个过程中定期对边缘节点进行巡检是必不可少的。

但与中心化的场景不同，边缘场景下巡检有很多难点：

效率不高

传统的巡检方式是通过登录机器，在机器上执行一些工具或者命令，来判断机器是否运行正常。更进一步可以将检测过程写成脚本或者程序，一次性执行，从而提升效率。

但无论如何都需要先登录机器然后执行，由于每个检查都要花费一些时间，少则几秒，多则几分钟甚至几十分钟，一旦机器的数量增加后，这种方式就要消耗非常多的时间，才能对全网所有机器进行一次检测。例如：假设检测一台机器需要 30s，全网有 5000 台机器，则共需要 30 * 5000 / 3600 = 41.67 小时。这么长的检测时间，是很难满足业务要求的，因为很难及时发现问题。

当然也可以采用分组并行检测的方式，提升效率，但总体上还是效率太低。理想的情况，全网检测的耗时，应该接近单台单次检测的耗时才是最佳的。

异构网络

首先，在边缘场景下，很多边缘节点处于内网之中，这也就意味着运维人员无法直接登录边缘节点，而必须借助复杂的端口反弹系统才能登录到边缘节点上做检测。这种方式增加了系统的复杂性，也使得故障诊断的难度有所提升。

其次，再加上有时边缘节点的网络不是很稳定，登录上后容易断开，这也导致无法正常地完成一次检测，即检测程序刚跑到一半，登录连接就断开了，导致检测过程中断，必须重新检测。因此，这也要求检测的粒度要尽可能的小，并且要支持重试机制。

长尾故障

由于 PPIO 采用共享经济模式来建设边缘节点，因此相当比例的边缘节点是通过招募来的，这加速了边缘节点的建设，但也带来了一个问题，即边缘节点的硬件资源参差不齐。由于招募来的硬件是各式各样的，因此出故障的可能性也会比硬件统一的 IDC 机房要多一些，而且很多问题是非常罕见的。例如：主板的序列号为空或异常值，同一设备两路 CPU ID 不一致，网卡异常导致 CPU 软中断过高，磁盘容量突然变地很小等等。

这些问题具有一个典型的特征，就是长尾。每一个问题涉及的机器数量不多，但问题的数量却很多。

对于每一个长尾问题，跟头部问题一样，技术人员也需要花费相当的时间和精力去诊断，但由于长尾问题涉及的机器不多，因此其通常被认为是小问题而被疏忽。技术人员在该问题定位后，不一定会将诊断方法和检测手段沉淀下来。但该问题可能在未来某一时刻又会出现，这会导致后续另一位工程师可能会花费同样的时间再诊断一次。这对于人效的消耗是非常巨大的。

让海量的机器自动检测上报，让机器找人

从问题出发

针对传统巡检方法应用到边缘计算场景后的各种问题，我们逐步开始思考解决方案。

对于效率不高的问题，可以尽可能的提高检测并行度，并行度越大就能在越短的时间内完成全网的检测。因此，理论上最大的并行度就是与全网机器数量相等，即所有机器同时进行检测。

对于异构网络的问题，可以设计避免登录机器的方案，使得整个检测过程不依赖于长连接。于是可以将检测过程与检测结果上报分离开来，可以先在边缘节点检测，并记录检测结果，之后再统一上报。同时减小检测粒度，使得很多庞杂的检测项，打散为一个一个的检测点，每个检测点都可以在很短的时间内检测完，且不同的检测点之间互不干扰。

对于长尾故障的问题，尽可能的采用积累沉淀的方式，做到每个问题只分析和研究一次，并将检测的方法能够形成可反复使用的插件，永久性的加入到检测系统中。通过这样日拱一卒的方式，积累一个庞大的检测库，把长尾故障问题逐渐解决掉。

逆向思维

从另一个角度来看，传统的巡检方式更多的是运维人员主动找故障，这种方式本身没错，但是如果当机器数量达到海量时，这种方式就带来极大的低效。那么为什么不反过来呢？与其让人找问题，还不如让问题来找人。

一个运维人员挨个检测海量机器是困难的，如果让海量的机器自行检测，然后自行上报问题，那运维人员只需要查询检测结果就可以了，这样巡检的效率就极大提升了。

Telme系统设计思路

本着让机器主动告知其故障的原则，开始设计 PPIO 自动巡检系统，首先给这个系统起了一个名字叫 telme。telme 是一个新造词，其含义就是 tell me。

telme 系统分为三个角色：

telme server，是 telme 的中心服务，运行在云端，它负责与所有边缘节点上的 telme agent 保持长连接，同时为 telme client，提供基本的管理接口。另外 telme server 背后有一个数据库支持，该数据库主要存储检测插件和检测结果。

telme agent，是 telme 的边缘服务，运行在边缘节点上，它负责与 telme server 保持连接，监听并时刻保持自己的检测插件是与中心是同步的，同时也负责周期性的执行检测脚本，并将检测结果上报到 telme server。

telme client，是 telme 的控制端，主要有运维人员使用，他负责对检测插件进行管理，并查询或清理检测结果。

插件管理

如上图，插件管理相对简单，主要的核心在于边缘节点需要实时或准实时地保持自己本地的插件集合与云端是同步的。假设边缘节点与中心之间的网络不一定是每时每刻都很稳定的，我们需要一种抗网络不稳定的同步机制，且要尽可能的减少全量同步来优化同步的开销。

这里，我们借鉴了 kubernetes 的 List-Watch 思想，让新启动的 telme agent 从 telme server 做一次检测插件的全量同步，即 List；之后让 telme agent 监听 telme server 上插件的变动，如有变化只同步变化部分，即 Watch。考虑到网络的不稳定性，因此在每次连接断开时，都要尝试做一次 List 操作，不过 List 操作可以进一步优化为，先同步所有插件的 hash 值，如果 hash 值都一致，可以直接跳过 List 阶段直接 Watch，否则则要强制 List 一次，即全量同步一次。

通过这种优化过的 List-Watch 机制，使得云边之间的数据同步达到最优化，而且非常实时，即使有部分节点因网络不稳定临时离线，重连之后状态又立刻可以和云端保持一致。