《在阿里云上使用Marathon》由会员分享，可在线阅读，更多相关《在阿里云上使用Marathon（7页珍藏版）》请在金锄头文库上搜索。
1、在阿里云上使用Marathon本文章来自于阿里云云栖社区摘要：本文介绍了小博无线目前的线上环境，Mesos+Marathon,是如何做到高 可用零宕机的。基于Marathon本身的高可用模式并利用SLB API解决容器启 停的平滑切换问题，再结合运维机器人TidyMaid实现了自动伸缩。冃景之前的文章云阿里云容器服务测评(原文链接：https:/yq.aliyu nt72558.10.FzjU3R)就高可用零宕机方面对容器服务作了详细测评，本文我们介绍一下小博无 线目前的线上环境，Mesos+Marathon,是如何做到高可用零宕机的。Marathon0kMlliO处=Q MARATHON4
2、rMfiWAMiK -ComnMuidcmavctKi fwmiOM Ibr twyntwr U BlMp BOO0.11/11AOil 1/31fta*1/11#g A/10Marathon作为Mesos的容器调度框架，本身就提供了非常可靠的高可用方案：1. 自身的High Availability Mode保证了单点故障时，依然能够提供服务2. 蓝绿部署机制在新版容器健康之后再停止旧版容器，确保新旧服务平滑切换3. 当容器健康检查持续失败，Marathon会将其kill，并启动新的容器但这些还不够，因为：1. 容器可能被部署到集群内任意节点上，已有的容器也会漂移到其它节点。对于新 增/停止
3、的节点，该如何在对应的SLB中添加/移除节点2. 新版容器启动后，Marathon只能判断容器本身的健康状态，无从知道该容器对 应的SLB状态是否健康。如果在SLB的新节点还处于异常状态时就将旧版容器 停止，则会出现服务短时不可用的故障3停止容器会使其正在处理的请求被终止，并且，从停止容器到SLB感知到节点 异常，需要一定时间，这段时间被分发到已停止节点的请求也无法被正常处理4. Marathon不支持动态伸缩在阿里云上使用Marathon，基本上都会遇到这四个问题。下面介绍我们是如何 解决这些问题的。添加/移除SLB节点我们利用Maratho n的Eve nt Bus机制来解决这个问题，启动
4、Marath on时，可 以配置一个HTTP回调地址，当某些特定的事件发生时，Marathon通知回调地 址。我们部署了一个基于golang web server的运维服务平台（osp），在上面实现 了这个回调接口。该接口订阅status_update_event事件，并判断taskstatus 的值。如果taskstatus是TASK_RUNNING，那么就添加对应节点到SLB；如果是 TASK_FINISHED, TASK_KILLED, TASK_LOST, TASK_FAILED，则从 SLB 中移除 对应的后端节点。获取SLB状态如何让Marathon的健康检查获取到SLB的状态？我
5、们的设计是通过添加一个 负责查询SLB状态的中间层，并让健康检查请求这个中间层。Marathon支持三种模式的健康检查： TCP HTTP COMMAND其中TCP和HTTP只能请求容器内的端口，COMMAND则可以设置为任意shell 命令。我们在osp上实现了这样一个接口 ：查询SLB状态，如果状态为正常， 缓存结果下次不再查询，否则每次都调用SLB API进行查询。之所以缓存查询 结果，是因为SLB Health API很慢，而且有调用次数的限制。最后使用 COMMAND健康检查请求这个接口。配置如下：protocol: COMMAND,command: value”： cui -vf7
6、equestPOSTht7ip/oisp7heai7h_ch7Ck- -data host=$HOST -data ,service_name=$MARATHON_APP_ID, -dat a mesos task id=$MESOS TASK,gracePeriodSeconds: 200,intervalSeconds:_30,timeoutSeconds:_10,maxConsecutiveFailures: 5,第一版的整个流程如图:1. 中间层缓存了 SLB检查结果，在SLB状态正常后不会继续查询，所以导致 Marathon获取不到容器本身的健康状态。即使容器内服务出错，Marath
7、on依然 认为它是健康的2. 这应该算是Marathon的一个bug,如果leader节点宕机，那么所有COMMAND模式的服务的健康状态会变为状态因此我们又加入了一个中间层，它是一个部署在容器中的golang web server， 做下面两件事情：1调用运维平台API，返回结果2. 如果运维平台API返回结果为健康，缓存结果，不再请求运维平台，改为 请求容器内服务自身的OK API，返回结果由于web server位于容器内部，健康检查可以由COMMAND模式改为HTTP 模式，这样就很好地解决了上面碰到的两个问题。虽然增加了些复杂度，需要在 每个容器中嵌入这个web server，但可以
8、将这一步固化在最底层的base image 中，而且其硬件开销几乎可以忽略不计（不到2M内存）。最终的流程如下:1. 设置 Mesos 的 executor_shutdown_grace_period 和 docker_stop_timeout 参数。 如果容器收到SIGTERM信号后迟迟不停止，一分钟后再发送SIGKILL信号强制停 止容器2. 在容器内捕获SIGTERM信号，让容器在收到kill命令后不退出，继续提供服务3. 订阅Maratho n的Eve nt，在tasks tat us=TASK_KILLED时将后端节点权重置为 0测试发现这个方案不可行，原因是Marathon并不是在
9、第一次向容器发送 SIGTERM信号时，而是在发送SIGKILL信号将容器强制停止后，才触发 taskStatus=TASK_KILLED 事件，最终的方案为，在容器中捕获SIGTERM信号，之后通知运维平台容器即将被停止， 运维平台收到请求后将该容器在SLB的权重设为0。通过设置executor_shutdown_grace_period 和 docker_stop_timeout 参数为容器从收到SIGTERM信号到被强制停止之间留出一分钟，这部分时间用于SLB的断流以及 容器对已有请求的处理的平滑切换。我们在最底层的镜像中创建了服务的运行框架，其中一个python进程会将指定 的所有服务
10、启动起来。因此我们只要在这个python进程中捕获sigterm信号并 通知运维平台即可解决问题。signal(signal.SIGTERM, lambda signum, frame: shutdown_gr| ace()一年多的线上实战表明，这套解决方案是非常可靠的。无论是部署、重启、还是 停止容器，都可以做到无感知平滑漂移。动态伸缩解决了上面和SLB有关的三个问题后，能够解决容器的启动与停止过程中对服 务质量的影响。但在容器运行中，依然有可能发生影响服务的情况，例如负载的 变化。Marathon支持对每个容器配置不同的资源（CPU、内存、磁盘），也可以选择 不配置，让所有容器共用ECS资
11、源，但建议尽量不要这么做，这种做法虽然简 单，可是风险很高，让单个服务也有可能耗光ECS上的CPU或内存资源，进 而影响到部署在ECS上所有服务的服务质量。合理的资源配置参数不应是静态的，而应随着负载的变化而动态地伸缩。这里的 伸缩，分为两个方面：横向地伸缩容器的数量纵向地伸缩容器的配额然而，Marathon并不原生支持动态地伸缩容器。为了解决这个问题，我们制作 了运维机器人TidyMaid，用于采集、分析每个容器负载，判断是横向还是纵向 地伸缩服务。大致的方案为： CPU负载超限，横向伸缩服务，直至容器数量达到设定的上限或下限 内存负载超限，如果容器已经运行超过一段时间，那么直接将超限的容器
12、停止（停 止后Marathon会自动启动新容器）；否则纵向地伸缩服务，直至容器配额已经 达到设定的上限或下限该方案背后的考虑是，CPU负载的变化，一般和流量压力紧密关联，压力的变 化会立即反映在CPU负载上，横向伸缩能立即适配流量压力;但是内存则不然， 某些时候，内存负载升高，仅靠增加容器个数并不能解决问题。虽然增加容器使 每个容器的请求压力降低,但对于内存已经居高的容器，其负载并不会立即下降， 所以选择直接停止服务或者纵向伸缩（纵向伸缩会重启服务）。这样做了之后，服务在任意时刻都会处于一个合理的配置，既能负担高峰期的压 力，又不至于闲置过多的资源。可见，无感知平滑漂移是一个容器调度服务系统的必备功能。只有实现了平滑漂 移，才有可能落地快速迭代开发方式，每天线上发版数十次；只有实现了平滑漂 移，运维机器人才能放开手脚，自由的重启状态异常的容器，合理的调整容器的 配额，更好的为实现高可用零宕机服务！
