ambari 維護模式及reset API 操做

Ambari 的維護模式（Maintenance Mode）介紹

Ambari 提供的 Maintenance Mode，是爲了讓用戶在調試或者維護 Service 的時候，抑制沒必要要的告警（Alert）信息，以及避免批量操做的影響。對 Maintenance Mode 來講，有幾個不一樣級別的設置，分別是 Service Level，Host Level，以及 Component Level。三種級別之間存在着覆蓋關係。下面我會舉幾個例子來詳細說明 Maintenance Mode 的應用場景。另外注意，在 Ambari 的 WEB GUI 上面會用一個照相機的圖標，標記打開 Maintenance Mode 的模塊、機器或者 Service。

Component Level（模塊級別）

在 Component 頁面裏，若是用戶對某一個 Component（模塊）打開了維護模式，對該模塊會有兩種影響。其一，對於該機器的該模塊再也不受批量操做的控制；其二，抑制該機器該模塊告警信息的產生。

例如，對機器 zwshen86 的 DataNode 模塊打開維護模式，那麼當用戶從 Host Action 中關閉全部 DataNode 的時候，該機器的 DataNode 就不會被關閉。這是由於關閉 DataNode 的批量操做會直接越過 zwshen86。圖 10 中能夠看到 zwshen86 不在執行的序列。而且 zwshen86 的 DataNode 不會產生任何新的告警。

圖 9. 確認批量操做頁面
<ignore_js_op> 
圖 10. 關閉 DataNode 進度頁面
<ignore_js_op> 
Host Level（機器級別）

對 Host 級別的維護模式來講，就是打開了該機器全部模塊的維護模式。操做起來也很簡單，在 Hosts 頁面中勾選完機器，而後在 Host Actions 裏面選擇「Turn On Maintenance Mode」便可。若是該機器已經有告警信息，當 Maintenance Mode 打開後，告警信息會被屏蔽，而且抑制新告警信息的產生。全部的批量操做都會越過該機器。

圖 11. Host 打開 Maintenance Mode 以前
<ignore_js_op> 
圖 12. Host 打開 Maintenance Mode 以後
<ignore_js_op> 
Service Level（服務級別）

對 Service 級別的維護模式來講，就是打開一個 Service 全部 Component 的維護模式。因爲 Service 可能部署在多臺機器，也就至關於用戶在多個機器打開 Service Component 的維護模式。這樣一來，這個 Service 就不會產生任何新的告警。當用戶重啓集羣全部 Service 的時候，該 Service 會越過這個批量操做。當用戶重啓一個機器的全部 Component 的時候，該 Service 的 Component 也會被越過。下圖是對 HDFS 打開維護模式的示例。

圖 13. Service 打開 Maintenance Mode 以前
<ignore_js_op> 
圖 14. Service 打開 Maintenance Mode 以後
<ignore_js_op> 


Ambari 應用舉例（快速搭建 Spark on YARN 的集羣）

HDP2.2 的 Stack 已經支持了 Spark。可是 metainfo 中的版本仍是 1.2.1，這個版本已經很老了（Spark1.4.0 已經發布）。目前安裝的 Ambari 2.0.1 和 HDP 2.2 的 Stack，不少時候也沒法正常的安裝 Spark。緣由在於 HDP 的 repository 文件沒法找到 Spark 的安裝包。用戶能夠在搭建好的 Ambari 環境中，登陸到任一個 Agent 機器，執行以下的命令。

[Plain Text]  純文本查看 複製代碼

?

1	yum list | grep spark

若是看不到 Spark 的 rpm 包，就表明沒法正常的經過 Ambari 創建 Spark 集羣。用戶能夠到 HortonWorks 的 repository 服務器上下載最新 HDP 2.2 的更新 repo 文件。個人下載的 repo 內容以下：

# VERSION_NUMBER=2.2.4.4-16

[Plain Text]  純文本查看 複製代碼

?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18

[HDP-2.2.4.4] name=HDP Version - HDP-2.2.4.4 baseurl=http://public-repo-1.hortonworks.com/HDP/centos6/2.x/updates/2.2.4.4 gpgcheck=1 gpgkey=http://public-repo-1.hortonworks.com/HDP/centos6/2.x/updates/2.2.4.4/                                            RPM-GPG-KEY/RPM-GPG-KEY-Jenkins enabled=1 priority=1     [HDP-UTILS-1.1.0.20] name=HDP Utils Version - HDP-UTILS-1.1.0.20 baseurl=http://public-repo-1.hortonworks.com/HDP-UTILS-1.1.0.20/repos/centos6 gpgcheck=1 gpgkey=http://public-repo-1.hortonworks.com/HDP/centos6/2.x/updates/2.2.4.4/                                          RPM-GPG-KEY/RPM-GPG-KEY-Jenkins enabled=1 priority=1

將上面的內容拷貝到 Agent 機器的 HDP_up.repo 中，並放入文件夾/etc/yum.repos.d（不能複製到已有 HDP.repo 中，不然會被覆蓋掉），就能夠經過 yum list 看到 Spark 的 rpm 包了。在 Github 中，咱們能夠發現 HDP2.3 已經配置 Spark 的版本爲 1.3.1 了。

圖 15. HDP2.3 已經配置 Spark 的 1.3.1 版本
<ignore_js_op> 

瞭解了以上的背景知識，就能夠開始在 Ambari 上增長 Spark 這個 Service 了（這裏只簡單說明，具體的 Add Service 步驟，能夠閱讀《Ambari——大數據平臺的搭建利器》）。

若是以前瞭解過 Spark，就會發現 Ambari 部署的 Spark 集羣的模式是 Spark on YARN。這也是爲何在 Add Spark 的時候，Ambari 會提示要選擇依賴的 YARN。下圖是 Ambari、YARN 與 Spark 的層級結構。

圖 16. Ambari&YARN&park 結構示意圖
<ignore_js_op> 

搭建好 Spark 以後，咱們就能夠在 Ambari 的 Dashboard 看到 Spark 的 Service。

Ambari 經常使用的 REST API 介紹

Ambari 借鑑了不少成熟分佈式軟件的 API 設計。Rest API 就是一個很好地體現。經過 Ambari 的 Rest API，能夠在腳本中經過 curl 維護整個集羣。而且，咱們能夠用 Rest API 實現一些沒法在 Ambari GUI 上面作的操做。下面是一些實例。

實例 1，經過 API 卸載已安裝的 Service

目前 Ambari 不支持在 GUI 上面卸載已安裝的 Service。因此當一個 Service 再也不須要的時候，用戶無法刪除掉該 Service。幸運的是 Ambari 提供了 DELETE 的 Rest API，咱們能夠經過該 API 來刪除 Ambari 中 Service。不過這裏須要注意，這個方法只是從 Ambari Service 中刪除了 Service。這樣一來，Ambari 的 GUI 界面中再也不顯示這個 Service。可是 Service 自己還安裝在 Agent 所在的機器。若是用戶須要完全的清除掉這個 Service，仍須要手工的到每一個機器卸載（例如，在每一個機器執行 yum erase）。

這裏我以刪除 Storm 爲例。卸載以前，須要確認是否停掉了該 Service。咱們經過 GET 方法來獲得這個結果（這裏固然也能夠直接從 GUI 上面看到 Service 狀態）。具體的命令以下：

[Plain Text]  純文本查看 複製代碼

?

1 2	curl -u admin:admin -H "X-Requested-By: ambari" -X GET     http://zwshen86:8080/api/v1/clusters/bigdata/services/STORM

命令中的 zwshen86 爲 Ambari Server 的機器名（端口默認爲 8080），bigdata 爲 cluster 名字，STORM 爲 Service 的名字。

在返回的報文中，能夠看到 State 字段。若是是 INSTALLED，表明這個 Service 已是停掉的狀態。咱們能夠繼續刪除步驟。若是不是 INSTALLED，則須要先停掉這個 Service，能夠從 WEB 上操做，也能夠用 Rest API。

圖 17. Get 返回的結果
<ignore_js_op> 

用 Rest API 停掉 Service 的命令格式以下，有興趣的朋友能夠嘗試一下。

[Plain Text]  純文本查看 複製代碼

?

1 2 3

curl -u admin:admin -H "X-Requested-By: ambari" -X PUT -d '{"RequestInfo":          {"context":"Stop Service"},"Body":{"ServiceInfo":{"state":"INSTALLED"}}}'          http://AMBARI_SERVER_HOST:8080/api/v1/clusters/c1/services/SERVICE_NAME

執行以下命令刪除 STORM：

[Plain Text]  純文本查看 複製代碼

?

1 2	curl -u admin:admin -H "X-Requested-By: ambari" -X DELETE  http://zwshen86:8080/api/v1/clusters/bigdata/services/STORM

執行完成後，Storm 就從 Ambari 的 Service 裏面刪掉了，可是 Storm 的 package 還存在於機器。

圖 18. Storm 的 RPM 包
<ignore_js_op> 

若是須要完全清除掉 Storm 的 package，則須要到各個 Agent 機器執行以下命令。

[Plain Text]  純文本查看 複製代碼

?

1	yum erase「storm_2_2*」

執行完後，這個 Service 就被完全的清除掉了。

實例 2，獲取 Service 的 Component 和 Host 列表

上個實例中，讓用戶登陸到每一個機器去執行 yum 卸載安裝包，實際上是不太現實的。通常咱們會寫一個腳本先經過 curl 調用 GET 方法，先獲取到 Service 的 Component 列表，而後再調用 GET 方法，獲取 Component 的機器列表，接着調用 DELETE 從 Ambari 中刪除 Service。最後腳本經過 SSH 登陸到各個 Agent 機器上執行 yum 卸載安裝包。腳本示例代碼以下（該腳本只能在 Ambari Server 上執行，由於 Ambari Server 有無密碼登陸全部 Agent 機器的權限）。

[Plain Text]  純文本查看 複製代碼

?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

#!/bin/sh GetHostList() {   curl -u admin:admin -H "X-Requested-By: ambari" -X GET   http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE/components/$1   2>/dev/null |grep host_name|awk -F: '{print $2}'|sed 's/"//g' >> temp_host_list }   GetServiceComponent() {   curl -u admin:admin -H "X-Requested-By: ambari" -X GET   http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE   2>/dev/null | grep "component_name" > ./temp_component_list   sed -i 's/"//g' ./temp_component_list   sed -i 's/,//g' ./temp_component_list }     if [ $# != 4 ]; then   echo "Usage: $0 Ambari_Server Cluster_Name Service_Name Package_Name"   exit 1 fi   AMBARI_HOST=$1 CLUSTER=$2 SERVICE=$3 PACKAGE=$4   GetServiceComponent   cat ./temp_component_list|while read line do   COMPONENT=`echo $line|awk -F: '{print $2}'`   GetHostList $COMPONENT done   curl -u admin:admin -H "X-Requested-By: ambari" -X DELETE http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE   rm -f ./temp_component_list >/dev/null 2>&1 #delete duplicated lines (duplicated host name)   hosts=`cat temp_host_list|sort |uniq` for host in $hosts do   ssh $host "yum erase $PACKAGE" done   rm -f temp_host_list >/dev/null 2>&1

實例 3，經過 API 執行 Service 的命令

這裏，咱們以調用 API 執行 Service Check 爲例。首先須要知道命令的名字，這裏每一個 Service 的 Check 命令也是不一樣的。不過 Service Check 是 build-in 的命令，因此有必定的格式可循。

格式大體以下：

[Plain Text]  純文本查看 複製代碼

?

1	NAME_SERVICE_CHCECK

只要將 NAME 替換成對應的 Service，就是該 Service 的 Check 命令。以 YARN 爲例，執行以下的命令。

[Plain Text]  純文本查看 複製代碼

?

1 2 3 4

curl -u admin:admin -H "X-Requested-By: ambari" -X POST -d '     {"RequestInfo":{"context":"My YARN Service Check", "command":     "YARN_SERVICE_CHECK"},"Requests/resource_filters":[{"service_name":"YARN"}]}'     http://zwshen86:8080/api/v1/clusters/bigdata/requests

執行完後，能夠發如今 WEB GUI 上面，就多了一個正在進行的 Operation。以下圖：

圖 19. Service Check 執行進度
<ignore_js_op> 

在這裏咱們能夠發現，這個 Operation 的名字其實就是 context 字段的值。咱們在 WEB GUI 上面直接點擊 Service Check 的時候，Operation 的名字實際上是 JS code 中指定了一個特殊 context。

這裏咱們也能夠指定執行自定義命令（Custom Comand）。以給 Resource Manager 添加的 GetMem 爲例。執行以下的命令。

[Plain Text]  純文本查看 複製代碼

?

1 2 3 4 5

curl -u admin:admin -H "X-Requested-By: ambari" -X POST -d '     {"RequestInfo":{"context":"Get RM host Mem Usage","command":"GetMem"},"Requests/resource_filters":[{"service_name":     "YARN","component_name":"RESOURCEMANAGER","hosts":"zwshen86.eng.platformlab.ibm.com"}]}'     http://zwshen86:8080/api/v1/clusters/bigdata/requests

WEB GUI 的顯示以下

圖 20. 自定義命令 GetMem 的執行進度
<ignore_js_op> 

跟 Service Check 相比，不難看出其中的差別。對於自定義命令，咱們須要指定參數 Component 以及 Host。當這兩個參數缺失的時候，Ambari 是不會接受這個請求的。

經過這三個簡單實例，就能夠體會到 Ambari Rest API 的做用。在 Rest API 的基礎上，就算脫離了 WEB，咱們也能夠很好地控制 Ambari。固然，咱們也不得不記住不少生澀的參數。所以，大多狀況下，只有當 Ambari 的 GUI 不足以完成需求，或者不指望暴露在 GUI 上面的時候，就可使用 Rest API。有興趣的讀者能夠搜索下 Ambari Server 目錄全部的 Python 腳本，其實 Ambari 自身不少地方都在用 curl 調用 Rest API。

Ambari 的發展

咱們能夠到 Ambari 的 Roadmap 頁面查看 Ambari 最新 release 的進展，以及將來 Ambari 將會開發怎樣的功能。例如如今的 Ambari Server 是存在單點問題的，若是 Server 機器宕機了，就沒法恢復整個 Ambari Server 的數據，也就是說沒法再經過 Ambari 管理集羣。咱們能夠從 Ambari 的 Roadmap 中看到，Ambari 將來會在 2.2 的 release 中考慮這個問題。