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

内容简介：聊聊Mesos原生健康检查（Native Health Check）

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

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

点击上面蓝色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的HTTP健康检查在探测1900个实例以后开始出现失败。

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

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

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

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

原文链接： https://dzone.com/articles/int ... erral

原文作者：Gaston Kleiman

以上所述就是小编给大家介绍的《聊聊Mesos原生健康检查（Native Health Check）》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• 零信任原生安全：超越云原生安全
• 畅谈云原生（下）：云原生的飞轮理论
• 【云原生丨主题周】云原生为何物？为何重要？
• Micronaut 2.0.0 发布，原生云原生微服务框架
• 2018云原生技术实践峰会(CNBPS) 重新定义云原生
• 云原生生态周报 Vol. 8 | Gartner 发布云原生趋势

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。