Ambari深刻學習（I）－系統架構

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能夠很好地採集到節點信息。

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

 

 

2、Ambari-Agent內部架構

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

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

所以它有兩種隊列：

1. 消息隊列MessageQueue，或爲ResultQueue。包括節點狀態信息（包括註冊信息）和執行結果信息，而且彙總後經過心跳發送給ambari-server;
2. 操做隊列ActionQueue。用於接收ambari-server返回過來的狀態操做，而後能過執行器按序調用puppet或python腳本等模塊完成任務。

 

3、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經過心跳來得到數據庫的變動歷史。

下一節中，咱們將深刻學習Ambari的代碼結構及其主要流程。