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

摘要： 請輸入圖片描述 掃碼關注微信公眾號"Kooola大資料" <font color=grey size=1 >掃碼關注微信公眾號號"Kooola大資料"，一起聊聊大資料</font> ...

<font color=grey size=1 >掃碼關注微信公眾號號"Kooola大資料"，一起聊聊大資料</font>

架構（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 入門者。