集群管理系统 Mesos 的设计原理.docxVIP

集群管理系统 Mesos 的设计原理 如下图所示的 Mesos 集群同时运转了 Hadoop 和 Mesos 两个框架，假如忽视图中与 Hadoop、MPI 框架的相关模块，我们会发觉架构会变得格外简约，它仅由 Zookeeper 集群、Mesos 主节点和工作节点组成。 图 3 - Mesos 架构图 Zookeeper 集群供应了高可用的数据存储和选举等功能； Mesos 主节点收集工作节点上报的数据并向框架的调度器供应资源； Mesos 工作节点上报数据并通过框架的执行者在本地启动任务； 每个 Mesos 集群中运转的框架都由调度器和执行者两部分组成，调度器会处理主节点供应的资源，与 Kubernetes 的调度器有着相同的作用，当调度器接受主节点供应的资源后，它会前往待运转任务的相关信息；而执行者会在工作节点上运转框架创建的任务。 Mesos 为了保证更好的可扩展性，它定义了一套能够满足资源共享的最小接口，将任务调度和执行的把握权都通过如下所示的接口交给框架，其本身仅保留较粗粒度的调度和资源管理功能。 图 4 - Mesos 接口 由于 Mesos 中的任务调度是分布式的过程，所以为了保证该过程的效率和牢靠性，它引入了下面的这三种机制： 节点过滤器：框架使用过滤器剔除集群中不满足本身调度条件的节点； 资源自动安排：为了提高框架的调度速度，会将事后供应应框架的资源计入框架的总安排资源，直到框架完成调度，这能激励框架实现更快的调度器； 资源撤回：假如框架在一段时间内没有处理主节点供应的资源，Mesos 会撤回资源并供应应其他框架； 除了供应良好的扩展性和功能之外，作为集群调度管理系统，Mesos 也面临着隔离不同任务资源的问题。在 Mesos 刚刚发布时，容器技术还没有像今日这么普及，但是它也利用操作系统的容器隔离不同工作负载的影响[^2]，并利用可插拔式的隔离模块支持多种隔离机制。 调度模型 我们在文章开篇就已经引见过 Mesos 和 Kubernetes 能够管理的集群规模有数量级的差距，这里简约对比分析下两者在调度器上的差异，这能挂念我们理解 Kubernetes 调度器在设计时做出的决策，以及这些决策是如何影响它的可扩展性。 需要留意的是，提升系统可扩展性往往都是简单的问题，而在 Kubernetes 这样浩大的系统中会显得愈加简单，Kubernetes 的调度器不是影响其可扩展性的独一因素，想要提升单个集群的规模要从多个方面入手。 Mesos 的调度器选择了两层的调度设计，其中顶层调度器仅会依据底层框架调度器的需求粗粒度地过滤集群中的节点，而框架调度器会执行真正的任务调度，将任务绑定到相应的节点上。 图 5 - 两层调度器 这种两层的调度器设计看起来虽然很简单，但是实际上它能够降低 Mesos 调度器的简单度并提高了它的可扩展性： 降低简单度：顶层调度器不需要处理真正的调度过程，它仅通过资源供应（Resource Offer）机制将一组节点交给底层调度器把握； 提高可扩展性：两层调度器设计可以更便利地接入新的框架调度器，兼容不同简单的调度策略，不同框架调度器内部可以串行为任务选择节点，提高全体调度的吞吐量； 虽然 Mesos 通过两层调度器设计供应了很强的扩展性，但是它却不能为调度决策供应全局最优解。这是由于全部的调度决策都是在整个集群中的一