ambari-cwiki

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指令碼等模組完成任務。
3. 
   

Ambari-Server內部架構

1. ambari-server是一個有狀態的，它維護著自己的一個有限狀態機FSM。同時這些狀態機儲存在資料庫中，前期資料庫主要採用postgres。如下圖所示，server端主要維護三類狀態：
   
2. Live Cluster State：叢集現有狀態，各個節點彙報上來的狀態資訊會更改該狀態;
3. Desired State：使用者希望該節點所處狀態，是使用者在頁面進行了一系列的操作，需要更改某些服務的狀態，這些狀態還沒有在節點上產生作用;
4. 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通過心跳來獲得資料庫的變更歷史