Ambari和ClouderManager分析對比

第一章      導論

運維過hadoop集羣的人都應該清楚，hadoop生態從安裝、配置到後期運維是一個很是艱辛的過程，通常來講安裝hadoop可能就須要幾天時間，運維一個小型集羣一樣須要幾我的。ambari和cloudera Manager這兩個系統，目的就是簡化hadoop生態集羣的安裝、配置，同時提升hadoop運維效率，以及對hadoop集羣進行監控。

1.1.   ClouderManager/ambari簡述

1.1.1.    Ambari

Ambari是Hortonworks公司開源的Hadoop平臺的管理軟件，着重於幫助你們管理本身的HDP集羣，具有Hadoop組件的安裝、管理、運維等基本功能，提供Web UI進行可視化的集羣管理，簡化了大數據平臺的安裝、使用難度。

1.1.2.    ClouderManager

Cloudera Manager是cloudera公司的一個產品，着重於幫助你們管理本身的CDH集羣，Cloudera Manager是一個擁有集羣自動化安裝、中心化管理、集羣監控、報警功能的一個工具（軟件）,使得安裝集羣從幾天的時間縮短在幾個小時內，運維人員從數十人下降到幾人之內，極大的提升集羣管理的效率。

1.2.   手動部署hadoop集羣和工具（ClouderManager/ambari）部署的比較：

1.2.1.    手動部署：

（1）  組件選擇：採用apache hadoop組件(原生hadoop組件)

（2）  優勢：

a)   各個組件徹底開源免費。

b)   社區資源活躍。

c)   能夠加深對各個組件的理解和掌握。

（3）  缺點：

a)   集羣部署：集羣部署、安裝、配置耗時比較多，一般按照集羣須要編寫大量的配置文件，分發到每一臺節點上，容易出錯，效率低下。

b)   版本管理：組件的版本管理比較複雜，在Hadoop生態圈中，組件的選擇、使用，好比Hive，Mahout，Sqoop，Flume，Spark，impala,Oozie等等，須要大量考慮兼容性的問題，版本是否兼容，組件是否有衝突，編譯是否能經過等。常常會浪費大量的時間去編譯組件，解決版本衝突問題。

c)   集羣運維：對集羣的監控，運維，須要安裝第三方的其餘軟件，如ganglia，nagois等，運維難度較大，同時運維成本比較高。

1.2.2.    工具部署

（1）  組件選擇：Ambari + HDP 或 Cloudera Manger + CDH

（2）  優勢：

a)   基於穩定版本Apache Hadoop，解決了組件不一樣版本之間的衝突問題，並應用了最新Bug修復或Feature的patch，在兼容性、安全性、穩定性上有加強。

b)   默認優化了不少參數，如HDFS的snappy壓縮。

c)   提供了部署、安裝、配置工具，大大提升了集羣部署的效率，能夠在數個小時內部署好集羣。

d)   第三方發行版一般都通過了大量的測試驗證，有衆多部署實例，大量的運行到各類生產環境。

e)   運維簡單。提供了管理、監控、診斷、配置修改的工具，管理配置方便，定位問題快速、準確，使運維工做簡單，有效。

（3）  缺點

a)   免費社區版功能不全，非社區版服務收費。

b)   收費標準：按節點收費，Cloudera每一個節點一年4000美圓，Hortonworks 每一個節點一年1250美圓。

第二章       Ambari 概述

2.1   Ambari簡介

Ambari是Hortonworks開源的Hadoop平臺的管理軟件，具有Hadoop組件的安裝、管理、運維等基本功能，提供Web UI進行可視化的集羣管理，簡化了大數據平臺的安裝、使用難度。

Ambari目前對接安裝Hortonworks Data Platform（HDP），即Hortonworks的開源Hadoop，對Apach的Hadoop平臺的生產環境部署沒有找到實例；對於已經安裝了Apach Hadoop或者其餘Hadoop平臺的，可能不能使用Ambari來管理；

2.2   ambari功能列表

2.2.1操做級別：

（1）Host Level Action（機器級別的操做）

（2）Component Level Action（模塊級別的操做）

2.2.2基於角色的用戶管理，5種角色：

（1）Cluster User

查看集羣和Service的信息，如配置、service狀態、健康狀態等。Read-only

（2）Service Operator

可以操做Service的生命週期，如啓動，中止，也能夠進行一些如Rebalance DataNode和YARN refresh的操做

（4）  Service Administrator

在Service Operator的基礎上增長了配置service，移動NameNode，啓用HA等操做

（5）  Cluster Operator

在Service Administrator的基礎上增長了對hosts和components的操做，如增長，刪除等

（6）  Cluster Administrator

集羣的超級管理員，擁有無上的權利，能夠操做任何組件。

2.2.3 Dashboard 監控

（1）Roll Start功能。根據Service的依賴關係，按照必定的順序啓動每一個Service。好比HBase依賴HDFS和Zookeeper，Ambari會先啓動HDFS和Zookeeper，以後啓動HBase。

（2）關鍵的運維指標（metrics）–metrics 是「度量,指標」的意思

（3）在左側的 Service 列表,中間部分是 Service 的模塊（Component）信息，也就是該 Service 有哪些模塊及其數目。右上角有個 Service Action 的按鈕，包括service的啓動、中止、刪除等操做。

（4）Quick links（導向組件原生管理界面） 

• NameNode UI、ResourceManage UI、HBase Master UI
• http://unix191:50070/logs/ HDFS的NameNode的logs
• http://unix192:8088/logs/ YARN的ResourceManage 的logs
• http://unix191:16010/logs/ Hbase的logs

2.3        Alert介紹

（1）Alert 告警級別： 
OK 、Warning、Critical、Unknown、None

（2）Alert 告警類型： 
WEB、Port、Metric、Aggregate 和 Script

表 1. Ambari 中的 Alert 類型對比

類型	用途	告警級別	閥值是否可配置	單位
PORT	用來監測機器上的一個端口是否可用	OK, WARN, CRIT	是	秒
METRIC	用來監測 Metric 相關的配置屬性	OK, WARN, CRIT	是	變量
AGGREGATE	用於收集其餘某些 Alert 的狀態	OK, WARN, CRIT	是	百分比
WEB	用於監測一個 WEB UI（URL）地址是否可用	OK, WARN, CRIT	否	無
SCRIPT	Alert 的監測邏輯由一個自定義的 python 腳本執行	OK, CRIT	否	無

2.4   Hadoop表明組件功能說明

2.4.1 HDFS

• 啓動、中止、重啓HDFS，也支持HDFS的刪除，前提是刪除依賴HDFS的其餘service
• 高級配置 
  支持對core-site.xml、hdfs-site.xml的高級配置
• 下載配置文件
• 狀態查看 
  NameNode和SNameNode的健康情況以及所在的節點、硬盤使用率、塊的狀態（丟失、衝突的個數）
• 文件查看 
  嵌入了HDFS原生的文件目錄查看功能，沒有一鍵上傳、下載文件的功能
• 日誌查看 
  日誌查看能夠經過QuickLinks中導向HDFS原生日誌查看Web UI界面，沒有通過界面的優化，日誌查看也沒有輔助功能（如檢索）
• 移動NameNode、SNameNode
• Rebalancing HDFS 
  使得DataNodes上的塊分佈均勻
• NameNode UI 
  經過QuickLinks導向HDFS原生UI
• HA 
  一鍵配置NameNode的高可用，使用JournalNode、NFS爲共享存儲
• 啓動、中止、重啓Zookeeper集羣
• 狀態查看 
  Zookeeper Server和Client的健康情況，所在的節點
• 高級配置 
  zoo.cfg、日誌輸出格式(log4j的配置)
• 添加Zookeeper Server節點
• 下載配置文件
• 啓動HBase集羣，啓動RegionServer，中止集羣，刪除HBase集羣
• 添加HBase Master節點
• 狀態查看 
  HBase Master、RegionServers的狀態及其所處節點，master啓動時間，平均負載（regions/regionsServer）
• 高級配置 
  HBase Master、RegionServer、Client的內存限制、心跳時間等。能夠啓用Kerberos（前提是安裝該Service），也能夠開啓Phoenix SQL
• 日誌查看 
  日誌查看能夠經過QuickLinks中導向原生日誌查看Web UI界面
• Master UI界面 
  經過QuickLinks導向HDFS原生UI
• Kafka的啓動、中止、重啓，Brokers的重啓，Service的刪除
• 高級配置 
  對Kafka Broker、Producer、Consumer的配置。Broker支持鏈接參數設置、Topic配置、日誌配置等，
• 狀態查看 
  Broker的狀態、所在節點位置，結合Ambari Metrics能夠查看更多狀態，如Topics、Controller、Replica

2.4.2 Zookeeper

2.4.3 HBase

2.4.5 Kafka

2.5       Ambari總結

Ambari經過HDP將Hadoop的組件進行集成，經過棧的形式提供Service的組合使用，它主要解決的問題以下：

• 簡化了部署過程，在HDP棧中支持的Service只須要圖形化的安裝便可，能夠方便的指定master所在的節點，使集羣快速運行起來
• 經過Ambari Metrics實現集羣狀態的監控，並經過集成Grafana進行數據的展現（CPU、內存、負載等）
• Service的高級配置。集羣部署以後，能夠方便的經過dashboard進行參數的修改（如HDFS的core-site等）
• 快速連接。Ambari提供快速導向Hadoop組件原生管理界面的連接
• 節點的擴展。如HBase Master的增長。
• 可定製的Alert功能。Ambari的報警信息能夠自定義，使得用戶能夠根據本身的須要，設置哪些狀況下須要報警，哪些不須要。
• 增值功能。如HDFS的Rebalance DataNode、NameNode的HA等
• Ambari自身的用戶管理，基於RBAC賦予用戶對Hadoop集羣的管理權限。

Ambari並無對Hadoop組件進行過多的功能集成，如日誌分析等，只是提供了安裝，配置，啓停等功能，儘可能保持了跟原生Hadoop組件的隔離性，對於該組件的具體操做，經過Quick Links 直接導向原生的管理界面（如HBase Master UI），它的作法保持了對於Hadoop組件的低侵入性。

第三章 ClouderManager概述

3.1 clouderManager簡介

Cloudera Manager是cloudera公司的一個產品，着重於幫助你們管理本身的CDH集羣，經過Cloudera Manager統一的UI界面來快速地自動配置和部署CDH和其相關組件，同時Cloudera Manager還提供了各類豐富的可自定義化的監視診斷和報告功能，集羣上統一的日誌管理功能，統一的集羣配置管理和實時配置變動功能，多租戶功能，高可用容災部署功能和自動恢復功能等， 方便企業統一管理和維護本身的數據中心。它細分爲免費的Express版本和功能徹底並提供衆多增值服務的收費版本Enterprise。

3.2 cloudera manager功能簡述：

管理：對大數據集羣進行管理，如添加、刪除節點等操做。

監控：監控集羣的健康狀況，對設置的各類指標和系統運行狀況進行全面監控。

診斷：對集羣出現的問題進行診斷，對出現的問題給出建議解決方案。

集成：對hadoop的多組件進行整合。

3.3 Cloudera Manager核心組成部分

cloudera manager的核心是管理服務器，該服務器承載管理控制檯的Web服務器和應用程序邏輯，並負責安裝軟件，配置，啓動和中止服務，以及管理上的服務運行羣集。

Agent：安裝在每臺主機上。該代理負責啓動和中止的過程，拆包配置，觸發裝置和監控主機。
Management Service：由一組執行各類監控，警報和報告功能角色的服務。
Database：存儲配置和監視信息。一般狀況下，多個邏輯數據庫在一個或多個數據庫服務器上運行。例如，Cloudera的管理服務器和監控角色使用不一樣的邏輯數據庫。
Cloudera Repository：軟件由Cloudera 管理分佈存儲庫。
Clients：是用於與服務器進行交互的接口：

Admin Console ：基於Web的用戶界面與管理員管理集羣和Cloudera管理。
API ：與開發人員建立自定義的Cloudera Manager應用程序的API。

 

第四章 hadoop生態圈原生的webUI

4.1 原生webUI簡介

Apache hadoop 原生組件的webUI界面能夠查看組件的運行狀態，歷史日誌，內存消耗，硬盤消耗狀況等。

相比clouderManager和ambari：

（1）原生的webUI不能執行服務的啓停操做

（2）各個組件之間的webUI界面是相互獨立的

（3）大部分功能僅限於read-only的操做，沒法執行其它操做

（4）很難統一監控整個集羣的運行狀況

第五章 Ambari和ClouderManager的比較

 

組件	Ambari	ClouderaManager
開發公司	Hortonworks公司	Cloudera公司
部署方式	Ambari + HDP	Cloudera Manger + CDH
生產運行狀況	比較穩定	很穩定
使用狀況	市場佔用率較高	市場佔用率高
開源狀況	產品開源，服務好像收費	有免費版和商業版
維護	依靠社區力量	cloudera作了一些定製開發，自行維護或打patch會離社區愈來愈遠
配置版本控制和歷史記錄	支持	不支持
二次開發	支持	不支持
集成	支持	no (不支持redis、kylin、es)
權限控制	ranger(相對簡單)	sentry(複雜)
視圖定製	支持建立本身的視圖，添加自定義服務	不支持

 

第六章 版本選擇分析

當咱們決定是否採用某個軟件用於開源環境時，一般須要考慮如下幾個因素：

（1）是否爲開源軟件，便是否免費。

（2） 是否有穩定版，這個通常軟件官方網站會給出說明。

（3） 是否通過實踐驗證，這個可經過檢查是否有一些大點的公司已經在生產環境中使用知道。

（4） 是否有強大的社區支持，當後期出現一個問題時，可以經過社區、論壇等網絡資源快速獲取解決方法。

第七章 Ambari補充資料

Ambari是hadoop分佈式集羣配置管理工具，是由hortonworks主導的開源項目。它已經成爲apache基金會的頂級項目，已經成爲hadoop運維繫統中的得力助手，引發了業界和學術界的關注。

Ambari採用的不是一個新的思想和架構，也不是完成了軟件的新的革命，而是充分利用了一些已有的優秀開源軟件，巧妙地把它們結合起來，使其在分佈式環境中作到了集羣式服務管理能力、監控能力、展現能力。這些優秀開源軟件有：

• 在agent端，採用了puppet管理節點;
• 在Web端，採用了ember.js做爲前端的MVC構架和NodeJS相關工具，用handlebars.js做爲頁面渲染引擎，在CSS/HTML方面還用了Bootstrap 框架;
• 在Server端，採用了Jetty, Spring，Jetty，JAX-RS等;
• 同時利用了Ganglia，Nagios的分佈式監控能力。

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