【51CTO.com原創(chuàng)稿件】本文首先將簡要介紹我們生產(chǎn)環(huán)境中 Hadoop 集群現(xiàn)狀、Ambari 的關鍵技術，然后將重點闡述我們 Ambari 管理監(jiān)控線上 Hadoop 集群的技術方案，介紹線上接管過程中碰見的問題和解決方式。

公司在保持游戲事業(yè)快速增長的同時也認識到數(shù)據(jù)的重要性，在大數(shù)據(jù)規(guī)劃層面，為了快速加強我司的游戲數(shù)據(jù)整合能力、分析能力與行動能力，我們已經(jīng)在 2014 年年底啟動，結合成本、效率等多種因素選用 Apache 開源的 Hadoop 技術。

最初以 Hadoop v2.2.0 社區(qū)版搭建以其為核心的集群，結合自研的作業(yè)編排、數(shù)據(jù)調度等系統(tǒng)，打造了滿足游戲業(yè)務中包括平臺運營、廣告投放等數(shù)據(jù)的收集、分析與挖掘需要的大數(shù)據(jù)平臺。

然而，隨著公司游戲事業(yè)在國內、海外，頁游、手游布局的擴大，支撐公司在游戲發(fā)行與游戲研發(fā)方面不斷增長的數(shù)據(jù)資源與服務的集群規(guī)模也在不停增長。

Hadoop 游戲數(shù)據(jù)集群承載著游戲發(fā)行與游戲研發(fā)中主要包括用戶行為數(shù)據(jù)、平臺運營數(shù)據(jù)等數(shù)據(jù)的多方采集、處理與分析，為公司游戲發(fā)行各環(huán)節(jié)提供有力的數(shù)據(jù)保障。

目前 Hadoop 游戲數(shù)據(jù)集群規(guī)模已經(jīng)發(fā)展到上百節(jié)點，集群的計算能力支撐著 TB 級別的日增數(shù)據(jù)量，以及上萬次作業(yè)的處理規(guī)模。

但無論是我們的日常集群管理與監(jiān)控，還是 2016 年對集群從 v2.2.0 至 v2.7.3 的線上升級，我們發(fā)現(xiàn)對集群的管理上都不夠系統(tǒng)與全面，集群運維不夠簡便與智能。

主要有以下不足：

• 集群中資源的安裝、擴容、升級不方便，特別是資源組件間的依賴配置管理難。
• 集群中各個 Service 缺少統(tǒng)一的集群整體監(jiān)控，往往只能通過查單 Host 機器性能指標輔助排查問題和性能調優(yōu)，導致效率低下。
• 集群資源各個 Component 的監(jiān)控，無法充分利用其 Metrics 指標，基于時間序進行統(tǒng)一的健康觀察，排查穩(wěn)定性難。
• 平臺整合現(xiàn)有集群監(jiān)控運維工具難，也缺乏直觀的用戶界面，不方便有效地查勘平臺的信息和進行管理。

因此 2017 年我們經(jīng)過調研與測試業(yè)界主流的一些統(tǒng)一的平臺管理方案，目標是提高集群的穩(wěn)定性、易管理性、安全性，在對 CDH、Ambari 等作競品分析后，我們選擇了 Ambari 這個 Hortonworks 貢獻給 Apache 的頂級開源項目。

選擇的原因總體來說主要有：

• Ambari 是 Hortonworks 貢獻給 Apache 開源社區(qū)的頂級項目，屬于 Hadoop 生態(tài)中的重要組成部分，Hortonworks 本身也提供一些基于 ApacheHadoop 開發(fā)良好的商業(yè)應用組件，例如 HDP 數(shù)據(jù)平臺。
• Ambari 不僅整合了常用的運維管理工具，更重要的本身專注于 Hadoop 集群管理方案，所以它的優(yōu)勢就在于 Hadoop 集群的供應、管理和監(jiān)控等，最能解決我們的需求痛點。
• Ambari 基于 Web 的特點能夠直現(xiàn)給使用者直觀用戶界面，能夠極大提升管理效率和降低本身開發(fā)成本。

因此，我們基于 Ambari 摸索了一套接管線上 Hadoop 集群(下文中 Hadoop 游戲數(shù)據(jù)集群將簡稱為 Hadoop 集群)的技術方案并成功實踐之，如同 Ambari 從零供應一個集群一樣，將基于 Web 的 Ambari 充分利用在了對集群的管理與監(jiān)控上。

生產(chǎn)環(huán)境中 Hadoop 集群現(xiàn)狀

首先介紹我們生產(chǎn)環(huán)境中 Hadoop 集群的現(xiàn)狀，Hadoop 集群主要承擔了數(shù)據(jù)接入存儲、離線計算的職責，同時提供其上數(shù)據(jù)調度等自研系統(tǒng)的基礎服務。生產(chǎn)環(huán)境中 Hadoop 使用的版本是 v2.7.3，下面介紹其主要組件。

首先 HDFS 采用了 HA with QJM 的高可用架構，即采用 Standby Namenode 熱備、多節(jié)點協(xié)同同步 Active/Standby Namenodes(不同物理機器)之間元數(shù)據(jù)日志的方式，降低之前單點 Namenode 因為故障而導致的集群服務不可用的時間，提高集群的可用性。

并且如下圖中，Active/StandBy Namenode 節(jié)點各自運行了基于 Zookeeper 集群自動監(jiān)控 Namenodes 狀態(tài)、自動選舉保證集群 Namenode 只有一個處于 Active 狀態(tài)的 ZKFailoverController。

圖 1  HDFS HA with QJM

接著是用于集群資源分配與作業(yè)調度的 Yarn 框架，我們采用了 Yarn 的 FairScheduler 公平調度策略，并且根據(jù)不同業(yè)務線集群使用成本投入占比，劃分了作業(yè)執(zhí)行隊列以及隊列使用的資源池，各個資源池合理定義了最大同時運行作業(yè)數(shù)、Min/Max 可參與分配的資源(Vcore 數(shù)、mem 大小)、動態(tài)競爭其他空閑隊列資源池資源權重等參數(shù)。

除開業(yè)務線使用的各隊列之外，還定義了 Default 的共享作業(yè)隊列，分配其較小的資源用于保證其他一些例如集群數(shù)據(jù)的共享查詢等應用。

圖 2  YARN FairScheduler 資源分配圖

集群 ETL 離線作業(yè)處理與數(shù)據(jù)查詢我們主要基于 Hive，Hive 是 SQL on Hadoop 的數(shù)據(jù)倉庫工具，具備良好的類似以關系型數(shù)據(jù)庫的方式存儲管理接入數(shù)據(jù)、提供對外數(shù)據(jù)處理接口特性，以 Hive 為基礎我們打造了大數(shù)據(jù)中心，安全、簡潔、便捷地統(tǒng)一接入數(shù)據(jù)以及對外統(tǒng)一提供數(shù)據(jù)處理基礎服務。

并且在發(fā)展過程中，為了提高數(shù)據(jù)中心服務水平，我們將 Hive 版本升級至 v2.1，其 HiveServer2 服務能夠更好支持并發(fā)和身份認證以及開放 API 客戶端(如 ODBC 和 JDBC)，且其更好支持內存計算(TEZ+LLAP)也為后續(xù)升級提供了基礎。

圖3  Hive 2.1 應用架構圖

除開上述主要介紹的 Hadoop 集群中組件應用之外，我們還有包括 Flume+Kafka 分布式日志采集與隊列數(shù)據(jù)分發(fā)的完整數(shù)據(jù)流架構，該架構使用 Zookeeper 集群做協(xié)同服務和配置管理，在這里不一一贅述。

最后是 Hadoop 集群原有的監(jiān)控和告警邏輯，在進程監(jiān)控這塊我們采用 Crontab 周期性從主控節(jié)點 ssh 至集群每個節(jié)點，輪詢檢查每個主要進程的運行狀況，一旦發(fā)現(xiàn)進程掛掉則告警且重新啟動；在性能監(jiān)控這塊(例如 Yarn 任務堆積數(shù))我們也是采用 Crontab 周期性的調組件監(jiān)控接口獲取相關 Mertrics 數(shù)值，告警異常值的方式。

至此我們已經(jīng)梳理完畢生產(chǎn)環(huán)境中 Hadoop 集群現(xiàn)狀，其上支撐的業(yè)務之廣、使用人之多，就決定了我們 Ambari 線上接管集群不容有失，且需要最大限度降低接管過程中對業(yè)務造成的影響。

Ambari 相關技術介紹

接下來我們將簡單介紹 Apache Ambari 相關技術，Ambari 是 Hortonworks 貢獻給 Apache 開源管理 Hadoop 集群的頂級開源項目上文已提及，主要用于 Hadoop 集群的部署、監(jiān)控與告警，Ambari 整體架構如下圖，主要由 5 部分組成：

圖 4 Ambari 整體架構圖

• Ambari Web: 用戶交互界面，通過 HTTP 發(fā)送使用 Rest Api 與 Ambari Server 進行交互。
• Ambari Server: Web 服務器，用于和 Web、Agent 進行交互并且包含了 Agent 的所有控制邏輯，Server 產(chǎn)生的數(shù)據(jù)存儲在 DB 中。
• Ambari Agent: 守護進程，主要包含節(jié)點狀態(tài)與執(zhí)行結果信息匯報 Server 以及接受 Server 操作命令的兩個消息隊列。
• Host: 安裝實際大數(shù)據(jù)服務組件的物理機器，每臺機器都有 Ambari Agent 服務與 Metrics Monitor 守護進程服務。
• Metrcis Collector: 主要包括將 Metrics Monitor 匯報的監(jiān)控信息存儲到 Hbase，以及提供給 Ambari Server 的查詢接口。
• Ambari 整體管理集群方面以 Ambari Server 為核心，維護著一個 FSM 有限狀態(tài)機，包含平臺中所有部署 Agent 并注冊的節(jié)點、部署的服務與組件的狀態(tài)變化信息、配置文件并且持久化在 Ambari Server 端的 DB 中。

對外一方面通過 rest Api 接口方式與 Ambari Web 交互，一方面接受來自 Agent 的定時心跳請求，所有交互信息中包含了節(jié)點狀態(tài)、事件信息、動作命令中其中至少一種，由 Ambari Server 統(tǒng)一協(xié)調命令和維護狀態(tài)結果，然后給 Agent 下發(fā)的相關 command，Ambari Agent 接受命令執(zhí)行相關邏輯并返回狀態(tài)結果。

Ambari 整體監(jiān)控方面通過 Ambari Server 獲取 Ambari Metrics Collector 中聚集后的從各個節(jié)點 Ambari Metrics Monitor 上報的單節(jié)點監(jiān)控指標數(shù)據(jù)，在 Ambari Web 中給出圖形化的展示。

Ambari 是 HDP 數(shù)據(jù)平臺套件的一部分，HDP 是 Ambari 管理集群的技術?；A。HDP 即 Hortonworks Data Platform，是 Hortonworks 完全開源以 Yarn 為核心整合 Apache Hadoop 技術的一個安全的企業(yè)級數(shù)據(jù)平臺，HDP 涵蓋了幾乎所有 Hadoop 的數(shù)據(jù)離線處理技術，以及最新的實時處理技術滿足用戶需求，如下圖所示，其 2017 年開源的 HDP v2.6 正好支持 Hadoop v2.7.3。

圖 5 HDP 數(shù)據(jù)平臺技術涵蓋

Ambari 支持對 HDP 的供應或者說 Ambari 基于 HDP 數(shù)據(jù)平臺，下面是幾個核心概念：

• Stack：Ambari 支持管理的 HDP 整個技術棧，本身技術棧也有版本區(qū)分，例如 HDP 2.6  就是 Hortonworks 基于 Apache Hadoop v2.7.3 與 Apache 協(xié)議的 2017 年發(fā)行版。
• Service：Ambari 支持管理的某個具體服務，比如 HDP 中的 HDFS、Yarn 等，可以部署、管控的一個完整 Framework 技術方案。
• Component：Ambari 支持管理的最小組件單位，由于 Service 服務大多數(shù)為分布式應用，Componet 即細分為 Master、Slave、Client 等組件。

Ambari 按照 Stack -> Service -> Component 的層次關系，管理著 HDP 之間各組件依賴關系，通過 Service Metainfo 的定義來管理組件的依賴管理配置。

例如 Yarn 的metainfo.xml 文件中定義了 Yarn 需要 HDFS 和 MR2 的支持，配置文件依賴 Hadoop 的主要配置文件 core-site、hdfs-site 等。

其中 HDFS、MAPREDUCE2 為 Ambari 管理的 Service，而 HDFS 中每一個運行實例，例如 Namenode、DataNode 為 Ambari 管理的 Component。

Ambari 接管線上 Hadoop 集群問題與思路

上文中已提及在 Ambari 接管線上 Hadoop 集群時，需要主要考慮兩方面的問題：

• Ambari 接管之后怎樣保證集群依舊能夠支撐原先支撐的所有上層應用。
• Ambari 接管動作怎樣降低對線上 Hadoop 集群提供服務的影響。

問題描述

圍繞上述這兩方面，首先我們梳理了集群上支撐系統(tǒng)的所有使用接口，包括調度系統(tǒng)中使用的 HDFS RestApi，數(shù)據(jù)中心使用的 Hive Jdbc、ThriftApi，實時采集和分發(fā)系統(tǒng)使用的 Zookeeper 服務。

其中涉及到的主要技術組件例如 HDFS、Hive、Zookeeper，HDP 中各組件的版本應該向下兼容最好版本一致(Hadoop v2.7.3、Hive 2.1.0 等等)，保證功能特性滿足。

根據(jù) HDP 提供的組件信息，我們選擇了 HDP v2.6.0.2，并且針對 HDP v2.6 對其包含的組件功能特性與社區(qū)版各組件功能特性進行對比，確保了 HDP v2.6.0.2 支持現(xiàn)有所有功能特性。

然后是支持 HDP v2.6.0.2 作為 Stack 的 Ambari v2.5.1.0，接下來是確定 Ambari v2.5.1.0 管理 HDP v2.6.0.2 下的各個 Service 可行性：

圖6  HDP-2.6.0.2 與 Hadoop - 2.7.3 各 Service 版本對比

從上面的對比圖中可以發(fā)現(xiàn)，Ambari 是支持管理大多數(shù)與線上集群組件版本一致的組件的。

但是也有例外，例如 Hive，Ambari 支持管理的版本比線上集群中的低，而我們生產(chǎn)環(huán)境中數(shù)據(jù)中心等上層應用都是基于 Hive 2.1.0 接口運行的。

所以 Ambari 接管線上集群不得不解決Hive的兼容性問題，才能最終達到 Ambari 管理為我們所用的生產(chǎn)集群的目標。

接著需要考慮的是 Ambari 自動供應的 HDP 集群怎樣與線上 Hadoop 集群兼容，就拿其中比較重要的一個必要條件來說：接管后的 HDP HDFS 能夠唯一管理線上已有集群數(shù)據(jù)，而要能夠順利實現(xiàn)這一目標就得 Ambari 管理的 HDP 能夠代替原有 Hadoop 集群。

所以 Ambari 接管線上集群的問題就轉化成了集群升級的問題，升級問題要考慮的是最小化停機的影響以及能夠回滾恢復，以及充分利用 Ambari 的特性。

解決思路

現(xiàn)在已經(jīng)了解到了此次 Ambari 接管線上集群的問題，我們來說說解決上述問題的思路。首先是 Ambari 管理組件兼容性問題，以 Hive 組件為例，雖然 Ambari v2.5.1 在管理方面只支持 Hive v1.2.1，但是作為整個 HDP v2.6.0.2 提供的技術組件中包含了 Hive v2.1.0(見圖 5)。

Hive v2.1.0 組件的保留是為了兼容 Hive2 包括 LLAP、CBO 等一系列新功能，在 Ambari 部署 Hive 組件時，會分為 Hive v1.2.1 與 Hive v2.1.0 兩個版本同時部署，下圖中通過主要 jar 包報名版本號可以看出，HDP 功能組件根目錄的 hive 與 hive2 子目錄分別為 Hive v1.2.1、Hive v2.1.0 組件根目錄。

圖 7 HDP 中 hive 與 hive2 功能版本對比

Ambari 部署 Hive 完畢后，接下來是生成配置與組件啟動邏輯，而 Ambari 默認是支持 Hive v1.2.1 即配置生成與啟動時針對的是 hive，那么我們需要調整的目標是讓它針對 hive2。

回顧 Ambari 執(zhí)行邏輯，完整的一次交互是用戶在 Ambari Web 界面操作 -> Ambari Server 請求處理&命令下發(fā)具體機器 -> 具體機器 Ambari Agent 執(zhí)行相關操作，而在這里 Ambari Agent 啟動 Hive(實際分為 HiveMetaStore、HiveServer、HiveClient 等 Component，每個 Component 啟動執(zhí)行邏輯一致，故在這里統(tǒng)一稱為啟動 hive)過程包括了解析下發(fā)命令、從 DB 拉取配置信息、更新配置文件、啟動 Hive。

因為配置文件對于各個 Hive 中 Component 一致，所以更新配置文件的執(zhí)行邏輯也一致，并且 hive2 是能夠向下兼容 hive 中的所有配置項的，因此在更新 hive 配置文件的邏輯最后增加同步配置至 hive2 配置的功能，就實現(xiàn)了在 Ambari Web 頁面也能夠更新本不支持的 hive2 的配置了，并且因為 Ambari 有自定義配置項功能支持所以也不用擔心 hive2 配置項 hive 中不支持的問題。

圖 8 hive 更新配置增加同步至 hive2 功能

配置支持的問題解決了，然后是 Hive 啟動的問題，啟動邏輯更加簡單即默認以 hive/bin 目錄下啟動腳本啟動相關組件之前會嘗試去獲取機器的 HIVE_HOME 系統(tǒng)環(huán)境變量，所以在節(jié)點提前配置 hive2 的相關系統(tǒng)環(huán)境變量，則啟動邏輯會以 hive2/bin 目錄下的啟動腳本啟動相關組件，同樣的關閉、重啟等邏輯也會按照 hive2 的邏輯執(zhí)行。

至此通過類似”移花接木”的方式實現(xiàn)了 Ambari 管理 Hive v2.1.0 的目標，即在 Ambari Web 頁面上的管理操作的生效對象為 HDP Hive2 即 Hive v2.1.0。

接著是 Ambari 接管線上集群如何轉化成線上升級，集群升級中的要點包括：舊版本元數(shù)據(jù)的備份(Namenode、Journalnodes 等)，舊版本配置在新版本配置的覆蓋和調優(yōu)，可能升級失敗的回滾方案準備，實施升級時段選在集群使用空閑時間，升級前的演練等。

這些方案此次 Ambari 接管線上集群升級同樣受用，但是同時也要考慮一些特殊的細節(jié)：第一，Ambari 支持的 Hadoop 集群供應并沒有直接 HA with QJM 的方案，在 HDFS 部署時必須按照 SNN 冷備方案部署然后調整為 HA with QJM 的步驟。

第二，集群中的 Zookeeper 服務支持的一些實時型業(yè)務就決定了 Zookeeper 服務不能與 Hadoop 升級那樣需要停機而造成服務不可用的空窗期。

第三，Ambari 管理的組件程序運行 role 與現(xiàn)有組件程序運行 role 的不同導致的主要包括文件權限等問題，以及由于此前 Hadoop 集群經(jīng)歷過節(jié)點擴容、節(jié)點配置個性化差異如何在 Ambari 統(tǒng)一配置管理中避免沖突的問題。

而且我們需要保證的目標包括了：

• 架構上與原有集群一致，比如 nn 節(jié)點、dn 節(jié)點的分布等，盡可能與原有集群組件機器分配一致。
• 升級最重要的是我們的數(shù)據(jù)資產(chǎn)，數(shù)據(jù)不能丟，所以重要配置比如 hdfs 各存儲日志文件目錄、索引文件目錄等等必須一致。
• 再就是各組件重要參數(shù)，比如服務命名空間、文件塊大小、資源調度策略等等，也要盡可能一致。

所以綜上所述，我們將 Ambari 接管線上集群升級拆分為下面幾大步驟：

圖9 Ambari 接管線上集群升級步驟

在升級前的準備部分中將把所有的相關資源提前部署以及配置好，線上升級操作部分中只操作 Ambari 啟動相關組件，完成線上集群運行組件的替換，所以集群停機影響時間縮短至 Hadoop、Hive 相關啟動的時間，最大化減小了停機的影響。

升級前準備工作主要分為兩個部分：第一，按照 Ambari 官網(wǎng)提供的部署方式部署并啟動 Ambari 各組件，然后在 Ambari Web 上按照 Ambari Cluster Install Wizard 并且根據(jù)線上現(xiàn)有集群的組件分布，選擇相應 HDP 組件的部署節(jié)點，確保將 HDP 各組件部署節(jié)點與線上集群各組件運行節(jié)點保持一致后，Ambari 將會在各節(jié)點 Install HDP 的各組件，最后由于節(jié)點已有運行組件的端口沖突會導致 Start 失敗，不過不影響 Ambari 成功完成部署 HDP 各組件。

第二，Ambari 線上升級前環(huán)境準備首先最重要的是與現(xiàn)有集群的配置同步，同樣在 Ambari Web 界面中操作，這里需要注意的是現(xiàn)有集群不同節(jié)點的差異化配置在 Ambari 中使用 Config Group 同樣進行差異化配置，比如集群中 DataNode 機器節(jié)點在磁盤上的差異情況，在 Ambari 中配置不同節(jié)點組對應的配置如下圖：

圖10 不同 DataNode 節(jié)點組 Blocks 目錄差異化配置

依次對 Hadoop、Hive 等組件完成配置同步；接著是準備所有執(zhí)行邏輯腳本，包括剛才提到的涉及到功能修改的相關 Ambari Agent python 功能腳本以及升級上線操作時的包括備份 NN、JN 元數(shù)據(jù)、統(tǒng)一修改系統(tǒng)環(huán)境變量等命令腳本，至此升級前的所有準備工作全部完成。

線上升級操作部分也分為兩部分：

第一，Ambari 線上升級 Hadoop，首先是 Zookeeper 集群的升級，采用從 Zookeeper 的 follower 機器開始一臺一臺停掉線上、Ambari 啟動相應節(jié)點，因為在配置同步過，所以 Ambari 啟動的 zk 是讀取原有 zk 的數(shù)據(jù)，待所有 follower 節(jié)點操作完畢之后操作 leader 節(jié)點。

然后是 Hadoop 的升級，Hadoop 升級前暫時關閉所有程序訪問入口(提前公告通知)，Hadoop 升級中最重要的是 Hdfs 的升級。Hdfs 的升級分為 SNN 冷備方案 HDFS 啟動與 Enable HA with QJM 兩步：

• 第一步讓原有集群進入安全模式確保沒有數(shù)據(jù)寫入時，備份所有 Namenode、Journalnode 節(jié)點元數(shù)據(jù)，執(zhí)行關閉集群腳本在確保 Hadoop 組件全部關閉后執(zhí)行修改所有節(jié)點系統(tǒng)環(huán)境變量腳本(修改為新 HDP 集群的系統(tǒng)環(huán)境變量)。

根據(jù) Ambari 中提示啟動 HDFS，由于 Namenode 重啟需要一定時間(在這里不介紹 Namenode 重啟優(yōu)化了)，等待集群 check blocks 直至自動退出安全模式后至此 SNN 冷備方案的 HDFS 正式啟動成功。

• 第二步在 Ambari 中操作 Enbale HA with QJM，每一步的操作根據(jù)操作指南即可，需要注意的是過程當中可能會出現(xiàn)原有的 Stand By Namenode 元數(shù)據(jù)缺少因為第一步中單 Namenode 運行過程中產(chǎn)生的部分元數(shù)據(jù)，可以同步 Namenode 中 fsimage 與 editLog 文件至 Stand By Namenode 并重新 initializeShareEdits。

正常情況下在 Enable HA 最后 Ambari 又會重啟一次 HDFS，重啟完成之后至此 HDFS 升級完畢，依次啟動 Mapreduce2、Yarn 服務，整體 Hadoop 升級完畢。

第二，Ambari 線上升級 Hive，在第一部分 Hadoop 成功升級后相對來說 Hive 的升級比較容易，在更新 Hive Metastore 中相關元數(shù)據(jù)信息(DBSCHEMA)之前首先對數(shù)據(jù)庫進行備份，更新 HiveMetaStore Schema、執(zhí)行啟動 Hive 即可，因為已經(jīng)部署了修改邏輯后的代碼部分，Hive 將以 Hive v2.1.0 在線上提供服務。

上面四大步驟順利完成之后，Ambari 就成功接管了線上集群，集群支撐的上層服務可以開放入口給使用者使用了。后續(xù)圍繞 Ambari 的監(jiān)控功能，使用其 api 接口可以定制各種個性化的監(jiān)控和告警服務，至此 Ambari 成功接管線上集群。

Ambari 接管線上 Hadoop 集群實踐

上文中想必讀者已經(jīng)了解了我們 Ambari 實踐最終想要達到的目標，其中存在的主要問題以及問題解決的思路，現(xiàn)在我們介紹 Ambari 接管線上 Hadoop 集群的實踐過程。

因為此次 Ambari 接管線上 Hadoop 集群動的是我們集群或者說是大數(shù)據(jù)平臺的最底層，影響范圍大所以每個步驟環(huán)節(jié)我們都謹小慎微確保無誤，防止一丁點的疏忽導致整體大數(shù)據(jù)平臺崩盤的”蝴蝶效應”出現(xiàn)。

所以我們從開發(fā)集群開始，目標是在使用 Ambari 從零搭建集群過程中，了解其核心特性和對機器運行環(huán)境的所有依賴；然后是在我們 Hadoop 測試集群上，Hadoop 測試集群不僅有與生產(chǎn) Hadoop 集群同樣的環(huán)境與配置，并且也支撐著同樣的用于測試目的的上層應用系統(tǒng)。

在灰度集群上我們按照上文中四步驟完整演練了較多次，總結了一些其中碰見的問題和應急解決方案，除開節(jié)點規(guī)模和數(shù)據(jù)量比不上線上 Hadoop 集群之外，升級方案方面已經(jīng)確定。

最后是使用在測試集群中的上線方案，選擇恰當?shù)臅r機在線上環(huán)境完整執(zhí)行了一遍，Ambari 線上操作部分整體耗時控制在了 2h 以內，Ambari 接管后集群整體運行正常，支撐的上層應用無報錯。

下面將把 Ambari 接管線上 Hadoop 集群實踐過程中的關鍵點著重講述，讓讀者了解接管升級實踐過程中需要關注的部分。

配置同步

Ambari 接管的目標是對于集群使用者來說感受不到集群本身的變化，所以能否接管線上集群的關鍵點之一在于集群配置的同步，準確點是說 Ambari 使用的 HDP 中各個 Component 組件系統(tǒng)參數(shù)、應用參數(shù)、運行時環(huán)境變量等都需要保持一致，下面將介紹幾個主要配置文件中的重要配置項。

以下圖中的 HDFS core-site.xml 配置為例，core-site.xml 配置文件是 HDFS 重要配置文件之一，可以看見黃色標注部分為我們在 Ambari 線上升級 Hadoop HDFS 時分階段 fs.defaultFS 的不同配置：

第一步單點啟動時配置保證了單 Namenode 啟動的順利進行，到第二步 Enable HA 時，修改為 HA 時候的必要配置。

然后對于 Hadoop 集群使用者來說，增加了 root、hive 用戶與用戶組的訪問也是為了兼容 Ambari 接管后的 HDFS 運行 role 為 hdfs 用戶的訪問兼容，當然只有權限級別比較高的 root 和 hive 用戶能夠享有這個權限。

接著是 Namenode 運行的最大內存大小等參數(shù)，Ambari 默認的都比較小，這一點需要特別注意根據(jù)原有集群的運行 Namenode 進程運行時內存參數(shù)來調節(jié)這些參數(shù)。

然后再來看看 Yarn 相關的配置項，我們以 yarn-site.xml 配置文件中主要配置項為例：橙色標注的部分為需要根據(jù)原有集群做調整的部分，其中包括需要根據(jù)具體節(jié)點內存大小情況來合理選擇 NodeManager 可用于分配的最大內存，增加 mapreduce_shuffle 選項以支持集群中的 MapReduce 程序。

當然還有 Yarn 的調度策略，在生產(chǎn)集群環(huán)境介紹中已提到使用的是根據(jù)業(yè)務劃分的 FairScheduler，而 Ambari 中默認使用的是 Capacity Scheduler，所以需要特別注意調度策略以及相關的配置與原有保持一致。

圖 11 HDFS core-site.xml 主要配置項

圖 12 Yarn yarn-site.xml 主要配置項

最后是一些組件的數(shù)據(jù)存儲路徑的配置，Ambari 能夠接管線上集群，必須 HDP 各組件使用之前的數(shù)據(jù)來保證，所以數(shù)據(jù)存儲路徑的配置也是至關重要的。

圖 13 主要組件的主要數(shù)據(jù)存儲路徑配置項

升級操作

在升級操作前，我們會關閉所有訪問集群的應用入口，特別是集群數(shù)據(jù)接入與定時作業(yè)這一塊，保證集群沒有數(shù)據(jù)繼續(xù)寫入后，我們接著關閉所有之前的集群進程運維監(jiān)控腳本，防止升級過程中原有集群組件進程運行的恢復影響升級。

接著為了方便在 Namenode 統(tǒng)一執(zhí)行關閉集群操作，我們根據(jù)關停腳本的邏輯即各節(jié)點會找到存放對應進程(Datanode、NodeManager)PID 文件路徑，根據(jù)文件記錄的 PID 執(zhí)行 Kill 操作。

但是由于部分 PID 文件存放在系統(tǒng) tmp 文件夾下可能已經(jīng)被刪除，所以我們提前在各個節(jié)點部署了檢查各自運行進程并還原可能缺失的 PID 文件的腳本，并且在正式關停前，統(tǒng)一執(zhí)行還原進程 PID 文件，NN、JN 節(jié)點元數(shù)據(jù)文件信息備份后才執(zhí)行關停操作。

然后在 Ambari 升級 Hadoop 之前，我們通過 Hdfs 管理界面記錄系統(tǒng)的元數(shù)據(jù)信息，并且在 Ambari 完成整體 Hadoop 升級后，我們詳細對比了 Hdfs 記錄的元數(shù)據(jù)信息(下圖中選擇的為 Ambari 接管測試集群的統(tǒng)計數(shù)據(jù))：

圖15  Ambari 接管測試集群升級前后文件對比

在確定升級前后 Blocks 完全一致后，整體 Hadoop 升級確認完成。最后是 Ambari 升級 Hive，在步驟 2 集群關停操作完成之后，我們同步進行了 Hive MetaStore DB 的備份，因為 HiveMetaStore DB 只存儲 Hive 相關元數(shù)據(jù)信息，所以 hivemeta DB 本身不大，備份起來速度也較快。

在正式 Ambari Hive 升級之前，使用 SchemaTool 工具更新 hivemeta 庫，最后啟動 Hive。

我們在 Hadoop 與 Hive 升級啟動完畢之后，我們迅速使用命令腳本模擬包括調度系統(tǒng)、數(shù)據(jù)中心等線上系統(tǒng)訪問集群，測試新上線集群對外接口的可用性，確保測試都通過后，我們正式開放了各個上層應用，至此整體的上線時間耗時控制在了 2h 以內，整體升級操作時間軸如下：

圖16  線上集群升級各過程時間軸

后續(xù)運用

Ambari 接管線上集群后，在 Ambari Web 中可以對集群中所有組件進行統(tǒng)一管理：

圖17 集群組件操作界面

上圖中為集群中組件列表，以 HDFS 為例，對于 HDFS 的操作列表中包括了對 NameNode、DataNode、JournalNode 等的常用操作，通過界面即可統(tǒng)一操作。

統(tǒng)一配置管理將不同的配置文件分類給出，使用者根據(jù)相應的配置項屬性名填寫屬性值同步即可，用戶可自定義配置項，配置同步后有歷史版本概念，多版本之間可以對比。

Ambari Web 中將監(jiān)控集群捕獲到的關鍵操作指標值通過良好的 Widget 可視化，幫助我們日常能夠快速排查和解決問題，在主動預防問題上面提高了不少效率。

例如我們通過觀察 Yarn Pending Apps 的個數(shù)，發(fā)現(xiàn)堆積比較嚴重的時段后，會合理去調整作業(yè)的執(zhí)行時間；通過觀察集群整體 CPU 與內存的利用率，可以快速定位集群計算能力的瓶頸即 CPU 使用率較高但是內存使用率相對較低，然后我們會合理調整 Yarn 中 Container 對于 CPU 利用的策略等。

圖19 監(jiān)控指標值可視化

由于我們可以在統(tǒng)一的 Ambari Web 界面中對集群組件進行操作、配置管理，基于 Ambari 集群統(tǒng)一管理特性標準與規(guī)范化了集群的運維管理操作，相應的操作例如增加刪除節(jié)點、組件遷移、配置修改等，都有明確的權限范圍以及完整的操作歷史記錄，并且將 Ambari 所有使用者入口做統(tǒng)一管理，公司內部相關人員只能在權限范圍內對集群進行有跡可循的操作。

圖20  集群管理者各角色權限表

如上表將對于集群的運維管理操作角色權限分成四個 Level，最低的 Level 是能夠在 Ambari Web 中查看集群的運行狀態(tài)、配置、告警等信息。

但是對于集群沒有任何的操作權限，此類權限開放給所有需要對集群運行健康狀態(tài)有關注的集群使用者，例如可以在 Tez View 中查看自己的作業(yè)運行情況，在 Yarn 管理界面中查看負載等等。

然后在針對集群可操作人群，同樣劃分了操作組件級別、集群整體級別兩個 Level，一般的集群運維人員可以去管理其中組件、進行調優(yōu)，而上升到集群統(tǒng)籌規(guī)劃這一層面，則需要對整體架構熟知的集群架構人員去管理。

最后超級管理員除開上述所有權限之外，多了一層 Ambari 本身系統(tǒng)級別的管理。

管理權限按層級劃分，既能夠滿足不同集群使用者的要求，同樣也保護了集群的運行安全和穩(wěn)定。

然后我們根據(jù) Ambari 提供的監(jiān)控功能開發(fā)了相應的配套處理程序，目的在于第一使用我們自己的告警系統(tǒng)去替代 Ambari 中不太友好的告警系統(tǒng)；第二充分利用 Ambari api 不僅實現(xiàn)告警而且能夠在故障出現(xiàn)時一定程度上嘗試自動恢復。提高我們在集群監(jiān)控、管理方面的效率。

首先 Ambari 提供了良好的 Restapi 用于與集群的各種直接交互，下面我列舉一組 Restapi 示例：

http://ambari/api/v1/clusters/hdp/hosts/${host_name}/host_components/ZKFC  
 
{ 
 
         "RequestInfo": { 
 
                   "context":"ReStart  ZKFC", 
 
                   "operation_level":{ 
 
                            "cluster_name":"hdp", 
 
                            "host_name":"${host_name}", 
 
                            "service_name":"HDFS" 
 
                   } 
 
         }, 
 
         "Body": { 
 
                   "HostRoles": { 
 
                            "state":"STARTED" 
 
                   } 
 
         } 
 
} 

上述 URL 為典型的操作指定機器 ZKFC 進程的命令，如果 Http 動作是 GET 則返回該進程的狀態(tài)信息，如果是 PUT 且增加 json 請求內容則是對 ZKFC 的一次具體操作，從 RequestInfo 中 context 的描述可以看出是對 ZKFC 的重啟操作，operation_level 描述了具體操作對象的信息屬于哪個集群哪個節(jié)點，以及 ZKFC 屬于 HDFS 服務的一個組件，最后 Body Host Roles 描述了 ZKFC 重啟操作后應該屬于啟動狀態(tài)。

介紹完了 Ambari 中的操作 API，我們利用 api 的特性設計了一套完整的自動發(fā)現(xiàn)組件疑似嚴重錯誤、確認錯誤并告警、嘗試恢復的功能配件。

完整邏輯圖如下：

定期掃描 dm_monitor_info，Ambari 中定義的告警項的周期掃描狀態(tài)，發(fā)現(xiàn)組件存在的最近一次的隱患，確認組件是否真正處于服務不可用的狀態(tài)(可能是集群在維護即 maintainance_state=‘ON’)后，記錄該次告警信息，周期性嘗試自動恢復正常之前告警系統(tǒng)報告消息，直到恢復后最后一次向告警系統(tǒng)報告成功恢復消息后，消除此次告警信息。

根據(jù)上線后運行近半年的統(tǒng)計，累計自動恢復組件時間分布如下圖，Ambari 中最小掃描周期為一分鐘，所以按照分鐘級別的掃描出疑似組件問題與自動恢復的平均時間在五分鐘之內，且絕大多數(shù)故障恢復在一分鐘，大大提高了組件的服務可用性。

后記

在 Ambari 接管線上集群后已經(jīng)穩(wěn)定運行了半年之久，它幫助我們大大提高了集群管理、監(jiān)控方面的效率，在幫助我們性能排查、科學調優(yōu)方面給了很大的幫助。

當然 Ambari 管理與監(jiān)控集群只是大數(shù)據(jù)平臺基礎建設的第一步，在智能化、企業(yè)級大數(shù)據(jù)平臺基礎建設過程中，我們會利用其提供的 HDP 平臺服務不斷提高大數(shù)據(jù)平臺基礎服務水平。

作者：陳燃

簡介：碩士，三七互娛大數(shù)據(jù)開發(fā)工程師，一直專注于圍繞 Hadoop 為主的大數(shù)據(jù)平臺研發(fā)工作。

【51CTO原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為51CTO.com】