现在的位置: 首页 > 大数据 > hadoop > 正文
玩转Ambari之一:系统架构
2014年06月05日 hadoop, 大数据 ⁄ 共 2405字 暂无评论 ⁄ 被围观 22,554 views+

说在前面:

这段时间为公司部署了测试环境的Hadoop,采用了apache最新社区版,在使用中也遇到了各种各样的问题,但还是跑起来了,其他同事已能再其上运行推荐算法等基础应用。但在管理和后继部署中,越来越多的问题不断出现,主要如下:

  • 各集群节点的配置同步:我采用rsync+sersync+inotify实现,但配置较复杂
  • 新应用的部署:比如为集群添加hbase应用,需要很细心复杂的配置才能完成,而且要是操作错误,还可能导致正常的集群崩溃
  • 新集群节点增加:同上
  • 集群架构调整:比如原来hdfs的namenode和ResourceManager等应用主节点都是放到一台服务器上的,当应用多后,需要调整独立,发现异常复杂
  • Hadoop集群监控:虽然我们采用Nagios监控hadoop集群各节点,但hadoop本身应用监控还比较差

后来发现Apache有个项目Ambari能很好的解决上述所有问题,但目前基本没有中文资料,于是将我应用ambari的一些过程记录下来:

Ambari是hadoop分布式集群配置管理工具,是由hortonworks主导的开源项目。它已经成为apache基金会的孵化器项目,已经成为hadoop运维系统中的得力助手,引起了业界和学术界的关注。

Ambari采用的不是一个新的思想和架构,也不是完成了软件的新的革命,而是充分利用了一些已有的优秀开源软件,巧妙地把它们结合起来,使其在分布式环境中做到了集群式服务管理能力、监控能力、展示能力。这些优秀开源软件有:

    • 在agent端,采用了puppet管理节点;
    • 在Web端,采用了ember.js作为前端的MVC构架和NodeJS相关工具,用handlebars.js作为页面渲染引擎,在CSS/HTML方面还用了Bootstrap 框架;
    • 在Server端,采用了Jetty, Spring,Jetty,JAX-RS等;
    • 同时利用了Ganglia,Nagios的分布式监控能力。

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可以很好地采集到节点信息。

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

52fa1fbc-e2ad-369b-9028-ecc6ce25502c

二、Ambari-Agent内部架构

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

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

因此它有两种队列:

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

09b223bb-e18c-3280-8f77-bd604518a2b5

三、Ambari-Server内部架构

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

  1. Live Cluster State:集群现有状态,各个节点汇报上来的状态信息会更改该状态;
  2. Desired State:用户希望该节点所处状态,是用户在页面进行了一系列的操作,需要更改某些服务的状态,这些状态还没有在节点上产生作用;
  3. Action State:操作状态,是状态改变时的请求状态,也可以看作是一种中间状态,这种状态可以辅助Live Cluster State向Desired State状态转变。

a1ceaae2-189e-3cce-bcf3-3be37139a3ca

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

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

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

给我留言

留言无头像?


×