Mesos+Zookeeper+Marathon+Docker分布式集群管理最佳实践

目录


  • Mesos简介

  • Zookeeper简介

  • Marathon简介

  • docker集群实践

  • Mesos集群部署


一、Mesos简介


Mesos是Apache下的开源分布式资源管理框架,它被称为分布式系统的内核。Mesos最初是由加州大学伯克利分校的AMPLab开发,后在Twitter得到广泛使用。


  • Mesos-Master:主要负责管理各个framework和slave,并将slave上的资源分配给各个framework。

  • Mesos-Slave:负责管理本节点上的各个mesos-task,比如:为各个executor分配资源。

  • Framework:计算框架,如:Hadoop、Spark、Kafaka、ElasticSerach等,通过MesosSchedulerDiver接入Mesos

  • Executor:执行器,就是安装到每个机器节点的软件,这里就是利用docker的容器来担任执行器的角色。具有启动销毁快,隔离性高,环境一致等特点。


Mesos-Master是整个系统的核心,负责管理接入Mesos的各个framework(由frameworks_manager管理)和slave(由slaves_manager管理),并将slave上的资源按照某种策略分配给framework(由独立插拔模块Allocator管理)。


Mesos-Slave负责接受并执行来自Mesos-master的命令、管理节点上的mesos-task,并为各个task分配资源。Mesos-slave将自己的资源量发送给mesos-master,由mesos-master中的Allocator模块决定将资源分配给哪个framework,当前考虑的资源有CPU和内存两种,也就是说,Mesos-slave会将CPU个数的内存量发送给mesos-master,而用户提交作业时,需要指定每个任务需要的CPU个数和内存。这样当任务运行时,mesos-slave会将任务放导包含固定资源Linux container中运行,以达到资源隔离的效果。很明显,master存在单点故障问题,为此Mesos采用了Zookeeper解决该问题。


Framework是指外部的计算框架,如果Hadoop、Mesos等,这些计算框架可通过注册的方式接入Mesos,以便Mesos进行统一管理和资源分配。Mesos要求可接入的框架必须有一个调度模块,该调度器负责框架内部的任务调度。当一个framework想要接入Mesos时,需要修改自己的调度器,以便向Mesos注册,并获取Mesos分配给自己的资源,这样再由自己的调度器将这些资源分配给框架中的任务,也就是说,整个Mesos系统采用了双层调度框架:第一层,由Mesos将资源分配给框架。第二层,框架自己的调度器将资源分配给自己内部的任务。


当前Mesos支持三中语言编写的调度器,分别是C++、Java、Python。为了向各种调度器提供统一的接入方式,Mesos内部采用C++实现了一个MesosSchedulerDriver(调度驱动器),framework的调度器可调用该driver中的接口与Mesos-master交互,完成一系列功能(如注册,资源分配等。)


Executor主要用于启动框架内部的task。由于不同的框架,启动task的接口或者方式不同,当一个新的框架要接入mesos时,需要编写一个Executor,告诉Mesos如何启动该框架中的task。为了向各种框架提供统一的执行器编写方式,Mesos内部采用C++实现了一个MesosExecutorDiver(执行器驱动器),framework可通过该驱动器的相关接口告诉Mesos启动task的方式。


整体架构如图1.1-1所示:


图1.1-1总体架构


图1.1-1展示了Mesos的重要组成部分,Mesos由一个master进程管理运行着每个客户端节点的slave进程和跑任务的Mesos计算框架。


Mesos进程通过计算框架可以很细致的管理cpu和内存等,从而提供资源。每个资源提供都包含了一个清单(slave ID,resource1:amount1,resource2,amount2,…)master会根据现有的资源决定提供每个计算框架多少资源。例如公平分享或者根据优先级分享。


为了支持不同种的政策,master通过插件机制新增额一个allocation模块使之分配资源更简单方便。


一个计算框架运行在两个组建之上,一个是Scheduler,他是master提供资源的注册中心,另一个是Executor程序,用来发起在slave节点上运行计算框架的任务。master决定给每个计算框架提供多少计算资源,计算框架的调度去选择使用哪种资源。当一个计算框架接受了提供的资源,他会通过Mesos的任务描述运行程序。Mesos也会在相应的slave上发起任务。


资源提供案例,如图1.1-2所示:


图1.1-2资源提供案例


下面我带大家一起熟悉图1.1-2的流程步骤:


  1. slave1报告给master他拥有4核cpu和4G剩余内存,Marathon调用allocation政策模块,告诉slave1计算框架1应该被提供可用的资源。

  2. master给计算框架1发送一个在slave上可用的资源描述。

  3. 计算框架的调度器回复给master运行在slave上两个任务相关信息,任务1需要使用2个CPU,内存1G,任务2需使用1个CPU,2G内存。

  4. 最后,master发送任务给slave,分配适当的给计算框架执行器,继续发起两个任务(图1.1-2虚线处),因为任有1个CPU和1G内存未分配,allocation模块现在或许提供剩下的资源给计算框架2。


除此之外,当任务完成,新的资源成为空闲时,这个资源提供程序将会重复。


二、Zookeeper简介


Zookeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chuby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个分布式应用提供一致性服务的软件,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。


1.2.1Zookeeper角色


  • Leader(领导者):负责投票发起和决议,更新系统状态。

  • follower(跟随者):Follower用于接收客户请求并向客户端返回结果,在选主过程中参与投票。

  • ObServer(观察者):ObServer可以接受客户端连接,将写请求转发给Leader节点,但ObServer不参加投票过程,只同步Leader的状态,ObServer的目的是为了拓展系统,提高读取速度。

  • Client(客户端):请求发起方。


1.2.2Zookeeper工作原理


Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数Server完成了和Leader的状态同步以后,回复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。


为了保证事物的顺序一致性,Zookeeper采用了递增的事物ID号(zxid)来标识事物。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字,它高32位是epoch用来标识Leader关系是否改变,每次一个Leader被选出来,它都会有每一个Server在工作过程中三种状态。


  • q   LOOKING:当前Server不知道Leader是谁,正在搜寻。

  • q   LEADING:当前Server即为选举出来的Leader。

  • q   FOLLOWING:Leader已经选举出来,当前Server与之同步。


1.2.3Zookeeper选举流程


当Leader崩溃或者Leader失去大多数的Follower,这时候zk进入恢复模式,恢复模式需要重新选举出一个新的Leader,让所有的Server都恢复到一个正确的状态。


ZK的选举算法有两种:

  1. 基于Basic paxos实现

  2. 基于fast paxos算法实现


系统默认的选举算法为fast paxos。


1.2.4Zookeeper同步流程


选完Leader以后,zk就进入状态同步过程。

  • Leader等待server连接。

  • Follower连接Leader,将最大的zxid发送给Leader。

  • Leader根据Follower的zxid确定同步点。

  • 完成同步后通知Follower已经成为uptodate状态。

  • Follower收到uptodate消息后,又可以重新接受client的请求进行服务。


1.2.5Zookeeper工作流程


Leader三大功能:

  • 恢复数据

  • 维持与learner的心跳,接收learner请求并判断learner的请求消息类型

  • learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息,根据不同的消息类型,进行不同的处理。


PING消息是指Learner的心跳信息;REQUEST消息是Follower发送的提议信息,包括写请求及同步请求;ACK消息是Follower的对提议的回复,超过半数的Follower通过,则commit该提议;REVALIDATE消息是用来延长SESSION有效时间。


Follower主要四大功能:

  • 向Leader发送请求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息)。

  • 接收Leader消息并进行处理。

  • 接收Client的请求,如果为写请求,发送给Leader进行投票。

  • 返回Client结果。


Follower的消息循环处理如下几种来自Leader的消息:

  • PING消息:心跳消息。

  • PROPOSAL消息:Leader发起的提案,要求Follower投票。

  • COMMIT消息:服务器端最新一次提案的信息。

  • UPTODATE消息:表明同步完成。

  • REVALIDATE消息:根据Leader的REVALIDATE结果,关闭待revalidate的session还是允许其接受消息。

  • SYN消息:返回SYNC结果到客户端,这个消息最初由客户端发起,用来强制得到最新的更新。

三、Marathon简介


Marathon是一个Mesos框架,能够支持运行长服务,比如Web应用等。它是集群的分布式init.d能够原样运行任何Linux二进制发布版本,如Tomcat、Play等等。它也是一种私有的PaSS,实现服务的发现,为部署提供REST API服务,有授权和SSL、配置约束,通过HaProxy实现服务发现和负载平衡。


四、docker集群实践


1.4.1集群环境准备




1.4.2Zookeeper伪集群安装部署


部署Zookeeper需要java支持, 主流1.7,稳定最新1.8,开发最新1.9,这边选择yum安装即可支持Zookeeper



1.4.2.1Zookeeper配置文件详解



1.4.2.2Zookeeper配置文件修改


由于是伪集群的配置方式,B(IP地址)都是一样,所以不同的Zookeeper实例通信端口号不能一样,所以要给它分配不同的端口号。



1、创建三个目录来存放Zookeeper的数据



2、生成三份Zookeeper配置文件



3、修改zk2、zk3对应的数据存放目录以及端口



1.4.2.3Zookeeper角色查看


1、启动Zookeeper并查看角色


 


2、连接Zookeeper



五、Mesos集群部署


安装Mesosphere仓库,需要在Mesos Master和Mesos Slave节点安装。


1.5.1Mesos_Master部署



1.5.2Mesos_Slave部署



1.5.3Mesos_Web界面


访问:http://192.168.56.11:5050,如图1.5-1所示:


图1.5-1Tasks表格没有任何条目


运行Mesos任务,可以在Web界面查看task如图1.5-2所示:



图1.5-2运行Mesos任务


1.5.4Marathon调用Mesos运行Docker容器



通过marathon默认监听8080端口,通过marathon创建项目,如图1.5-3所示:


图1.5-3Marathon界面


下面通过Mesos调度,使用marathon来创建一个nginx镜像的Docker容器,Marathon启动时会读取/etc/mesos/zk配置文件,Marathon通过Zookeeper来找到Mesos Master。


Marathon有自己的REST API,我们通过API的方式来创建一个Nginx的Docker容器。首先创建如下的配置文件nginx.json



使用curl的方式调用



访问Docker随机启动的端口31011,如图1.5-4所示:


图1.5-4成功访问Nginx界面


在MarathonWeb界面查看,如图1.5-5所示:


图1.5-5MarathonWeb界面查看Nginx已经在运行


在Mesos界面查看,如图1.5-6所示:


图1.5-5Mesos界面查看Nginx Tasks


也可以点击Marathon左上角的创建进行创建容器。


注意:这里哪Nginx来举例,注册中心的marathon+mesos+docker集群是不适合用于服务的,也就是说不适合于对外开放端口的。比如说爬虫,因为不开放端口,需要做的仅仅是从队列中取资源,然后处理,存库。


这个仅仅是job的发布管理运行,还有没CI,也就是说持续集成,后期我会发布jenkins+docker+mesos+marathon+git持续集成的方案,如果将代码发布结合DCO框架。

1.Docker入门    1.1 Docker为什么火    1.2 Docker是什么    1.3 为什么要使用Docker    1.4 Docker与虚拟化区别    1.5 Docker Engine    1.6 Docker 体系结构    1.7 Docker 应用场景2.Docker安装    2.1 安装Docker2.1.1 调整镜像源从国内获取2.1.2 调整docker数据存储位置    2.2 如何快速运行一个容器3.Docker镜像    3.1 什么是镜像?    3.2 镜像能干什么?    3.3 如何使用镜像运行容器    3.4 镜像的基本操作。搜索、下载、查看、导入、导出、删除、上传4.Docker容器    4.1 什么是容器    4.2 容器能运行什么    4.3 启动第一个容器    4.4 容器运行的参数含义    4.5 如何运行一个自启动的容器    4.6 容器暴露    4.7 容器的整个生命周期5.Docker数据管理    5.1 数据持久化介绍    5.2 数据持久化-Data Volume (db)    5.3 数据持久化-Bind Mounting  ( web )6.Docker镜像构建    6.1 如何将运行的容器打包成镜像    6.2 如何实现自动化构建镜像    6.3 Dockerfile介绍    6.4 Dockerfile语法    6.5 dockerfile构建-案例1    6.5 dockerfile构建-案例2    6.7 dockerfile构建-案例3    6.8 dockerfile构建-案例4 (搞清楚ENTRYPOINT与CMD之间的关系与区别)7.Docker私有仓库    7.1 什么是私有仓库    7.2 为什么要有私有仓库    7.3 私有仓库种类    7.2 搭建私有仓库registry     7.3 为registry添加basic认证    7.3 如何将本地镜像存放私有仓库    7.4 如何获取私有仓库的docker镜像    7.5 企业级私有仓库harbor https    7.6 实战a主机推送镜像至仓库,b主机拉取镜像启动为容器8.Docker网络    8.1 docker容器互联是什么?--link    8.2 docker容器互联项目实践( python )    8.3 docker网络模式 ( bridge、host、container、none )9.Docker单机编排    9.1 Compose基本介绍    9.2 Compose三大概念   project(services、volumes、networks)    9.3 Compose编排博客系统    9.4 Compose编排Python-web    9.5 Compose实现水平扩展    9.6 Compose实现负载均衡    9.7 Compose编排投票系统 (python、node、java、db、redis)10.Docker图形化与监控    10.1 docker图形工具 Portainer    10.2 docker监控工具 cAdvisor
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值