如何利用Mesos构建多任务调度系统

1. 各组件简介:
   1.1 主体还是Mesos master + Mesos agent;
   1.2 二级调度框架使用的是Marathon;
   1.3 在部署了Mesos agent的机器上同时部署monitor用于实时监控和调整Agent的可用计算资源;

   
   

2. 系统运行流程，按上图中标号顺序

   2.1 Monitor实时监控组件收集所在机器上的可用资源；

   2.2 Monitor根据所在机器上的可用资源动态调整agent的保留资源;

   2.3 Agent动态实时的将自已的保留资源上报到Mesos master;

   2.4 Mesos Master在resource offer发到Marathon;

   2.5 Marathon根据收到的resource offer和需要运行的task作资源分配, 将分配结果反馈给Mesos Master;

   2.6Mesos Master将task分配到具体的Agent上执行;

Mesos agent在业务机器上非侵入式部署

我们采用的是Mesos 1.4.1版本，用C++11编写，Mesos项目本身非常庞大,依赖库必然也很多，解决这些运行依赖问题首当其冲;

部署原则就是不改变,不污染所部署的机器环境，针对libstdc++和其他一些so, 我们不会将其安装到例如/usr/local/lib这样的系统目录, 而是在打包时采用动态更改可执行程序的rpath的方法，使其运行时从我们的安装目录加载相应的so库, 具体作法就是

1. 我们将mesos运行所需要的所有lib文件都集中放在libs目录下；

2. 编译出来的mesos可执行文件,使用patchelf来更新rpath路径,指向我们自已的libs目录即可;

3. patchelf这个工具可以在不影响可执行文件运行的前提下,修改其elf文件结构中的某些属性值,具体可参考:https://nixos.org/patchelf.html

这样部署完，Mesos agent只是一个单独的目录，卸载只需要停掉进程，删除目录就好;

说一下编译过程,虽然官网上已经介绍得比较详细,但在编译过程中还是会遇到一些问题:

1. 官网编译步骤: 请参考

   http://mesos.apache.org/documentation/latest/building/;

2. gcc官方要求是 4.8.1+, 我用了 gcc 5.4, 自己在 centos 6.2,linux 2.6.32上重新编译的;

   
   

3. 编译默认是编译java语言的binding的, 但在 编译 "Build and attach javadoc"时缺 protobuffer的jar包,没编译过, 解决方案:修改 src/java/mesos.pom.in,先找到 ``, 在它下面的 下添加 true,这样不会编译这个 javdoc, 但不影响 java binding的使用

实时监控和调整Agent所能使用的计算资源

自行开发了Monitor程序，和Agent一同部署在业务机器上，周期性的监测机器上可用资源和Agent本身所用资源;

Mesos为我们提供了动态资源保留这个超实用的功能，可以限制Agent当前针对某个Role可以使用的计算资源:

Monitor的监控评估结果就是当前Agent可以使用的计算资源;

本想着到这里这个问题就结束了，测试时发现Agent并不能在线实时调整这个动态资源保留，需要在配置文件时更新好当前能够使用的动态资源,然后重启Agent;

重启Agent是我们不能忍受的,因此我们修改了源码，通过http接口在线调整动态资源保留, 这部分其实不难,mesos http接口定义十分清晰,依葫芦画瓢就好了.

Task的快速部署和资源隔离

task的部署目前我们采用Marathon，上手简单，功能够用; 如果需要更灵活的调整策略，可能就需要自己开采框架或基于某一框架二次开发了;

task其实是有重要，紧急之分，占用资源也不尽相同。对于重要紧急任务，为了保障任务的更好运行，我们会利用Mesos attribute,在调度任务时让特定任务只跑在具有特定attributes的agent上, 这就需要为每个mesos agent设置相应的attributes;

遇到了同样的问题，mesos不能在线动态调整attributes :-(, 其实也比较简单，稍微梳理下mesos源码结构，改起来不难;

还有一个问题，attributes是动态调整的，agent如果重启了怎么办？我们为此部署了etcd集群来管理，每台agent都是etcd上的一个node, 通过etcd提供的http接口更新其attribrtes, agent会周期性的从etcd上同步;同时各agent 上的attributes信息也很容易从etcd上获得;

直接操作etcd, 删除某台agent上的attribute, 那依赖于这种attribute部署的任务会自动别调度走,不再在这台agent上运行;

task隔离问题，针对cpu和memory，mesos都是通过cgroup来完成，对于cpu的限制， 我们使用cfs方式，前提是需要判断当前kernel是否支持.对于disk的限制，目前mesos使用的是du命令周期性检测的方式;

对于cpu的限制,mesos有两种方式:

1. cpu shared方式:这种方式对 cpu 没有严格限制，机器上的任何task都可以访问机器上所有cpu资源,比如你限定的cpu使用资源是2, 这种方式可能使用到4,6或更高;

   
   

2. cpu CFS方式: 相当于配置了独占 cpu, 比如cpu配置为1，那么这个任务的 cpu 使用率就不会超过 100%, 相当于设定了一个hard limit;

在我们的大部分环境中，受限于kernel版本，mount namespace不支持，因此我们采用rootfs + chroot的方式来作简单的资源隔离;

我们定制了若干版本的rootfs, 任务打包就是将任务本身的依赖和相应rootfs结合的过程, 打包好可以放到s3等存储上，供marathon部署任务时调用。

这里我们结合marathon的一个任务部署的json配置来讲一下, 先看一个这个配置, 我将说明直接写在里面