Ambari源码分析(一):Ambari架构

ambari-cwiki

ambari-github
https://github.com/apache/ambari

Ambari系统架构

除了ambari-server和ambari-agent,ambari还提供一个界面清亮的管理监控页面ambari-web,这些页面由ambari-server提供。ambari-server开放了REST API,这些API也主要分两大类,其中一类为ambari-web提供管理监控服务,另一类用于与ambari-agent交互,接受ambari-agent向ambari-server发送的心跳请求。下图是Ambari的系统架构。其中master模块接受API和Agent Interface的请求,完成ambari-server的集中式管理监控逻辑,而每个agent节点只负责所在节点的状态采集及维护。



Ambari-Agent内部架构

ambari-agent是一个无状态的。其功能主要分两部分:

  1. 采集所在节点的信息并且汇总发心跳汇报给ambari-server;
  2. 处理ambari-server的执行请求。

因此它有两种队列:

  1. 消息队列MessageQueue,或为ResultQueue。包括节点状态信息(包括注册信息)和执行结果信息,并且汇总后通过心跳发送给ambari-server;
  2. 操作队列ActionQueue。用于接收ambari-server返回过来的状态操作,然后能过执行器按序调用puppet或python脚本等模块完成任务。

Ambari-Server内部架构

链接:http://www.toxingwang.com/hadoop/2356.html


  1. ambari-server是一个有状态的,它维护着自己的一个有限状态机FSM。同时这些状态机存储在数据库中,前期数据库主要采用postgres。如下图所示,server端主要维护三类状态:
  2. Live Cluster State:集群现有状态,各个节点汇报上来的状态信息会更改该状态;
  3. Desired State:用户希望该节点所处状态,是用户在页面进行了一系列的操作,需要更改某些服务的状态,这些状态还没有在节点上产生作用;
  4. Action State:操作状态,是状态改变时的请求状态,也可以看作是一种中间状态,这种状态可以辅助Live Cluster State向Desired State状态转变。

     Ambari-server的Heartbeat Handler模块用于接收各个agent的心跳请求(心跳请求里面主要包含两类信息:节点状态信息和返回的操作结果),把节点状态信息传递给FSM状态机去维护着该节点的状态,并且把返回的操作结果信息返回给Action Manager去做进一步的处理。

    Coordinator模块又可以称为API handler,主要在接收WEB端操作请求后,会检查它是否符合要求,stage planner分解成一组操作,最后提供给Action Manager去完成执行操作。

    因此,从上图就可以看出,Ambari-Server的所有状态信息的维护和变更都会记录在数据库中,用户做一些更改服务的操作都会在数据库上做一些相应的记录,同时,agent通过心跳来获得数据库的变更历史




阅读更多
个人分类: Ambari
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

不良信息举报

Ambari源码分析(一):Ambari架构

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭