分布式架构的根基-Mesos
Posted 通信互联网技术笔记
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分布式架构的根基-Mesos相关的知识，希望对你有一定的参考价值。
请长按扫码关注
通信互联网笔记——易懂的通信IT知识共享平台
摘要
Mesos是Apache下的开源分布式资源管理框架（或者说Mesos是Apache的一个开源项目），所以Mesos的本质是资源管理调度平台，它被称为是分布式系统的内核。Mesos是一个通用的集群管理器，其目标就是在不同的Framework之间高效的共享硬件资源。这篇文章仅是从概念层面介绍一下Mesos是干啥的，不涉及难懂的技术，文中会对提到专业概念进行形象比喻。
Mesosphere是一家成立于2012年的云计算公司，提供所谓的数据中心操作系统服务，DCOS就是Mesosphere开发的开源数据中心操作系统[注意DCOS就是操作系统了，除了Mesos的资源调度还加了别的能力]，除了mesos分布式内核外还集成marathon和mesos-dns等组件，能够提供完整的服务治理、应用监控、权限管理能力。
DCOS（数据中心操作系统）即是Mesos的“核心”与其周边的服务及功能组件所组成的一个生态系统。它即是意味着一个跨越在数据中心或者云环境所有主机之上的操作系统。DCOS 可以运行在任意的现代Linux环境，公有或私有云，虚拟机甚至是裸机环境。（当前所支持的平台有：亚马逊AWS、谷歌GCE、微软Azure、OpenStack、Vmware、RedHat、CentOS、CoreOS以及Ubuntu）。迄今为止，DCOS 在其公有仓库上已经提供了多达40余种服务组件（Hadoop、Spark、Cassandra、Jenkins、Kafka、MemSQL等等）。
我们可以认为：DCOS=Mesos（总体控制）+Zookeeper（资源发现预注册）+Marathon（任务调度）+Docker（资源管理）
Apache是一款软件开源协议，也是基于这个协议的一个组织
Framework即架构，它是一个语言开发软件，提供了软件开发的框架，使开发更具工程性、简便性和稳定性。在Framework下可以形成不同的应用框架例如Hadoop、MPI等。（Framework可以理解为是实际干活的，是 Mesos 上跑的应用）
Framework 分两种：一种是对资源需求可以 scale(扩展) up 或者 down 的（Hadoop、Spark）；一种是对资源需求大小是固定的（MPI）。
MPI是基于消息传递的并行计算框架，MPI从数据存储节点读取需要处理的数据分配给各个计算节点=>数据处理=>数据处理。
一般Hadoop, Spark, MPI三种计算框架会放在一起比较，讲hadoop的时候我会一起介绍。
Zookeeper是一个开放源码的分布式应用程序协调服务，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，主要完成服务发现注册与服务配置的功能。
在面向对象程序设计中，“类”在实例化之后叫做一个“实例”。 “类”是静态的，不占进程内存，而“实例”拥有动态内存（实例是位于内存中的）。在数据库中，代表一些程序的集合，如Oracle中，实例就是一些能支撑数据库运行的数据库程序。
实例（instance）和对象（object）的区别：实例和对象基本上是同义词，它们常常可以互换使用。对象代表了类的一个特定的实例。对象具有身份（identity）和属性值（attribute values）2个特征。实例是对象的具体表示，操作可以作用于实例，实例可以有状态地存储操作结果。实例被用来模拟现实世界中存在的、具体的或原型的东西。
Mesos的本质是资源管理与调度平台，目前比较有名的开源资源统一管理和调度平台有两个，一个是Mesos，另外一个是YARN。
不同的分布式运算框架(spark、hadoop、ES、MPI、Cassandra、etc.)中的不同任务往往需要的资源（内存，CPU，网络IO【网络IO指出口入口】等）不同，它们运行在同一个集群中，会相互干扰，为此，应该提供一种资源隔离机制避免任务之间由资源争用导致效率下降,考虑到资源利用率，运维成本，数据共享等因素，公司一般希望将所有这些框架部署到一个公共的集群中，让它们共享集群的资源，并对资源进行统一使用，这样，便诞生了资源统一管理与调度平台,典型的代表就是mesos和yarn。
Mesos的目标就是在不同的Framework【架构】之间高效的共享硬件资源，同时简化自身的调度逻辑，使其具有尽可能大的兼容性和可扩展性，以保证在大规模集群使用环境下的健壮性和对各种可能的运算框架的普遍适用性。
先大概介绍几个概念，首先是Mesos架构中的几个概念：
Mesos-master（主控制）：协调全部的slave，并确定每个节点的可用资源，聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework发出资源邀约。
Mesos-slave（被控制）：向master汇报自己的空闲资源和任务的状态，负责管理本节点上的各个mesos-task，在Framework成功向Master申请资源后,收到消息的slave会启动相应Framework的exexutor
Framework：Hadoop，Spark等，通过MesosSchedulerDiver接入Mesos。Framework是实际干活的，可以理解为 mesos 上跑的应用，需要注册到master上。
Executor：执行器，用于启动计算框架中的task
大概了解图中的概念以后我们来看看上面那张图，这里讲到重点了，请尽量理解，Mesos实现了两级调度架构，它可以管理多种类型的应用程序。
第一级调度是Master的守护进程，管理Mesos集群中所有节点上运行的Slave守护进程（集群由物理服务器或虚拟服务器组成，用于运行应用程序的任务，比如Hadoop和MPI作业）。
第二级调度由被称作Framework的“组件”组成。Framework包括调度器（Scheduler）和执行器（Executor）进程，其中每个节点（slave）上都会运行执行器。Mesos能和不同类型的Framework通信，每种Framework由相应的应用集群管理。上图中只展示了Hadoop和MPI两种类型，其它类型的应用程序也有相应的Framework。Mesos master实际上是一个全局资源调度器，采用某种策略将某个slave上的空闲资源分配给某一个Framework，各种Framework通过自己的调度器向Mesos master注册，以接入到Mesos中。而Mesos slave主要功能是汇报任务的状态和启动各个Framework的executor。下面更通俗的说一下。
Mesos是如何实现分布式任务调度的？Mesos是整个分布式计算系统的核心，分布式计算总线（简称DSF吧）接入Mesos采用双层调度策略。首先由mesos将资源分配给分布式总线，然后DSF调度器将资源分配给自己内部的任务。DSF通过注册的方式接入mesos，以便DCOS进行统一管理和资源分配。DSF提交作业时，会指定每个任务需要的CPU个数和内存量，当任务运行时，mesos-agent会将任务放到包含固定资源的Docker（容器）中运行，以达到资源隔离的效果。Executor主要用于启动框架内部的task。
1、Mesos Master
Mesos Master协调全部的Slave，并确定每个节点的可用资源，
聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework（作为Master的客户端）发出资源邀约。Framework可以根据应用程序的需求，选择接受或拒绝来自master的资源邀约。一旦接受邀约，Master即协调Framework和Slave，调度参与节点上任务，并在容器中执行，以使多种类型的任务，比如Hadoop和Cassandra，可以在同一个节点上同时运行。
2、部署架构—提高资源利用率
Mesos最大的好处是能够对分布式集群做细粒度资源分配。如上图所示，左边是粗粒度的资源分配，右边是细粒度的资源分配。细粒度的资源分配是指直接按照任务实际需求分配资源，这种分配机制可大大提高资源利用率。
左边有三个集群，每个集群三台服务器，分别装三种分布式计算平台，比如上面装三台Hadoop，中间三台是Spark，下面三台是Storm，三个不同的框架分别进行管理。右边是Mesos集群统一管理9台服务器，所有来自Spark、Hadoop或Storm的任务都在9台服务器上混合运行。Mesos提高了资源冗余率。粗粒度资源管理肯定带来一定的浪费，细粒度的管理提高了资源管理能力。
3、Slave与Docker的关系
YARN是下一代MapReduce，即MRv2，是在第一代MapReduce基础上演变而来的，主要是为了解决原始Hadoop扩展性较差，不支持多计算框架而提出的。它完全不同于Hadoop MapReduce，所有代码全部重写而成。整个平台由Resource Manager（master，功能是资源分配）和Node Manager组成（slave，功能是节点管理）。较于HadoopMapReduce，其最大特点是将JobTracker拆分成Resource Manager和Application Master，其中Resource Manager是全局的资源管理器，仅负责资源分配（由于Resource Manager功能简单，所以不会严重制约系统的扩展性），而Application Master对应一个具体的application（如Hadoop job， Spark Job等），主要负责application的资源申请，启动各个任务和运行状态监控（没有调度功能）。
相信看到这里大家对Mesos有了大致的认识，是时候说说具体流程了。我们来研究下上图的事件流程，前文提到，Slave是运行在物理或虚拟服务器上的Mesos守护进程，是Mesos集群的一部分。Framework由调度器（Scheduler）应用程序和任务执行器（Executor）组成，被注册到Mesos以使用Mesos集群中的资源。资源调度的具体流程（模拟）如下：
第一步：Slave 1向Master汇报其空闲资源：4个CPU、4GB内存。然后，Master触发分配策略模块，得到的反馈是Framework 1要请求全部可用资源。
第二步：Master向Framework 1发送资源邀约，描述了Slave 1上的可用资源。
第三步：Framework的调度器（Scheduler）响应Master，需要在Slave上运行两个任务，第一个任务分配<2 CPUs, 1 GB RAM>资源，第二个任务分配<1 CPUs, 2 GB RAM>资源。
最后一步：Master向Slave下发任务，分配适当的资源给Framework的任务执行器（Executor）,接下来由执行器启动这两个任务（如图中虚线框所示），在容器中执行。 此时，还有1个CPU和1GB的RAM尚未分配，因此分配模块可以将这些资源供给Framework 2。
为了实现在同一组Slave节点集合上运行多任务这一目标，Mesos使用了隔离模块， 该模块使用了一些应用和进程隔离机制来运行这些任务。Mesos当前模块支持的是容器隔离。为运行特定应用程序的任务，都需要将执行器全部打包，并在已经为该任务分配资源的Slave服务器上启动。当任务执行完毕后，容器会被“销毁”，资源会被释放，以便可以执行其他任务。
我们来更深入地研究一下资源邀约和分配策略，因为这对Mesos管理跨多个Framework和应用的资源，是不可或缺的。我们前面提到资源邀约的概念，即由Master向注册其上的Framework发送资源邀约。每次资源邀约包含一份Slave节点上可用的CPU、RAM等资源的列表。Master提供这些资源给它的Framework，是基于分配策略的。分配策略对所有的Framework普遍适用，同时适用于特定的Framework。如果分配的资源不满足要求，Framework可以拒绝资源邀约，因此资源邀约随即可以发给其他Framework。由Mesos管理的应用程序通常运行短周期的任务，因此这样可以快速释放资源，缓解Framework的资源饥饿； Slave定期向Master报告其可用资源，以便Master能够不断产生新的资源邀约。
如何作出资源邀约的决定是由资源分配模块实现的，该模块存在于Master之中。资源分配模块确定Framework接受资源邀约的顺序，与此同时，确保在本性贪婪的Framework之间公平地共享资源。在同质环境中，比如Hadoop集群，使用最多的公平份额分配算法之一是最大最小公平算法（max-min fairness）。最大最小公平算法算法将最小的资源分配最大化，并将其提供给用户，确保每个用户都能获得公平的资源份额，以满足其需求所需的资源。同质环境下的资源需求几乎没有波动，所涉及的资源类型包括CPU、内存、网络带宽和I/O（I/O表示入口与出口）。然而，在跨数据中心调度资源并且是异构的资源需求时，资源分配将会更加困难。例如，当用户A的每个任务需要1核CPU、4GB内存，而用户B的每个任务需要3核CPU、1GB内存时，如何提供合适的公平份额分配策略？当用户A的任务是内存密集型，而用户B的任务是CPU密集型时，如何公平地为其分配一揽子资源？因为Mesos是专门管理异构环境中的资源，所以它实现了一个可插拔的资源分配模块架构，将特定部署最适合的分配策略和算法交给用户去实现。
使用Mesos的主要好处是可以在同一组计算节点集合上运行多种类型的应用程序（调度以及通过Framework初始化任务）。这些任务使用隔离模块（容器技术）从实际节点中抽象出来，以便它们可以根据需要在不同的节点上移动和重新启动。
那么Mesos是如何处理持久化存储的呢？如果我在运行一个数据库作业，Mesos如何确保当任务被调度时，分配的节点可以访问其所需的数据？如图所示，在Hindman的示例中，使用Hadoop文件系统（HDFS）作为Mesos的持久层，这是HDFS常见的使用方式，也是Mesos的执行器传递分配指定任务的配置数据给Slave经常使用的方式。实际上，Mesos的持久化存储可以使用多种类型的文件系统，HDFS只是其中之一，但也是Mesos最经常使用的，它使得Mesos具备了与高性能计算的亲缘关系。其实Mesos可以有多种选择来处理持久化存储的问题。例如分布式文件系统，Mesos可以使用DFS（比如HDFS或者Lustre）来保证数据可以被Mesos集群中的每个节点访问。这种方式的缺点是会有网络延迟，对于某些应用程序来说，这样的网络文件系统或许并不适合。
Mesos本身只提供资源的分配， 并不涉及存储， 任务调度等功能， 所以它要和其它软件或者系统搭配使用才能构成完整的分布式系统。Mesos，Docker，Marathon/Chronos，RabbitMQ，HDFS/Ceph构成了一个完整的分布式系统，
由于纵向拓展可优化空间太小（单台服务器的性能上限很明显），分布式系统强调横向扩展、横向优化，当分布式集群计算资源不足时，就要往集群里面添加服务器，来不停地提升分布式集群的计算能力。分布式系统要做到统一管理集群的所有服务器，屏蔽底层管理细节，诸如容错、调度、通信等，让开发人员觉得分布式集群在逻辑上是一台服务器。
Docker：一个开源的应用容器引擎， 它涉及基础技术有Linux cgroup和namespace, 以及AUFS。 Docker可以理解为更轻量级的虚拟机。
Marathon: 针对服务型分布式应用提供任务调度，比如企业网站等这类需要长时间运行的服务。
Chronos: 针对分布式批处理应用提供任务调度，比如定期处理日志或者定期调Hadoop等离线任务。
RabbitMQ: 一种消息队列， 企业级的消息系统。
HDFS: 即Hadoop分布式文件系统， 提供高吞吐量的数据访问， 适合大数据集的分布式应用。
Ceph: 一种分布式文件系统， 开源存储解决方案， 提供对象存储。
和单机Linux操作系统相比，虽然分布式系统还没有成熟到成为“分布式操作系统”，但它和单机Linux一样要解决五大类操作系统必需的功能，即资源分配、进程管理、任务调度、进程间通信（IPC）和文件系统，可分别由Mesos、Docker、Marathon/Chronos、RabbitMQ和HDFS/Ceph来解决，对应于Linux下的Linux Kernel、Linux Kernel、init.d/cron、Pipe/Socket和ext4，如图所示。
除了上述讲到的分布式系统最基本的五大组件外， 分布式系统还涉及到其它的组件， 如负载均衡器， 服务发现器， 系统性能监控器， 系统告警监控器， 对应的软件分别有HAproxy， Zookeeper， Ganglia， Zabbix等。
HAproxy：是一个轻量级的TCP/HTTP的代理, 提供负载均衡功能，支持数以万计的并发。
Ganglia：是UC Berkeley发起的一个开源集群监视项目，设计用于测量数以千计的节点。Ganglia的核心包含gmond、gmetad以及一个Web前端。主要是用来监控系统性能，如：cpu 、mem、硬盘利用率， I/O负载、网络流量情况等
Zabbix：是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案
在技术的角度上说一下资源分配，一般来说Mesos集群部署在公有云服务上，用100多台虚拟机组成Mesos集群。Mesos不要求计算节点是物理服务器还是虚拟服务器，只要是Linux操作系统就可以。Mesos可以理解成一个分布式的Kernel（操作系统内核），只分配集群计算资源，不负责任务调度。基于Mesos之上可以运行不同的分布式计算平台，如Spark、Storm、Hadoop、Marathon和Chronos等。
Spark、Storm和Hadoop这样的计算平台有任务调度功能，可以直接使用MesosSDK跟Mesos请求资源，然后自行调度计算任务，并对硬件容错。Marathon针对服务型分布式应用提供任务调度，比如企业网站等这类需要长时间运行的服务，通常网站应用程序没有任务调度和容错能力，因为网站程序不太会处理某个后台实例挂掉以后要在哪台机器上重新恢复等这类复杂问题，这类没有任务调度能力的服务型分布式应用，可以由Marathon来负责调度。比如，Marathon调度执行了网站服务的一百个后台实例，如果某个实例挂掉了，Marathon会在其他服务器上把这个实例恢复起来。Chronos是针对分布式批处理应用提供任务调度，比如定期处理日志或者定期调Hadoop等离线任务。
Mesos只做一件事情，就是分布式集群资源分配，不管任务调度。Marathon和Chonos是基于Mesos来做任务调度。如下图所示，Mesos集群混合运行来自Marathon和Chronos的不同类型的任务。
Marathon和Chonos基于Mesos做任务调度时，一定是动态调度，也就是每个任务在执行之前是不知道它将来在哪一台服务器上执行和绑定哪一个端口。如下图所示，9台服务器组成的Mesos集群上混合运行各种Marathon调度的任务，中间一台服务器坏掉以后，这台服务器上的两个任务就受影响，然后Marathon把这两个任务迁移到其他服务器上，这就是动态任务调度带来的好处，非常容易实现容错。
为了减少硬件故障对应用服务的影响，应用程序要尽量做到无状态。无状态的好处是在程序受到影响时不需要进行任何恢复，这样这个程序只要重新调度起来就可以。无状态要求把状态数据放到存储服务器或者是消息队列里面，这样的好处是容错时恢复起来会变得很方便。
在分布式环境下应用服务之间通信，是用分布式消息队列来做，用的是RabbitMQ。RabbitMQ也是一个分布式系统，它也要保证高可靠性、解决容错的问题。首先RabbitMQ也有集群，如图所示，六个节点组成了一个RabbitMQ的集群，每个节点之间是互为备份的关系，任何一个坏掉，其他五个还可以提供服务，通过冗余来保证RabbitMQ的高可靠性。
讲一下分布式文件系统HDFS和Ceph。Hadoop文件系统HDFS，如图所示，每个数据块有三个备份，必须放在不同的服务器上，而且三个备份里面每个机架最多放两份，这么做也是为了容错。Ceph是另一种流行的开源分布式文件系统。Ceph把网络存储设备抽象成一张逻辑硬盘，然后“挂载”到分布式集群的每台服务器上，原理上非常像是Linux操作系统Mount一块物理硬盘。这样一来，用户程序访问Ceph的文件系统就跟访问Linux本地路径一样，非常方便。
本篇文章对Mesos做了基本介绍，掌握这么多就可以跟我一起来看看DCOS了。
以上是关于分布式架构的根基-Mesos的主要内容，如果未能解决你的问题，请参考以下文章