聊聊Mesos原生健康检查（Native Health Check）

Posted 2021-04-24 云技术实践

Mesos 1. 2 . 0即将发布，这个版本会有一个非常全面的健康检查相关功能。

但是你知道吗，数人云Mesos开源调度器Swan（https://github.com/Dataman-Cloud/swan）在设计之初就已经意识到Marathon健康检查的问题。同时在接口上兼容了Marathon，方便用户从Marathon迁移任务到Swan上时做到无痛。

复制上面网址即可体验，欢迎 Star & Fork。

言归正传，我们还是来说一说Mesos 1. 2. 0的健康检查。

即将发布的Mesos 1.2.0中包含了一个非常全面的健康检查相关功能，即Mesos原生健康检查。严格意义上来讲，自Mesos 0.20 开始开始就已经内置了对健康检查的支持，不过一直被标记为实验版本，至此 1.2.0 版本的发布，才考虑将此功能标记为稳定版。

为什么是“原生支持”？第一，这样听起来很酷；第二，因为健康检查是由Mesos-Executor来执行并且通过Mesos API表现出来（HTTP API和Protobuf）。

本文将分两部分来说明健康检查的功能：

• 第一部分，将讨论一些关于设计决策和实现细节相关的内容。

• 第二部分，会着重说明一下关于配置可扩展性的健康检查以及Marathon的健康检查。

设计决策和实现细节

为什么需要健康检查

如果应用异常退出，那么一定是有程序内部哪里出了问题。Mesos会检测且上报这样的错误到调度的Framework。但是，并不是所有的应用都涉及成是“fail fast”，有可能出了问题以后还继续执行，不过展现出的行为已经出错了。如何检测这样的程序问题是很难的，为了解决这样的问题，一些Mesos Framework比如Marathon或者Aurora实现了自己的健康检查模块。

下面来看一下Marathon是如何解决HTTP的健康检查的。用户在应用的描述文件中指明需要HTTP层面的健康监测，Marathon根据用户的请求分析出实例的具体运行时IP和端口，定时发送HTTP请求到用户的应用上，分析返回结果。Marathon的这种直观易用的健康检查方式存在了两年以上了。过去两年中也暴露了一些问题，比如：

• Marathon的健康检查方式仅限于Marathon自己，Mesos层面没有支持，导致用户使用其他Framework时会产生兼容性的问题。

• 健康检查的检测进程和实例进程不在同一主机上，增加了额外的网络负担，由于网络环境的不稳定可能导致健康检查的错误结果。

• Marathon作为一个调度框架来说，同时做健康检查可能引起过高的IO负载。
  

这就是为什么要实现Mesos层面健康检查的原因，一个更统一而且可扩展的解决方案。

设计决策和实现细节

初识Mesos原生健康检查

其初衷是解放Framework开发者设计自己健康检查API，在所有调度器和执行器过程中定义健康检查的保准化，设计了针对TCP、HTTP、COMMAND三种健康检查的方式，每种都有不同的参数需要用户提供。

统一的API只是一半的工作，大家知道不同的Executor下执行健康检查的方式区别很大，兼容所有executor的健康检查是非常繁重的工作。为此，其设计了一套独立的健康检查模块来帮助Framework开发者减轻工作量。

内置的几种Executor也使用了这一套新的健康检查模块，自定义的Executor也同时可以使用，不管executor是进程、或线程还是其他。

健康检查模块最主要的工作是进入到合适的实例网络 namespace 里面，这样健康检查的执行环境就一直是 127.0.0.1，尽可能离要检查的实例网络近一些。而且越过了比如overlay网络，或者负载均衡等。这样意味着当网络不稳定时也不会影响到健康检查。

因Mesos原生的健康检查是执行在不同的Agent之上，所有健康检查的负载分布在不同机器上，这样的话横向扩展就不会增加Mesos Master节点的压力。

设计决策和实现细节

Mesos原生健康检查有哪些坑？

每次健康检查时都有单独的命令在Agent上执行。

凡事有两面性，Mesos原生健康检查会消耗Agent上的资源，另外，fork-execing（发起自进程的一种办法）然后进入实例的namespace会有不小的消耗，下面会详细地说明损耗。

因为进入到进程的namespace执行，所以健康检查的进程消耗会计算到实例的损耗里面，故而前期做资源消耗计算时要考虑健康检查。

健康检查程序是和实例运行在相同的cgroup和namespace里面，所以健康检查程序的执行会受到实例的影响，比如有可能健康检查程序由于实例过于消耗资源而得不到执行。即使设置了CFS标示。由于健康检查是检查本地 127.0.0.1 的网卡上，所以健康检查的安全性很高，不过同时要求实例应用需要监听loopback上，但由于生产环境Marathon之类通过负载均衡把服务暴露出去，所以实例要在保证健康检查的同时需要和负载均衡可达到的任务，需监听更多网卡。

可扩展性健康检查及Marathon的健康检查

扩展性

通过一些实验，会发现Marathon的HTTP健康检查在探测1900个实例以后开始出现失败。

tcp情况会好一些，不过3700个实例之后Marathon开始变得完全不动。

而Mesos原生健康检查完全克服了这个问题， 对Master没有任何压力。

本文作者在此blog的第二部分中，详细描述了对比试验的过程：在AWS上搭建Mesos、 Marathon的集群，通过Python脚本分别测试了Marathon 的HTTP， TCP健康检查， 以及Mesos内置的HTTP和TCP健康检查。

通过对比实验发现，Marathon的健康检查在实例达到一定数量之后都有着严重的性能瓶颈，而Mesos原生健康检查没有此类瓶颈。

原文链接：https://dzone.com/articles/introducing-mesos-native-health-checks-in-apache-m?utm_source=tuicool&utm_medium=referral

---

不得不说Mesos的功能实在是越来越完善了，而MesosCon Asia2017也将于6月20—22日在北京国家会议中心举行，届时会有中国联通、中国移动、腾讯、携程、IBM、ARM、Twitter等国内外多家顶级互联网科技公司在大会上进行分享。

本文转载自数人云

ID：dmesos

完

相关阅读：