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的分佈式監控能力。

1、Puppet

在Agent節點上，它全部的狀態更改操做，都是經過Puppet來完成。Agent相關軟件包的安裝部署是由python完成，Agent端的包升級操做由Python和Puppet組合完成。例如，若是在頁面上進行啓動HDFS服務，那麼最終在某個Ambari-Agent端會執行相似以下命令：

/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的執行邏輯。

#04.09.2013 15:52:26
import '/var/lib/ambari-agent/puppet/modules/hdp/manifests/*.pp'

# 省略一堆import...
# 省略一堆xxx-site.xml裏面的參數配置項...

$hadoop_pid_dir_prefix = '/var/run/hadoop'
$zookeeper_sessiontimeout = '60000'
$dfs_include = 'dfs.include'
＃執行節點 默認
node /default/ {
# 共分兩步
 stage{1 :} -> stage{2 :}
＃第一步是 準備啓動階段，進行一系列的檢查 和配置更新
class {'hdp': stage => 1}
# 第二步是 執行namenode的啓動工做。
class {'hdp-hadoop::namenode': stage => 2, service_state => running}
}

 2、Ember.JS

自從Node.JS出來以後， JavaScript就變得更加神奇了。在前端能夠控制頁面展現，在後臺能夠看成服務器。尤爲在前端的迅猛發展，不斷散發出其無窮無盡的魅力，難怪有人說不懂點JS就不是純正的攻城師。

Ember.JS是在瀏覽器前端構建的JS MVC框架，簡單易用。它須要你建立一個Ember.Application實例，這個實例裏有許多動態對象，MVC的功能就是經過這些動態對象之間相互交互來完成。

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

具體如何使用，請下載本文附件。

3、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

 

4、Ambari-Server中的僞「插件」機制

Ambari-Server提供了多種類型的操做和服務，不一樣的操做對應不一樣的BaseProvider實現類和Definition實現類。若是要添加新的操做，就要依次實現對應Provider和Definition。這些操做類會統一加載進來。詳情能夠查看相關類的代碼，例如：org.apache.ambari.server.controller.internal.AbstractControllerResourceProvider和org.apache.ambari.server.api.resources.ResourceInstanceFactoryImpl。這種實現機制在Ambari-Server這一層有點相似把服務看成插件來完成，可是也沒有徹底作到插件那麼靈活，只須要實現某些類，配置某些參數就能夠實現一個服務或操做。

 

5、改進思考

熟悉完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集羣。對於系統工程師來講，添加一點麻煩是可以接受的。