Ambari——大資料平臺的搭建利器之進階篇[配置spark]
Ambari 的現狀
目前 Apache Ambari 的最高版本是 2.0.1，最高的 Stack 版本是 HDP 2.2。未來不久將會發布 Ambari 2.1 以及 HDP 2.3（本文也將以 Ambari 2.0.1 和 HDP 2.2 為例進行講解）。其實在 Ambari trunk 的 code 中，我們已經可以看到 HDP 2.3 相關的程式碼。
圖 1. Ambari Trunk 的 code
HDP 2.2 所支援的 Service 已經有 18 個之多，分別是 Falcon，Flume，Hbase，HDFS，Hive，Kafka，Kerberos，Knox，Oozie，Pig，Ranger，Slider，Spark，Sqoop，Stom，Tez，Yarn，Zookeeper。HDP 2.3 將會支援更多的 Service，例如 Accumulo。
利用 Ambari 擴充套件叢集
利用 Ambari 搭建好的叢集，可以通過 Ambari 來擴充套件。這裡的步驟其實類似於 Add Service，只是少了選擇 Master 的頁面。下面是詳細的描述。
第一步，需要開啟 Hosts 頁面，然後點選左上角的 Actions，在下拉列表中選擇“Add New Hosts”。
圖 2. Add Host 按鈕
第二步，在 Add Host Wizard 需要輸入新增的機器名（包含完整域名）以及 Ambari Service 機器上生成的私鑰。
圖 3. 選擇 Agent 機器頁面
第三步，需要部署已安裝 Service 的 Slave 模組和 Client 模組。
圖 4. 選擇 Slave、Client 頁面
第四步，選擇對應的 Service 的配置。這裡 Ambari 為使用者已經選擇了預設的配置。選擇完後，便會開始安裝 Ambari Agent 到新的機器，並且安裝選擇的模組。
當 Add Host Wizard 完成時，我們就可以從 Hosts 的頁面中看到新的機器，以及安裝的模組（Component）。
圖 5. 成功新增 Host 後頁面
Ambari 的自定義命令（Custom Command）
在 Ambari 的 Stack 中，每個 Service 都會有 start、stop、status、configure 這樣的命令，我們稱之為生命週期的控制命令（lifecycle command）。Service 的每個模組（Component）都必須實現這幾個命令的邏輯。為了讓使用者可以更好地控制每個 Service 以及每個模組，Ambari 支援了自定義命令（Custom Command）。不過目前只能支援到模組級別（Component Level），Service Level 的還不支援。
具體的自定義命令配置在每個 Service 的 metainfo.xml 中。不過不同的模組型別，呈現在 GUI 的方式是有差異的。當給一個 Service 的 Master 模組增加一個自定義命令時，該命令會顯示在該 Service 的 Service Action List。如果點選這個命令，Ambari Server 就會通知 Master 所在機器的 Agent，Agent 就會執行該自定義命令的邏輯。當增加一個自定義命令給 Slave 或 Client 型別的 Component（模組），該命令則會呈現在機器的 Component 頁面。在哪個機器的 Component 頁面點選該命令，Ambari Server 就會通知該機器 Agent 呼叫這個自定義的命令介面。
Master Component 的自定義命令
這裡我以 YARN 為例，給 Resource Manger 模組（Master）增加一個自定義命令。首先假設一個需求，例如，要在 YARN 的 Service Action 裡面加一個命令來檢查 Resource Manger 所在機器的記憶體空間還有多大。
第一步，需要找到 Yarn 的 metainfo.xml，並在 Resource Manager 的 Component 配置中增加一個自定義命令。Component 段的示例程式碼如下（metainfo.xml），其中 GetMem 這個命令就是我們新增的自定義命令。
<component> <name>RESOURCEMANAGER</name> <displayName>ResourceManager</displayName> <category>MASTER</category> <cardinality>1</cardinality> <versionAdvertised>true</versionAdvertised> <commandScript> <script>scripts/resourcemanager.py</script> <scriptType>PYTHON</scriptType> <timeout>1200</timeout> </commandScript> <customCommands> <customCommand> <name>DECOMMISSION</name> <commandScript> <script>scripts/resourcemanager.py</script> <scriptType>PYTHON</scriptType> <timeout>600</timeout> </commandScript> </customCommand> <customCommand> <name>REFRESHQUEUES</name> <commandScript> <script>scripts/resourcemanager.py</script> <scriptType>PYTHON</scriptType> <timeout>600</timeout> </commandScript> </customCommand> <!--新增部分 --> <customCommand> <name>GetMem</name> <commandScript> <script>scripts/resourcemanager.py</script> <scriptType>PYTHON</scriptType> <timeout>600</timeout> </commandScript> </customCommand> </customCommands> <configuration-dependencies> <config-type>capacity-scheduler</config-type> </configuration-dependencies> </component>
第二步，實現自定義命令的邏輯。這裡 CustomComand 的 xml 段已經指定了具體的指令碼（resourcemanager.py），所以需要在這個指令碼中增加該命令的介面，而且函式名必須是小寫且與配置的中的 name 保持一致。接下來，我們需要先找到 Ambari Server 上的 resourcemanager.py 檔案。找到之後，在 resourcemanager.py 增加如下的示例程式碼（python 指令碼中注意程式碼的對齊方式，否則會出現語法錯誤。可以參考 resourcemanager.py 中的 decommission 函式）：
def getmem(self, env):
import os
print 'Execute this coustom command to get mem info on this host'
os.system("free")
第三步，重啟 Ambari Server 以及 Resource Manger 所在機器的 Ambari Agent。這一步為了載入新的配置，並且同步我們修改的指令碼到 Agent 機器。因為在每個 Agent 的機器上，都有一個 cache 目錄，用來存放從 Server 端下載的配置及指令碼。當重啟 Agent 時候，Agent 便會嘗試從 Server 端下載最新的配置和指令碼。重啟命令如下：
ambari-server restart ambari-agent restart
第四步，登入 Ambari 的 WEB GUI，並檢查 Yarn 的 Service Actions。這時候我們已經可以看到這個 GetMem 的命令了。由於 CustomComand 的 xml 段不支援 DisplayName 標籤，所以我們沒法通過配置更改這個名字。如果需求要更改這個名字，則不得不更改 GUI 的 JS 程式碼。
圖 6. 自定義命令 GetMem 頁面
第五步，如果 GetMem 可以顯示，就可以點選並執行該命令了。執行結果如下圖顯示。
圖 7. 自定義命令 GetMem 執行進度頁面
Slave/Client Component 的自定義命令
本質上講，為 Slave、Client 型別的 Component 增加自定義命令，與 Master 型別是沒有什麼區別的。唯一的區別就是在 GUI 上呈現的位置不一樣。因此這裡給一個簡單的示例，不再贅述具體的步驟。
這裡我為 Yarn 的 NodeManager 增加了一個自定義命令“iostat”，用來檢視 NodeManager 所在機器的 IO 狀況。在 Yarn 的 metainfo.xml 中，為 NodeManager 新增如下的配置。
<component> <name>NODEMANAGER</name> <displayName>NodeManager</displayName> <category>SLAVE</category> <cardinality>1+</cardinality> <versionAdvertised>true</versionAdvertised> <commandScript> <script>scripts/nodemanager.py</script> <scriptType>PYTHON</scriptType> <timeout>1200</timeout> </commandScript> <!--新增部分 --> <customCommands> <customCommand> <name>iostat</name> <commandScript> <script>scripts/nodemanager.py</script> <scriptType>PYTHON</scriptType> <timeout>600</timeout> </commandScript> </customCommand> </customCommands> </component>
在 nodemanager.py 中增加如下的示例程式碼
nodemanager.py 中新增程式碼段
def iostat(self, env):
import os
os.system("iostat")
配置完成後，重啟 Ambari Server 以及 NodeManager 所在的 Agent 的機器。當重新登入 Ambari GUI 的時候，就可以在 NodeManger 所在機器的 Component 頁面看到這個命令。如下圖：
圖 8. Component 頁面
到這裡，我們就成功的為 YARN 的 Master 和 Slave 模組分別增加了一個自定義命令。現實的生產環境中，可以通過自定義命令擴充套件 Ambari 現在的控制功能，可以讓 Ambari 更好的與 Hadoop 等軟體切合。如果需要更深入應用自定義命令，以及增強 GUI 上面的顯示功能，則可能需要向社群貢獻 patch。這樣可以更好的提升使用者體驗等。
Ambari 中 Service 之間的依賴關係
在 Hadoop 的生態圈中，一個完整的解決方案往往是需要幾個 framework 共同的協作才能完成的。所以 Ambari 必須支援定義 Service 之間、Component 之間的依賴關係，以及 Component 狀態和 Action 之間的依賴關係。
對於 Service 和 Component 之間的依賴關係，可以在 metainfo.xml 中定義。例如開啟 YARN 的 metainfo.xml，就可以看到在 YARN 的 Service 段，有一個 requiredService 的欄位。每個 Service 段底下，可以用這個欄位來定義一個 Service 依賴哪些其他的 Service。YARN 所示配置如下，代表 YARN 需要 HDFS。
<requiredServices> <service>HDFS</service> </requiredServices>
對於 Component 來說，也有一個欄位 dependencies。在這個欄位定義了 Component 的依賴關係。我以 HBASE 的 HBASE_MASTER 配置為例。可以從示例程式碼中看到，HBASE_MASTER 需要 HDFS 的 HDFS_CLIENT，以及 ZOOKEEPER 的 ZOOKEEPER_SERVER。
<component> <name>HBASE_MASTER</name> <displayName>HBase Master</displayName> <category>MASTER</category> <cardinality>1+</cardinality> <versionAdvertised>true</versionAdvertised> <dependencies> <dependency> <name>HDFS/HDFS_CLIENT</name> <scope>host</scope> <auto-deploy> <enabled>true</enabled> </auto-deploy> </dependency> <dependency> <name>ZOOKEEPER/ZOOKEEPER_SERVER</name> <scope>cluster</scope> <auto-deploy> <enabled>true</enabled> <co-locate>HBASE/HBASE_MASTER</co-locate> </auto-deploy> </dependency> </dependencies> </component>
對於 Service 和 Component 的依賴，還是比較容易發現和理解的。但是對於 Component 狀態以及 Action 之間的依賴關係，就比較難理解了。Ambari 的 Service 目錄中，存在很多個叫做 role_command_order.json 的檔案。在這個檔案中定義了狀態之間以及 Action 的依賴。在 resource 目錄下的 role_command_order.json 定義著全域性的的依賴。每個 Stack 目錄下也會存在 role_command_order.json。相同的配置，Stack 下面的會覆蓋全域性的（overwrite）。對於不同的配置，Ambari 會拼接在一起（merge）。高版本的 Stack 會繼承低版本的配置。相同的也會 overwrite，不同的也會 merge。
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. 確認批量操作頁面
圖 10. 關閉 DataNode 進度頁面
Host Level（機器級別）
對 Host 級別的維護模式來說，就是打開了該機器所有模組的維護模式。操作起來也很簡單，在 Hosts 頁面中勾選完機器，然後在 Host Actions 裡面選擇“Turn On Maintenance Mode”即可。如果該機器已經有告警資訊，當 Maintenance Mode 開啟後，告警資訊會被遮蔽，並且抑制新告警資訊的產生。所有的批量操作都會越過該機器。
圖 11. Host 開啟 Maintenance Mode 之前
圖 12. Host 開啟 Maintenance Mode 之後
Service Level（服務級別）
對 Service 級別的維護模式來說，就是開啟一個 Service 所有 Component 的維護模式。由於 Service 可能部署在多臺機器，也就相當於使用者在多個機器開啟 Service Component 的維護模式。這樣一來，這個 Service 就不會產生任何新的告警。當用戶重啟叢集所有 Service 的時候，該 Service 會越過這個批量操作。當用戶重啟一個機器的所有 Component 的時候，該 Service 的 Component 也會被越過。下圖是對 HDFS 開啟維護模式的示例。
圖 13. Service 開啟 Maintenance Mode 之前
圖 14. Service 開啟 Maintenance Mode 之後
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 機器，執行如下的命令。
yum list | grep spark
如果看不到 Spark 的 rpm 包，就代表無法正常的通過 Ambari 建立 Spark 叢集。使用者可以到 HortonWorks 的 repository 伺服器上下載最新 HDP 2.2 的更新 repo 檔案。我的下載的 repo 內容如下：
#VERSION_NUMBER=2.2.4.4-16
[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 版本
瞭解了以上的背景知識，就可以開始在 Ambari 上增加 Spark 這個 Service 了（這裡只簡單說明，具體的 Add Service 步驟，可以閱讀《Ambari——大資料平臺的搭建利器》）。
如果之前瞭解過 Spark，就會發現 Ambari 部署的 Spark 叢集的模式是 Spark on YARN。這也是為什麼在 Add Spark 的時候，Ambari 會提示要選擇依賴的 YARN。下圖是 Ambari、YARN 與 Spark 的層級結構。
圖 16. Ambari&YARN&park 結構示意圖
搭建好 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 狀態）。具體的命令如下：
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 返回的結果
用 Rest API 停掉 Service 的命令格式如下，有興趣的朋友可以嘗試一下。
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：
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 包
如果需要徹底清除掉 Storm 的 package，則需要到各個 Agent 機器執行如下命令。
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 機器的許可權）。
#!/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 的命令，所以有一定的格式可循。
格式大致如下：
NAME_SERVICE_CHCECK
只要將 NAME 替換成對應的 Service，就是該 Service 的 Check 命令。以 YARN 為例，執行如下的命令。
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 執行進度
在這裡我們可以發現，這個 Operation 的名字其實就是 context 欄位的值。我們在 WEB GUI 上面直接點選 Service Check 的時候，Operation 的名字其實是 JS code 中指定了一個特殊 context。
這裡我們也可以指定執行自定義命令（Custom Comand）。以給 Resource Manager 新增的 GetMem 為例。執行如下的命令。
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 的執行進度
跟 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 中考慮這個問題。
結束語
Ambari 作為一個 Hadoop 生態圈的管理工具，起步比 Hadoop 等軟體晚一些。應用中免不了也會碰到一些奇怪的問題，所以未來 Ambari 的發展也離不開社群的貢獻，更離不開每一位 Committer。希望 Ambari 能在 Hadoop 的管理中脫穎而出，成為一個完美的管理平臺。