Ambari深入学习（III）－开源使用及其改进思考

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

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

一、Puppet

在Agent节点上，它所有的状态更改操作，都是通过Puppet来完成。Agent相关软件包的安装部署是由python完成，Agent端的包升级操作由Python和Puppet组合完成。例如，如果在页面上进行启动HDFS服务，那么最终在某个Ambari-Agent端会执行类似如下命令：

1. /usr/lib/ambari-agent/lib/puppet-2.7.9/bin/puppet apply --confdir=/var/lib/ambari-agent/puppet --detailed-exitcodes /var/lib/ambari-agent/data/site-83.pp

其中site-83.pp 是manifestGenerator.generateManifest方法产生的puppet脚本文件，这个文件里主要完成一x些xxx-site.xml文件的配置工作，最后几行是完成puppet启动namenode的执行逻辑。

1. #04.09.2013 15:52:26
2. import '/var/lib/ambari-agent/puppet/modules/hdp/manifests/*.pp'
3. # 省略一堆import...
4. # 省略一堆xxx-site.xml里面的参数配置项...
5. $hadoop_pid_dir_prefix = '/var/run/hadoop'
6. $zookeeper_sessiontimeout = '60000'
7. $dfs_include = 'dfs.include'
8. ＃执行节点 默认
9. node /default/ {
10. # 共分两步
11. stage{1 :} -> stage{2 :}
12. ＃第一步是 准备启动阶段，进行一系列的检查 和配置更新
13. class {'hdp': stage => 1}
14. # 第二步是 执行namenode的启动工作。
15. class {'hdp-hadoop::namenode': stage => 2, service_state => running}
16. }

二、Ember.JS

自从Node.JS出来之后， JavaScript就变得更加神奇了。在前端可以控制页面展示，在后台可以当作服务器。尤其在前端的迅猛发展，不断散发出其无穷无尽的魅力，难怪有人说不懂点JS就不是纯正的攻城师。

Ember.JS是在浏览器前端构建的JS MVC框架，简单易用。它需要你创建一个Ember.Application实例，这个实例里有许多动态对象，MVC的功能就是通过这些动态对象之间相互交互来完成。

1. // Creates an application instance.
2. App = Ember.Application.create({
3. LOG_TRANSITIONS: true
4. });

具体如何使用，请下载本文附件。

三、Nagios & Ganglia的使用

如果要观看漂亮的监控图，它就需要依赖nagios和ganglia了，一旦安装成功，ambari-server就直接用http请求的方式向nagios和ganglia请求数据。

ganglia有直接的请求json数据的地址，格式如下：

http://localhost/ganglia//graph.php?g=load_report&json=true

nagios没有直接请求数据的功能，因此ambari实现了一段php代码用来读取服务的json数据，请求地址如下：

http://localhost/ambarinagios/nagios/nagios_alerts.php?q1=alerts&alert_type=all

四、Ambari-Server中的伪“插件”机制

Ambari-Server提供了多种类型的操作和服务，不同的操作对应不同的BaseProvider实现类和Definition实现类。如果要添加新的操作，就要依次实现对应Provider和Definition。这些操作类会统一加载进来。详情可以查看相关类的代码，例如：org.apache.ambari.server.controller.internal.AbstractControllerResourceProvider和org.apache.ambari.server.api.resources.ResourceInstanceFactoryImpl。这种实现机制在Ambari-Server这一层有点类似把服务当作插件来完成，但是也没有完全做到插件那么灵活，只需要实现某些类，配置某些参数就可以实现一个服务或操作。

五、改进思考

熟悉完Ambari的架构，运行逻辑和一些开源软件后，让我想到Hadoop的使用习惯选择，及其Hadoop 1.x 和Hadoop 2.x+的差别。

5.1. “Yarn”化？

Hadoop为了解决计算模型多样化的问题，能够在同一存储系统上实现多种计算模型，Hadoop 2.x+添加了Yarn框架。准确地说，Yarn框架是那些计算模型的共性部分（控制管理部分）抽象出来，产生出一个新的通用的计算管理控制器。在Hadoop 1.x 中只有MapReduce框架，现在常称之为MapReduce V1。Hadoop 2.x+把计算模型的计算部分和控制部分分离开来，把控制部分交给Yarn，把计算部分交给各个计算模型实现（MapReduce模型实现就成为了MapReduce V2）。同时可以在Yarn上实现其它计算模型，例如：实时计算模型Storm，图计算模型BSP。

想一想Ambari现在只能管理着Hadoop及其生态系统，如果需要其管理监控Storm集群，显然现在无法达到。对于不同服务，例如无论是hadoop服务还是storm服务，都有着其共性部分，把其共性部分单独抽取出来，形成一个组件，然后运维人员只需要实现其具体操作。这样一来Ambari又是一款真正伟大的产品。

5.2. 做到简单的手动安装升级？

有人会说，Ambari现在都强大到能做到自动部署升级，那么就很容易做到手动部署升级的？还有人说，既然都已经自动部署了，为什么还要手动部署呢？

5.3. 做到用自己已经装好的hadoop集群？

现在ambari只能从头开始，安装自己的hadoop版本。如果现在已经有了hadoop集群，那么ambari就很难支持了。如果把ambari的多种功能进行分解，形成一组互相衔接的模块，那就更容易自定义hadoop集群。对于系统工程师来说，添加一点麻烦是能够接受的。