Ambari学习笔记-Ambari架构【转载】 _状态

是分布式集群配置管理工具，是由主导的开源项目。它已经成为基金会的孵化器项目，已经成为运维系统中的得力助手，引起了业界和学术界的关注。
采用的不是一个新的思想和架构，也不是完成了软件的新的革命，而是充分利用了一些已有的优秀开源软件，巧妙地把它们结合起来，使其在分布式环境中做到了集群式服务管理能力、监控能力、展示能力。这些优秀开源软件有：
架构采用的是/的模式，主要由两部分组成：-agent和- 。依赖其它已经成熟的工具，例如其- 就依赖，而-agent还同时依赖ruby,，等工具，还有它也依赖一些监控工具和用于监控集群状况。其中：
是分布式集群配置管理工具，也是典型的/模式，能够集中式管理分布式集群的安装配置部署，主要语言是ruby 。是用写的一个节点资源采集库，用于采集节点的系统信息，例如OS信息，主机信息等。由于-agent主要是用写的，因此用可以很好地采集到节点信息。一、系统架构
除了-和-agent，还提供一个界面清亮的管理监控页面-web，这些页面由-提供。-开放了REST API，这些API也主要分两大类，其中一类为-web提供管理监控服务，另一类用于与-agent交互，接受-agent向-发送的心跳请求。下图是的系统架构。其中模块接受API和Agent 的请求，完成-的集中式管理监控逻辑，而每个agent节点只负责所在节点的状态采集及维护。

文章插图
【Ambari学习笔记-Ambari架构【转载】】二、-Agent内部架构
-agent是一个无状态的。其功能主要分两部分：
采集所在节点的信息并且汇总发心跳汇报给-;处理-的执行请求。
因此它有两种队列：
消息队列，或为。包括节点状态信息（包括注册信息）和执行结果信息，并且汇总后通过心跳发送给-;操作队列。用于接收-返回过来的状态操作，然后能过执行器按序调用或脚本等模块完成任务。

文章插图

文章插图
三、-内部架构
-是一个有状态的，它维护着自己的一个有限状态机FSM 。同时这些状态机存储在数据库中，前期数据库主要采用。如下图所示，端主要维护三类状态：
LiveState：集群现有状态，各个节点汇报上来的状态信息会更改该状态; State：用户希望该节点所处状态，是用户在页面进行了一系列的操作，需要更改某些服务的状态，这些状态还没有在节点上产生作用; State：操作状态，是状态改变时的请求状态，也可以看作是一种中间状态，这种状态可以辅助LiveState向 State状态转变。

文章插图
-的模块用于接收各个agent的心跳请求（心跳请求里面主要包含两类信息：节点状态信息和返回的操作结果），把节点状态信息传递给FSM状态机去维护着该节点的状态，并且把返回的操作结果信息返回给去做进一步的处理。
模块又可以称为API，主要在接收WEB端操作请求后，会检查它是否符合要求，stage 分解成一组操作，最后提供给去完成执行操作。
因此，从上图就可以看出，-的所有状态信息的维护和变更都会记录在数据库中，用户做一些更改服务的操作都会在数据库上做一些相应的记录，同时，agent通过心跳来获得数据库的变更历史。