颠覆大数据分析之Mesos：集群调度及管理系统

正如前面“Mesos:动机”一节中所述，Mesos的主要目标就是去帮助管理不一样框架（或者应用栈）间的集群资源。好比说，有一个业务须要在同一个物理集群上同时运行Hadoop，Storm及Spark。这种状况下，现有的调度器是没法完成跨框架间的如此细粒度的资源共享的。Hadoop的YARN调度器是一个中央调度器，它能够容许多个框架运行在一个集群里。可是，要使用框架特定的算法或者调度策略的话就变得很难了，由于多个框架间只有一种调度算法。好比说，MPI使用的是组调度算法，而Spark用的是延迟调度。它们两个同时运行在一个集群上会致使供求关系的冲突。还有一个办法就是将集群物理拆分红多个小的集群，而后将不一样的框架独立地运行在这些小集群上。再有一个方法就是为每一个框架分配一组虚拟机。正如Regola和Ducom所说的，虚拟化被认为是一个性能瓶颈，尤为是在高性能计算（HPC）系统中。这正是Mesos适合的场景——它容许用户跨框架来管理集群资源。

Mesos是一个双层调度器。在第一层中，Mesos将必定的资源提供（以容器的形式）给对应的框架。框架在第二层接收到资源后，会运行本身的调度算法来将任务分配到Mesos所提供的这些资源上。和Hadoop YARN的这种中央调度器相比，或许它在集群资源使用方面并非那么高效。可是它带来了灵活性——好比说，多个框架实例能够运行在一个集群里。这是现有的这些调度器都没法实现的。就算是Hadoop YARN也只是尽可能争取在同一个集群上支持相似MPI这样的第三方框架而已。更重要的是，随着新框架的诞生，好比说Samza最近就被LinkedIn开源出来了——有了Mesos这些新框架能够试验性地部署到现有的集群上，和其它的框架和平共处。

Mesos组件

Mesos的关键组件是它的主从守护，正如图2.5所示，它们分别运行在Mesos的主节点和从节点上。框架或者框架部件都会托管在从节点上，框架部件包括两个进程，执行进程和调度进程。从节点会给主节点发布一个可用资源的列表。这是以<2 CPU，8GB内存>列表的形式发布的。主节点会唤起分配模块 ，它会根据配置策略来给框架分配资源。随后主节点将资源分配给框架调度器。框架调度器接收到这个请求后（若是不知足需求的话，也可能会拒绝它），会将须要运行的任务列表以及它们所需的资源发送回去。主节点将任务以及资源需求一并发送给从节点，后者会将这些信息发送给框架调度器，框架调度器会负责启动这些任务。集群中剩余的资源能够自由分配给其它的框架。接下来，只要现有的任务完成了而且集群中的资源又从新变为可用的，分配资源的过程会随着时间不断地重复。须要注意的是，框架不会去说明本身须要多少资源，若是没法知足它所请求的资源的话，它能够拒绝这些请求。为了提升这个过程的效率，Mesos让框架能够本身设置过滤器，主节点在分配资源以前总会首先检查这个条件。在实践中，框架可使用延迟调度，先等待一段时间，待获取到持有它们所需数据的节点后再进行计算。

图2.5  Mesos的架构

一旦资源分配好了，Mesos会当即提供给框架。框架响应此次请求可能会须要必定的时间。这得确保资源是加锁的，一旦框架接受了此次分配后资源是当即可用的。若是框架长时间没有响应的话，资源管理器（RM）有权撤销此次分配。

资源分配

资源分配模块是可插拔的。目前一共有两种实现——一种是Ghodsi等人（2011）提出的主导资源公平（Dominant Resource Fairness, DRF）策略。Hadoop中的公平调度器（https://issues. apache.org/jira/browse/HADOOP-3746）会按照节点的固定大小分区（也被称为槽）的粒度来分配资源。这样作的效率会差，尤为是在现代的多核处理器的异构计算环境中。DRF是最小-最大公平算法在异构资源下的一个泛化。须要注意的是，最大最小算法是一个常见的算法，它拥有许多变种好比循环以及加权公平排队，但它一般都用于同类的资源。DRF算法会确保在用户的主导资源中使用最大最小策略。（CPU密集型做业的主导资源是CPU，而IO密集型做业的主导资源则是带宽）。DRF算法中的一些有趣的特性列举以下：

• 它是公平的，而且吸引用户的一点是，它能保证若是全部资源都是静态平均分布的话，不会偏向任何一个用户。

• 用户谎报资源需求没有任何好处。

• 它具备帕累托效率，从某种意义上来讲，系统资源利用率最大化且服从分配约束。

框架能够经过API调用获取到保证分配给它们的资源大小。当Mesos必需要杀掉一些用户任务的时候，这个功能就颇有用了。若是框架分配的资源在确保的范围内的话，它的进程就不会被Mesos杀掉，若是超出了阈值，Mesos就会杀掉它的进程。

隔离

Mesos使用Linux或者Solaris容器提供了隔离功能。传统的基于hypervisor的虚拟化技术，好比基于内核的虚拟机（KVM），Xen(Barham等2003)，或者VMware，都是由基于宿主操做系统实现的虚拟机监控器组成的，这个监控器提供了虚拟机全部的硬件仿真。如此说来，每一个虚拟机都有本身专属的操做系统，这是和其它虚拟机彻底隔离开来的。Linux容器的方式是一种被称为操做系统级虚拟化的技术。操做系统级虚拟化会使用隔离用户空间实例的概念来建立一个物理机器资源的分区。本质上而言，这种方法则再也不须要基于hypervisor的虚拟化技术中所需的客户操做系统了 。也就是说，hypervisor工做于硬件抽象层，而操做系统级虚拟化工做于系统调用层。然而，给用户提供的抽象是指每一个用户空间实体都会运行本身八专属的独立的操做系统。操做系统级虚拟化的不一样实现会略有不一样，Linux-VServer是工做于chroot之上的，而OpenVZ则是工做于内核命名空间上。Mesos使用的是LXC，它经过cgroups（进程控制组）来进行资源管理，并使用内核命名空间来进行隔离。Xavier等人（2013）对它作了一份详细的性能评估报告，结果以下：[1]

 

• 从测试CPU性能的LINPACK基准测试(Dongarra 1987)来看，LXC的方式要优于Xen。

• 进行STREAM基准测试的时候，Xen的内存开销要明显大于LXC(接近30%)，然后者能提供接近原生的性能表现。

• 进行IOzone基准测试时，LXC的读，重复读，写，重写操做的性能接近于本机的性能，而Xen会产生明显的开销。

• 使用LXC进行NETPIPE基准测试的网络带宽性能接近本机性能，而Xen的开销几乎增长了40%。

• 因为使用了客户机操做系统，在Isolation Benchmark Suite (IBS)测试中，LXC的隔离性与Xen相比要较差。一个称为fork炸弹（fork bomb）的特殊测试（它会不断地重复建立子进程）代表，LXC没法限制当前建立的子进程数。

容错性

Mesos为主节点提供容错的方式是使用zookeeper（Hunt 等2010）的热备用配置来运行多个主节点，一旦主节点崩溃的话，就会选举出新的主节点。主节点的状态由三部分组成——它们分别是，活动从节点，活动框架，以及运行任务列表。新的主节点能够从从节点和框架调度器的信息中重构自身的状态。Mesos还会将框架执行器及任务报告给对应的框架，框架能够根据自身的策略来独立地处理失败。Mesos还容许框架注册多个调度器，一旦主调度器失败了，能够去链接从调度器。然而，框架得确保不一样调度器的状态是同步的。

[1] 熟悉UNIX操做系统的读者会记得，chroot是一个改变当前工做进程树根目录的命令，它会建立一个叫”chroot监狱”的环境来提供文件级别的隔离。

原创文章，转载请注明： 转载自并发编程网 – ifeve.com