在阿里云上使用Marathon

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: 本文介绍了小博无线目前的线上环境,Mesos+Marathon,是如何做到高可用零宕机的。基于Marathon本身的高可用模式并利用SLB API解决容器启停的平滑切换问题,再结合运维机器人TidyMaid实现了自动伸缩。

背景

之前的文章《阿里云容器服务测评》就高可用零宕机方面对容器服务作了详细测评,本文我们介绍一下小博无线目前的线上环境,Mesos+Marathon,是如何做到高可用零宕机的。

Marathon

marathon_web_console

Marathon作为Mesos的容器调度框架,本身就提供了非常可靠的高可用方案:

  1. 自身的High Availability Mode保证了单点故障时,依然能够提供服务
  2. 蓝绿部署机制在新版容器健康之后再停止旧版容器,确保新旧服务平滑切换
  3. 当容器健康检查持续失败,Marathon会将其kill,并启动新的容器

但这些还不够,因为:

  1. 容器可能被部署到集群内任意节点上,已有的容器也会漂移到其它节点。对于新增/停止的节点,该如何在对应的SLB中添加/移除节点
  2. 新版容器启动后,Marathon只能判断容器本身的健康状态,无从知道该容器对应的SLB状态是否健康。如果在SLB的新节点还处于异常状态时就将旧版容器停止,则会出现服务短时不可用的故障
  3. 停止容器会使其正在处理的请求被终止,并且,从停止容器到SLB感知到节点异常,需要一定时间,这段时间被分发到已停止节点的请求也无法被正常处理
  4. Marathon不支持动态伸缩

在阿里云上使用Marathon,基本上都会遇到这四个问题。下面介绍我们是如何解决这些问题的。

添加/移除SLB节点

我们利用Marathon的Event Bus机制来解决这个问题,启动Marathon时,可以配置一个HTTP回调地址,当某些特定的事件发生时,Marathon通知回调地址。

我们部署了一个基于golang web server的运维服务平台(osp),在上面实现了这个回调接口。该接口订阅status_update_event事件,并判断taskStatus的值。如果taskStatusTASK_RUNNING,那么就添加对应节点到SLB;如果是[TASK_FINISHED, TASK_KILLED, TASK_LOST, TASK_FAILED],则从SLB中移除对应的后端节点。

获取SLB状态

如何让Marathon的健康检查获取到SLB的状态?我们的设计是通过添加一个负责查询SLB状态的中间层,并让健康检查请求这个中间层。

Marathon支持三种模式的健康检查:

  • TCP
  • HTTP
  • COMMAND

其中TCP和HTTP只能请求容器内的端口,COMMAND则可以设置为任意shell命令。我们在osp上实现了这样一个接口:查询SLB状态,如果状态为『正常』,缓存结果下次不再查询,否则每次都调用SLB API进行查询。之所以缓存查询结果,是因为SLB Health API很慢,而且有调用次数的限制。最后使用COMMAND健康检查请求这个接口。配置如下:

      "protocol": "COMMAND",
      "command": {
        "value": "curl -v -f --request POST 'http://osp/health_check' --data 'host=$HOST' --data 'service_name=$MARATHON_APP_ID' --data 'mesos_task_id=$MESOS_TASK_ID'"
      },
      "gracePeriodSeconds": 200,
      "intervalSeconds": 30,
      "timeoutSeconds": 10,
      "maxConsecutiveFailures": 5,

第一版的整个流程如图:

marathon_slb_status_v1

这个流程存在以下不足:

  1. 中间层缓存了SLB检查结果,在SLB状态正常后不会继续查询,所以导致Marathon获取不到容器本身的健康状态。即使容器内服务出错,Marathon依然认为它是健康的
  2. 这应该算是Marathon的一个bug,如果leader节点宕机,那么所有COMMAND模式的服务的健康状态会变为unknown状态

因此我们又加入了一个中间层,它是一个部署在容器中的golang web server,做下面两件事情:

  1. 调用运维平台API,返回结果
  2. 如果运维平台API返回结果为『健康』,缓存结果,不再请求运维平台,改为请求容器内服务自身的OK API,返回结果

由于web server位于容器内部,健康检查可以由COMMAND模式改为HTTP模式,这样就很好地解决了上面碰到的两个问题。虽然增加了些复杂度,需要在每个容器中嵌入这个web server,但可以将这一步固化在最底层的base image中,而且其硬件开销几乎可以忽略不计(不到2M内存)。

最终的流程如下:

marathon_slb_status_v2

停止容器前通知SLB

这个问题我们起初期望通过Event Bus来解决:

  1. 设置Mesos的executor_shutdown_grace_perioddocker_stop_timeout参数。如果容器收到SIGTERM信号后迟迟不停止,一分钟后再发送SIGKILL信号强制停止容器
  2. 在容器内捕获SIGTERM信号,让容器在收到kill命令后不退出,继续提供服务
  3. 订阅Marathon的Event,在taskStatus==TASK_KILLED时将后端节点权重置为0

测试发现这个方案不可行,原因是Marathon并不是在第一次向容器发送SIGTERM信号时,而是在发送SIGKILL信号将容器强制停止后,才触发taskStatus==TASK_KILLED事件,

最终的方案为,在容器中捕获SIGTERM信号,之后通知运维平台容器即将被停止,运维平台收到请求后将该容器在SLB的权重设为0。通过设置executor_shutdown_grace_perioddocker_stop_timeout参数为容器从收到SIGTERM信号到被强制停止之间留出一分钟,这部分时间用于SLB的断流以及容器对已有请求的处理的平滑切换。

我们在最底层的镜像中创建了服务的运行框架,其中一个python进程会将指定的所有服务启动起来。因此我们只要在这个python进程中捕获SIGTERM信号并通知运维平台即可解决问题。

signal.signal(signal.SIGTERM, lambda signum, frame: shutdown_grace())

一年多的线上实战表明,这套解决方案是非常可靠的。无论是部署、重启、还是停止容器,都可以做到无感知平滑漂移。

动态伸缩

解决了上面和SLB有关的三个问题后,能够解决容器的启动与停止过程中对服务质量的影响。但在容器运行中,依然有可能发生影响服务的情况,例如负载的变化。

Marathon支持对每个容器配置不同的资源(CPU、内存、磁盘),也可以选择不配置,让所有容器共用ECS资源,但建议尽量不要这么做,这种做法虽然简单,可是风险很高,让单个服务也有可能耗光ECS上的CPU或内存资源,进而影响到部署在ECS上所有服务的服务质量。

合理的资源配置参数不应是静态的,而应随着负载的变化而动态地伸缩。这里的伸缩,分为两个方面:

  • 横向地伸缩容器的数量
  • 纵向地伸缩容器的配额

然而,Marathon并不原生支持动态地伸缩容器。为了解决这个问题,我们制作了运维机器人TidyMaid,用于采集、分析每个容器负载,判断是横向还是纵向地伸缩服务。大致的方案为:

  • CPU负载超限,横向伸缩服务,直至容器数量达到设定的上限或下限
  • 内存负载超限,如果容器已经运行超过一段时间,那么直接将超限的容器停止(停止后Marathon会自动启动新容器);否则纵向地伸缩服务,直至容器配额已经达到设定的上限或下限

该方案背后的考虑是,CPU负载的变化,一般和流量压力紧密关联,压力的变化会立即反映在CPU负载上,横向伸缩能立即适配流量压力;但是内存则不然,某些时候,内存负载升高,仅靠增加容器个数并不能解决问题。虽然增加容器使每个容器的请求压力降低,但对于内存已经居高的容器,其负载并不会立即下降,所以选择直接停止服务或者纵向伸缩(纵向伸缩会重启服务)。

这样做了之后,服务在任意时刻都会处于一个合理的配置,既能负担高峰期的压力,又不至于闲置过多的资源。

可见,无感知平滑漂移是一个容器调度服务系统的必备功能。只有实现了平滑漂移,才有可能落地快速迭代开发方式,每天线上发版数十次;只有实现了平滑漂移,运维机器人才能放开手脚,自由的重启状态异常的容器,合理的调整容器的配额,更好的为实现高可用零宕机服务!

相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
存储 Kubernetes 负载均衡
「容器云平台」Mesos 和 Kubernetes的比较
「容器云平台」Mesos 和 Kubernetes的比较
|
Kubernetes Apache Docker
正确认识Docker、Kubernetes 、Apache Mesos
无数的文章、社交媒体在探讨~~Docker、Kubernetes、Mesos~~三者之间孰优孰劣。如果你听信了某些一知半解者的言论,你可能会认为这三个开源项目正在为争夺容器霸权而殊死战斗。同时,你也会相信,在这三者间的选择无异于对其所奉宗教的信仰,而且真正的信徒敢于大胆和异教徒作斗争,并且拥护自己的信仰。
2855 0
|
Kubernetes 应用服务中间件 nginx
阿里云Kubernetes容器服务上体验Federation v2
概述 随着容器技术的发展和普及,以Kubernetes为标准的容器技术已经成为云计算事实标准。在业务形态和云灾备场景下,需要服务进行多地域部署,这就需要对k8s不同地域的集群进行管理。Federation(集群联邦)是k8s社区中重要的多云管理项目,实现了跨地区跨服务商管理多个k8s集群的功能。
3135 0
|
监控 Kubernetes Cloud Native
分享Docker监控体系(Kubernetes Mesos监控)
常不释放资源,造成高CPU占用;比如进程结束异常,不停的重启相同的进程;比如日志级别设置过低,大量日志输出,影响进程性能和占用大量磁盘空间。所以做监控时一定要遵循有自我安全控制的能力。监控工具在拿到生产环境中运行前,一定要先在测试环境中进行一段时间的试运行 。
1735 0
|
Kubernetes 网络协议 Docker
Swarm Kubernetes Marathon 编排引擎对比剖析
Docker Native Orchestration 基本结构 Docker Engine 1.12 集成了原生的编排引擎,用以替换了之前独立的Docker Swarm项目。Docker原生集群(Swarm)同时包括了(Docker Engine \/ Daemons),这使原生docker可以任意充当集群的管理(manager)或工作(worker)节点角色。
2268 0
|
调度
nomad的简易集群
学习使用nomad 上期consul搭建完成以后,就可以根据这期的内容,部署nomad服务,nomad会自动找到本机的8500consul端口,主动去注册服务。 启动服务器 第一步是为服务器创建配置文件。
1575 0
|
Kubernetes 调度 Docker
|
应用服务中间件 nginx 数据格式
|
分布式计算 Kubernetes 调度

热门文章

最新文章