聊聊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个实例以后开始出现失败。
image

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

image

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

image

image

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

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

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

原文作者:Gaston Kleiman

0 个评论

要回复文章请先登录注册