【譯】Cloudera Manager（CDH）入門系列之二 （架構）

掃碼關注微信公衆號號"Kooola大數據"，一塊兒聊聊大數據

架構（Architecture）

以下圖所示，Cloudera Manager 的核心是 Cloudera Manager Server（如下簡稱Server）。Server 託管管理控制檯 web 服務和應用程序邏輯，並負責軟件的安裝、配置、服務的啓動與關閉以及管理集羣。

Server 和其餘一些組件共同工做：

• Agent - 安裝在每臺主機上。Agent 負責進程的啓動和中止，解壓配置，觸發安裝以及監視主機。
• Management Service - 由一組角色組成的服務，這些角色執行各類監視，警報和報告功能。
• Database - 存儲配置以及監控信息。一般狀況下，多個邏輯數據庫運行在一個或多個數據庫服務器上。例如，Cloudera Manager Server 和 monitoring roles 使用不一樣的邏輯數據庫。
• Cloudera Repository - Cloudera Manager分發軟件的存儲庫。
• Clients - 與Server交互的接口
  • Admin Console - 管理員 web 界面版
  • API - 用於開發者建立 Cloudera Manager 程序

心跳（Heartbeating）

Heartbeats是Cloudera Manager中的主要通訊機制。默認狀況下，Agent 每15秒發送一次心跳給 Server。固然，這個心跳頻率能夠進行調整。

經過這個心跳機制，Agent 向 Server 彙報本身的活動。反過來，Server 會響應 Agent 的活動。Agent 和 Server 最終都會進行一些對賬。例如，若是你啓動一個服務， Agent 嘗試啓動相應的進程，若是這個進程啓動失敗，Server會標記這個失敗的啓動命令。

狀態管理（State Management）

Server 維護集羣的狀態。這個狀態能夠劃分爲兩類：model 和 runtime， 兩者都保存在 Server 的數據庫中。

Cloudera Manager 爲 CDH 建模以及管理服務：角色、配置以及內部依賴。模型告訴咱們應該在什麼地方運行什麼以及使用什麼樣的配置。例如，模型狀態捕獲了一個事實，即一個集羣包含17個主機，每一個主機應該運行一個DataNode。你可使用管理控制檯的配置頁或者 API 來操做模型，例如 "Add Service"。

Runtime 狀態這個概念能夠理解爲：進程在哪裏運行，什麼命令正在運行等。在管理控制檯頁面中選擇「啓動」時，服務器將收集相關服務和角色的全部配置，對其進行驗證，生成配置文件並將其存儲在數據庫中。

當你更新配置（例如更改 Hue Server 的 web 端口），你就更新了 Model 狀態。而後， 當 Hue 正在運行時改變端口，它仍然會使用老的端口。當這種狀況發生時，角色會被標記爲擁有一個「過期的配置」。爲了達到同步，你必須重啓角色（觸發配置文件從新生成以及進程重啓）。

配置管理（Configuration Management）

Cloudera Manager 定義了幾個配置級別：

• 服務級別（service level）: 針對整個服務實例的配置，例如 HDFS 服務默認的複製因子（dfs.replication）。

• 角色組級別（role group level）: 應用到角色成員的配置，例如 Datanode 的句柄數（dfs.datanode.handler.count）。針對不一樣的 Datanode，這個設置可能不一樣。例如，在性能更好的硬件上，這個值能夠設置更大一些。

• 角色實例級別（role instance level）: 這個級別的配置會覆蓋繼承自角色組的配置。這裏須要謹慎使用，由於會致使與角色組配置之間存在差別。在一些特殊狀況下可使用，好比零時打開 debug 日誌級別以發現並解決一些問題。

• 主機也有一些配置，好比配置監控、軟件管理以及資源管理等。

• Cloudera Manager自己具備與其自身管理操做相關的配置。

角色組（Role Groups）

你能夠給服務實例（例如 HDFS）進行配置，也能夠個角色實例（例如 host17上的 Datanode）進行配置。單個角色的配置從服務級別繼承，而且若是角色上進行了配置，它將覆蓋這個繼承。這種機制提供了配置的靈活性，用戶也不須要爲每個角色單獨進行配置，減小繁雜的配置工做。

Cloudera Manager 支持角色組配置，這是一種將配置分配給一個角色組的機制。這樣，組中各個角色都會繼承這個配置。例如，在一個擁有不一樣性能主機組成的集羣中，由於性能不一樣，咱們能夠爲部署在其上的 Datanode 構建不一樣的配置組（性能好的配置高點，差的配置低點）。在性能高的一些主機上，咱們爲 Datanode組 運用配置A,性能低的一些主機上，咱們運用配置B。

主機模板（Host Templates）

一般狀況下，一些主機擁有相同的硬件，而且有相同的服務運行在上面。主機模板在集羣中提供了一系列角色組，這樣作有兩個好處：

• 加入新主機到集羣會變得簡單 - 應用已經存在的角色組，簡單的操做便可完成新主機的加入
• 對一些列主機進行角色的配置修改將變得簡單 - 用戶不須要一個個進行修改，用戶能夠快速的修改集羣配置來應對不一樣的性能負載以及不一樣用戶的需求

服務以及客戶端配置（Server and Client Configuration）

用戶有時會詫異，爲何修改 /etc/hadoop/conf 配置並重啓 HDFS後並無生效。這是由於使用 Cloudera Manager 啓動服務實例並非從默認位置的配置文件中讀取。拿 HDFS 舉例，不適用 Cloudera Manager 管理的話，一般每一個主機上都須要進行配置，配置文件是 /etc/hadoop/conf/hdfs-site.xml。相同主機上的服務進程以及客戶端將使用相同的配置。

Cloudera Manager 區分服務配置以及客戶端配置。一樣拿 HDFS 舉例，/etc/hadoop/conf/hdfs-site.xml 文件中配置項適用於 HDFS 客戶端。也就是說默認狀況下，你運行一個須要跟 Hadoop 交互的程序時，它是從這個路徑下拿到 NameNode、JobTracker 以及其餘服務的配置項。一樣，/etc/hbase/conf 和 /etc/hive/conf 狀況也是同樣。

對比之下，HDFS 角色實例（例如，Datanode 或 Namenode）則會從每一個進程的私有目錄中（/var/run/cloudera-scm-agent/process/unique-process-name）獲取配置信息。給每一個進程提供私有的運行以及配置環境，會使得 Cloudera Manager 可以獨立地控制每一個進程。例如，下面是 879-hdfs-NAMENODE 進程目錄下的內容：

$ tree -a /var/run/cloudera-scm-Agent/process/879-hdfs-NAMENODE/
  /var/run/cloudera-scm-Agent/process/879-hdfs-NAMENODE/
  ├── cloudera_manager_Agent_fencer.py
  ├── cloudera_manager_Agent_fencer_secret_key.txt
  ├── cloudera-monitor.properties
  ├── core-site.xml
  ├── dfs_hosts_allow.txt
  ├── dfs_hosts_exclude.txt
  ├── event-filter-rules.json
  ├── hadoop-metrics2.properties
  ├── hdfs.keytab
  ├── hdfs-site.xml
  ├── log4j.properties
  ├── logs
  │   ├── stderr.log
  │   └── stdout.log
  ├── topology.map
  └── topology.py
複製代碼

區分服務配置和客戶端配置有如下幾個好處：

• 服務端配置中的一些敏感信息不會暴露給用戶，例如用於存儲 HIVE 元數據的數據庫的密碼。

• 一個服務依賴如另一個服務，有時就須要這個依賴服務提供特定的版本。例如，爲了得到 HDFS 更好的讀性能，Impala 須要指定版本的 HDFS 客戶端配置，可是這樣作會影響其餘通用的客戶端訪問。爲了解決這個問題，咱們能夠將 HDFS 配置分爲針對普通客戶端（/etc/hadoop/conf）以及 Impala 客戶端（Impala 進程私有的配置目錄）。

• 客戶端配置文件更小且更加已讀。這也避免了一些不相關的配置項困擾 Hadoop 入門者。