Mesos是apache的开源项目,是使用C++开发的资源管理框架。假设我们的数据中心有众多的服务器,这些服务器要运行业务程序,业务程序随着业务规模的增加往往需要扩容,在运维层面会遇到的问题是,运维无法准确把握资源分配是否合理,扩容是否需要购买和上架新的机器。这就造成了硬件资源往往是比实际需要的要宽裕的,但是由于资源利用率不高,安排不合理,无法真正利用硬件资源,造成了浪费,这种情况只会变得越来越糟,因为应用程序变得越来越多,越来越复杂,造成越来越无法掌控的局面。
急需一种资源管理软件,能够站在数据中心的角度,对硬件资源(这里的硬件资源是指服务器的CPU,内存,硬盘)进行统一的规划、分配、管理。Mesos就是这样的一个框架软件。需要注意的是Mesos本身只是一种资源管理框架,讲白了,mesos只能提供了如下几种主要的能力:
- 告诉你有当前数据中心总共有多少CPU,内存,硬盘
- 提供一系列的接口,提供应用程序下发、执行、资源配额设置
为了实现这种功能,我们首先需要在数据中心的服务器上,安装并启动mesos-slave
,在某几台管理节点上安装mesos-master
。mesos-master提供了api,以及一个简单的界面可以看到资源分配和分布情况。slave会上报资源到master汇总。slave的另一个功能是通过执行器,执行应用程序,并使用linux自带的资源隔离机制(cgroups等)为应用程序提供运行沙盒,这样应用程序对硬件的资源占用可以精确的被控制,不会对同一台机器上的其他进程造成资源的争用。
mesos的启动需要zookeeper作为协调器,mesos会在zk的/mesos
目录下进行配置管理和存储。
然而,为什么说Mesos是个框架软件呢?因为,Mesos并不做编排管理,编排(orchestration
)的策略和逻辑需要另一个程序协助完成,mesos将编排的逻辑开放给其他程序来做,这个程序在mesos中叫Framework
。
mesos之所以将编排的任务交出来,是因为编排的需求是发散的,无法收敛。比如:考虑到高可用,会部署同一个应用程序的多个实例,这些实例需要跨虚拟机,还是物理机,甚至是机架、机房?这个编排是根据具体的需求定的,无法一概而论。
Marathon首页的第一句话就是
Marathon is a production-grade container orchestration
platform...
因此,Marathon就是一个基于mesos的编排工具,它通过与mesos-master
通信,调用接口,实现通用的编排策略。而Marathon自身又提供了接口,使得应用程序的部署得以更简单。
marathon是scala开发的,本身也依赖zookeeper,除了提供api接口外,还提供了一个十分易用的web界面,使得我们即使不调用api,也可以通过web界面实现应用部署。
因此,对于mesos来说,marathon是一个framework,但并不是mesos的唯一选择。甚至在运行时,mesos支持多个framework同时注册和运行。
关于如何开发一个framework参见 Framework Development Guide
早期版本的mesos需要用C++或java或python的library进行,1.0以后,mesos实现了http接口,使得理论上可以使用任何语言开发framework。
RENDLER项目使用了包括go,heskell在内语言实现了一个分布式爬虫编排器。
不过mesos的http api还是有些复杂的,因为许多回调行为通过http模拟有些复杂,所以mesos基于http api封装了不同语言的库以便集成。比如go语言的https://github.com/mesos/mesos-go
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。