Ambari是hadoop分散式叢集配置管理工具，是由hortonworks主導的開源專案。它已經成為apache基金會的孵化器專案，已經成為hadoop運維繫統中的得力助手，引起了業界和學術界的關注。現在我們將深入學習Ambari原理及其架構。

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節點只負責所在節點的狀態採集及維護。  

 

二、Ambari-Agent內部架構

ambari-agent是一個無狀態的。其功能主要分兩部分：

1.  採集所在節點的資訊並且彙總發心跳彙報給ambari-server;
2.  處理ambari-server的執行請求。

因此它有兩種佇列：

1. 訊息佇列MessageQueue，或為ResultQueue。包括節點狀態資訊（包括註冊資訊）和執行結果資訊，並且彙總後通過心跳傳送給ambari-server;
2. 操作佇列ActionQueue。用於接收ambari-server返回過來的狀態操作，然後能過執行器按序呼叫puppet或python指令碼等模組完成任務。

 

三、Ambari-Server內部架構

ambari-server是一個有狀態的，它維護著自己的一個有限狀態機FSM。同時這些狀態機儲存在資料庫中，前期資料庫主要採用postgres。如下圖所示，server端主要維護三類狀態：

1. Live Cluster State：叢集現有狀態，各個節點彙報上來的狀態資訊會更改該狀態; 
2. Desired State：使用者希望該節點所處狀態，是使用者在頁面進行了一系列的操作，需要更改某些服務的狀態，這些狀態還沒有在節點上產生作用;
3. Action State：操作狀態，是狀態改變時的請求狀態，也可以看作是一種中間狀態，這種狀態可以輔助Live Cluster State向Desired State狀態轉變。

  Ambari-server的Heartbeat Handler模組用於接收各個agent的心跳請求（心跳請求裡面主要包含兩類資訊：節點狀態資訊和返回的操作結果），把節點狀態資訊傳遞給FSM狀態機去維護著該節點的狀態，並且把返回的操作結果資訊返回給Action Manager去做進一步的處理。 Coordinator模組又可以稱為API handler，主要在接收WEB端操作請求後，會檢查它是否符合要求，stage planner分解成一組操作，最後提供給Action Manager去完成執行操作。  因此，從上圖就可以看出，Ambari-Server的所有狀態資訊的維護和變更都會記錄在資料庫中，使用者做一些更改服務的操作都會在資料庫上做一些相應的記錄，同時，agent通過心跳來獲得資料庫的變更歷史。