Ambari深刻学习（I）－系统架构

Ambari是hadoop分布式集群配置管理工具，是由hortonworks主导的开源项目。它已经成为apache基金会的孵化器项目，已经成为hadoop运维系统中的得力助手，引发了业界和学术界的关注。如今咱们将深刻学习Ambari原理及其架构。

Ambari架构采用的是Server/Client的模式，主要由两部分组成：ambari-agent和ambari-server。ambari依赖其它已经成熟的工具，例如其ambari-server 就依赖python，而ambari-agent还同时依赖ruby, puppet，facter等工具，还有它也依赖一些监控工具nagios和ganglia用于监控集群情况。其中：

1. puppet是分布式集群配置管理工具，也是典型的Server/Client模式，可以集中式管理分布式集群的安装配置部署，主要语言是ruby。
2. facter是用python写的一个节点资源采集库，用于采集节点的系统信息，例如OS信息，主机信息等。因为ambari-agent主要是用python写的，所以用facter能够很好地采集到节点信息。

1、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节点只负责所在节点的状态采集及维护。

 

 

2、Ambari-Agent内部架构

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

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

所以它有两种队列：

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

 

3、Ambari-Server内部架构

ambari-server是一个有状态的，它维护着本身的一个有限状态机FSM。同时这些状态机存储在数据库中，前期数据库主要采用postgres。以下图所示，server端主要维护三类状态：

1. Live Cluster State：集群现有状态，各个节点汇报上来的状态信息会更改该状态; 
2. Desired State：用户但愿该节点所处状态，是用户在页面进行了一系列的操做，须要更改某些服务的状态，这些状态尚未在节点上产生做用;
3. 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的代码结构及其主要流程。