背景
- 公司内部的云平台为各个业务线提供了大量的实体机和虚拟机来运行业务的服务,经过统计发现,这些分配给业务的机器cpu, memory等资源利用并不充分;
- 如何充分利用这些机器上的空闲资源又能保证业务服务的正常运行,这是个问题;
选型
- 一提到任务运行和调度,大部分人可能首先都会想到
Kubernetes(k8s) + Docker
, 跑起来如清风拂面。然而我们的业务机器大部分为centos 6.2, linux kernel 2.6的配置; - 业务正在使用的机器,不能升级内核, 不能重启机器,
k8s
这条路走不通; - 还好,这个世界总是给我们多样选择,除了
k8s
, 我们还有mesos
;
Mesos简介
- 先放上官方网站
- 简单来说,
Mesos
就是用于整个计算中心的操作系统,它统一管理计算中心所有机器的cpu, memory, disk等计算资源,按任务所需分配资源,调度任务,支持故障转移等等; - Mesos最大特点是两级资源调度, 如下图:
m2.png- 各个
Agent
上报自的 已计算资源给Master
; -
Master
给各个二级调度框架Framework
发送resource offer
; -
Framework
将其上的task
与收到的resource offer
作匹配,反馈给Master
; -
Master
将相应Framework
反馈的task
和resource offer
发送到对应的Agent
; -
Agent
使用Executor
来运行task, 并限定资源使用;
- 各个
- Mesos系统架构:http://mesos.apache.org/documentation/latest/architecture/
- 任务隔离除了支持
docker
容器技术,还提供了它自己的Mesos Containerizer, 这正是我们所需要的;
我们需要解决的几个问题
-
Mesos agent
在业务机器上非侵入式地纯净式部署; - 实时监控和调整
Agent
所能使用的计算资源; -
Task
的快速部署和资源隔离; - 集群整体运行情况的监控;
我们在以下面会依次来聊一聊这些问题~
多任务调度系统总体架构
-
架构设计图:
mesos.jpeg- 主体还是
Mesos master
+Mesos agent
; - 二级调度框架使用的是Marathon;
- 在部署了
Mesos agent
的机器上同时部署monitor
用于实时监控和调整Agent
的可用计算资源;
- 主体还是
- 系统运行流程,按上图中标号顺序
-
Monitor
实时监控收集所在机器上的可用资源; -
Monitor
根据所在机器上的可用资源动态调整agent的保留资源; -
Agent
动态实时的将自已的保留资源上报到Mesos master
; -
Mesos Master
在resource offer发到Marathon
; -
Marathon
根据收到的resource offer和需要运行的task
作资源分配, 将分配结果反馈给Mesos Master
; -
Mesos Master
将task
分配到具体的Ag
ent`上执行;
-
解决: Mesos agent
在业务机器上非侵入式地纯净式部署
- 我们采用的是Mesos 1.4.1版本,用C++11编写,众所周知,C++的依赖问题是梦魇啊~~
- 部署原则就是不改变原有机器环境,针对libstdc++和其他一些so, 我们在打包时采用动态更改可执行程序的
rpath
的方法,使其运行时从我们的安装目录加载相应的so库; - 这样部署完,
Mesos agent
只是一个单独的目录,卸载只需要停掉进程,删除目录就好;
解决:实时监控和调整Agent所能使用的计算资源
- 开发Monitor程序,和
Agent
一同部署在业务机器上,周期性的监测机器上可用资源和Agent
本身所用资源; -
Mesos
为我们提供了动态资源保留这个超实用的功能,可以限制Agent
当前针对某个Role
可以使用的计算资源; -
Monitor
的监控评估结果就是当前Agent
可以使用的计算资源; - 本想着到这里这个问题就结束了,测试时发现
Agent
并不能在线调整这个动态资源保留,需要重启Agent
; - 不得已,我们修改了源码,通过http接口在线调整动态资源保留
解决:Task的快速部署和资源隔离
-
task
的部署目前我们采用Marathon,上手简单,功能够用; 如果需要更灵活的调整策略,可能就需要自己开采框架或基于某一框架二次开发了; -
task
其实是有重要,紧急之分,占用资源也不尽相同。对于重要紧急任务,为了保障任务的更好运行,我们会利用Mesos attribute,在调度任务时让特定任务只跑在具有特定attributes
的agent
上; - 遇到了同样的问题,mesos不能在线动态调整
attributes
:-( 来来来,源码改起来~~~其实都比较简单,稍微梳理下mesos源码结构,改起来不难; - 还有一个问题,
attributes
是动态调整的,agent
如果重启了怎么办?我们为此部署了etcd集群,这台agent都是etcd上的一个node, 通过etcd
提供的http接口更新其attribrtes
,agent
会周期性的从etcd
上同步;同时各agent
上的attributes
信息也很容易从etcd
上获得。 - task隔离问题,针对cpu和memory,mesos都是通过cgroup来完成,对于cpu的限制, 我们使用
cfs
方式,前提是需要判断当前kernel是否支持.对于disk的限制,目前mesos使用的是du
命令周期性检测的方式; - 在我们的大部分环境中,受限于kernel版本,mount namespace不支持,因为我们采用
rootfs + chroot
的方式; - 我们定制了若干版本的
rootfs
, 任务打包就是将任务本身的依赖和相应rootfs
结合的过程, 打包好可以放到s3等存储上,供marathon等调用。
解决:集群整体运行情况的监控
- 机器本身的基础监控由公司统一监控;
- 我们主要关注task的调整运行情况,目前的方案是mesos-exporter和mesos-agent(或mesos-master)一起部署,上报监控信息到prometheus,使用grafana来展示。
网友评论