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

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

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

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

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

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

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

主要有以下不足：

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

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

選擇的原因總體來(lái)說(shuō)主要有：

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

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

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

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

首先 HDFS 采用了 HA with QJM 的高可用架構(gòu)，即采用 Standby Namenode 熱備、多節(jié)點(diǎn)協(xié)同同步 Active/Standby Namenodes(不同物理機(jī)器)之間元數(shù)據(jù)日志的方式，降低之前單點(diǎn) Namenode 因?yàn)楣收隙鴮?dǎo)致的集群服務(wù)不可用的時(shí)間，提高集群的可用性。

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

圖 1  HDFS HA with QJM

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

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

圖 2  YARN FairScheduler 資源分配圖

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

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

圖3  Hive 2.1 應(yīng)用架構(gòu)圖

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

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

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

Ambari 相關(guān)技術(shù)介紹

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

圖 4 Ambari 整體架構(gòu)圖

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

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

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

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

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

Ambari 支持對(duì) HDP 的供應(yīng)或者說(shuō) Ambari 基于 HDP 數(shù)據(jù)平臺(tái)，下面是幾個(gè)核心概念：

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

Ambari 按照 Stack -> Service -> Component 的層次關(guān)系，管理著 HDP 之間各組件依賴(lài)關(guān)系，通過(guò) Service Metainfo 的定義來(lái)管理組件的依賴(lài)管理配置。

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

其中 HDFS、MAPREDUCE2 為 Ambari 管理的 Service，而 HDFS 中每一個(gè)運(yùn)行實(shí)例，例如 Namenode、DataNode 為 Ambari 管理的 Component。

Ambari 接管線上 Hadoop 集群?jiǎn)栴}與思路

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

• Ambari 接管之后怎樣保證集群依舊能夠支撐原先支撐的所有上層應(yīng)用。
• Ambari 接管動(dòng)作怎樣降低對(duì)線上 Hadoop 集群提供服務(wù)的影響。

問(wèn)題描述

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

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

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

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

圖6  HDP-2.6.0.2 與 Hadoop - 2.7.3 各 Service 版本對(duì)比

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

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

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

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

所以 Ambari 接管線上集群的問(wèn)題就轉(zhuǎn)化成了集群升級(jí)的問(wèn)題，升級(jí)問(wèn)題要考慮的是最小化停機(jī)的影響以及能夠回滾恢復(fù)，以及充分利用 Ambari 的特性。

解決思路

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

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

圖 7 HDP 中 hive 與 hive2 功能版本對(duì)比

Ambari 部署 Hive 完畢后，接下來(lái)是生成配置與組件啟動(dòng)邏輯，而 Ambari 默認(rèn)是支持 Hive v1.2.1 即配置生成與啟動(dòng)時(shí)針對(duì)的是 hive，那么我們需要調(diào)整的目標(biāo)是讓它針對(duì) hive2。

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

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

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

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

至此通過(guò)類(lèi)似”移花接木”的方式實(shí)現(xiàn)了 Ambari 管理 Hive v2.1.0 的目標(biāo)，即在 Ambari Web 頁(yè)面上的管理操作的生效對(duì)象為 HDP Hive2 即 Hive v2.1.0。

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

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

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

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

而且我們需要保證的目標(biāo)包括了：

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

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

圖9 Ambari 接管線上集群升級(jí)步驟

在升級(jí)前的準(zhǔn)備部分中將把所有的相關(guān)資源提前部署以及配置好，線上升級(jí)操作部分中只操作 Ambari 啟動(dòng)相關(guān)組件，完成線上集群運(yùn)行組件的替換，所以集群停機(jī)影響時(shí)間縮短至 Hadoop、Hive 相關(guān)啟動(dòng)的時(shí)間，最大化減小了停機(jī)的影響。

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

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

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

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

線上升級(jí)操作部分也分為兩部分：

第一，Ambari 線上升級(jí) Hadoop，首先是 Zookeeper 集群的升級(jí)，采用從 Zookeeper 的 follower 機(jī)器開(kāi)始一臺(tái)一臺(tái)停掉線上、Ambari 啟動(dòng)相應(yīng)節(jié)點(diǎn)，因?yàn)樵谂渲猛竭^(guò)，所以 Ambari 啟動(dòng)的 zk 是讀取原有 zk 的數(shù)據(jù)，待所有 follower 節(jié)點(diǎn)操作完畢之后操作 leader 節(jié)點(diǎn)。

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

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

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

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

正常情況下在 Enable HA 最后 Ambari 又會(huì)重啟一次 HDFS，重啟完成之后至此 HDFS 升級(jí)完畢，依次啟動(dòng) Mapreduce2、Yarn 服務(wù)，整體 Hadoop 升級(jí)完畢。

第二，Ambari 線上升級(jí) Hive，在第一部分 Hadoop 成功升級(jí)后相對(duì)來(lái)說(shuō) Hive 的升級(jí)比較容易，在更新 Hive Metastore 中相關(guān)元數(shù)據(jù)信息(DBSCHEMA)之前首先對(duì)數(shù)據(jù)庫(kù)進(jìn)行備份，更新 HiveMetaStore Schema、執(zhí)行啟動(dòng) Hive 即可，因?yàn)橐呀?jīng)部署了修改邏輯后的代碼部分，Hive 將以 Hive v2.1.0 在線上提供服務(wù)。

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

Ambari 接管線上 Hadoop 集群實(shí)踐

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

因?yàn)榇舜?Ambari 接管線上 Hadoop 集群動(dòng)的是我們集群或者說(shuō)是大數(shù)據(jù)平臺(tái)的最底層，影響范圍大所以每個(gè)步驟環(huán)節(jié)我們都謹(jǐn)小慎微確保無(wú)誤，防止一丁點(diǎn)的疏忽導(dǎo)致整體大數(shù)據(jù)平臺(tái)崩盤(pán)的”蝴蝶效應(yīng)”出現(xiàn)。

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

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

最后是使用在測(cè)試集群中的上線方案，選擇恰當(dāng)?shù)臅r(shí)機(jī)在線上環(huán)境完整執(zhí)行了一遍，Ambari 線上操作部分整體耗時(shí)控制在了 2h 以?xún)?nèi)，Ambari 接管后集群整體運(yùn)行正常，支撐的上層應(yīng)用無(wú)報(bào)錯(cuò)。

下面將把 Ambari 接管線上 Hadoop 集群實(shí)踐過(guò)程中的關(guān)鍵點(diǎn)著重講述，讓讀者了解接管升級(jí)實(shí)踐過(guò)程中需要關(guān)注的部分。

配置同步

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

以下圖中的 HDFS core-site.xml 配置為例，core-site.xml 配置文件是 HDFS 重要配置文件之一，可以看見(jiàn)黃色標(biāo)注部分為我們?cè)?Ambari 線上升級(jí) Hadoop HDFS 時(shí)分階段 fs.defaultFS 的不同配置：

第一步單點(diǎn)啟動(dòng)時(shí)配置保證了單 Namenode 啟動(dòng)的順利進(jìn)行，到第二步 Enable HA 時(shí)，修改為 HA 時(shí)候的必要配置。

然后對(duì)于 Hadoop 集群使用者來(lái)說(shuō)，增加了 root、hive 用戶(hù)與用戶(hù)組的訪問(wèn)也是為了兼容 Ambari 接管后的 HDFS 運(yùn)行 role 為 hdfs 用戶(hù)的訪問(wèn)兼容，當(dāng)然只有權(quán)限級(jí)別比較高的 root 和 hive 用戶(hù)能夠享有這個(gè)權(quán)限。

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

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

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

圖 11 HDFS core-site.xml 主要配置項(xiàng)

圖 12 Yarn yarn-site.xml 主要配置項(xiàng)

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

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

升級(jí)操作

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

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

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

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

圖15  Ambari 接管測(cè)試集群升級(jí)前后文件對(duì)比

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

在正式 Ambari Hive 升級(jí)之前，使用 SchemaTool 工具更新 hivemeta 庫(kù)，最后啟動(dòng) Hive。

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

圖16  線上集群升級(jí)各過(guò)程時(shí)間軸

后續(xù)運(yùn)用

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

圖17 集群組件操作界面

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

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

Ambari Web 中將監(jiān)控集群捕獲到的關(guān)鍵操作指標(biāo)值通過(guò)良好的 Widget 可視化，幫助我們?nèi)粘Ｄ軌蚩焖倥挪楹徒鉀Q問(wèn)題，在主動(dòng)預(yù)防問(wèn)題上面提高了不少效率。

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

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

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

圖20  集群管理者各角色權(quán)限表

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

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

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

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

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

然后我們根據(jù) Ambari 提供的監(jiān)控功能開(kāi)發(fā)了相應(yīng)的配套處理程序，目的在于第一使用我們自己的告警系統(tǒng)去替代 Ambari 中不太友好的告警系統(tǒng)；第二充分利用 Ambari api 不僅實(shí)現(xiàn)告警而且能夠在故障出現(xiàn)時(shí)一定程度上嘗試自動(dòng)恢復(fù)。提高我們?cè)诩罕O(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 為典型的操作指定機(jī)器 ZKFC 進(jìn)程的命令，如果 Http 動(dòng)作是 GET 則返回該進(jìn)程的狀態(tài)信息，如果是 PUT 且增加 json 請(qǐng)求內(nèi)容則是對(duì) ZKFC 的一次具體操作，從 RequestInfo 中 context 的描述可以看出是對(duì) ZKFC 的重啟操作，operation_level 描述了具體操作對(duì)象的信息屬于哪個(gè)集群哪個(gè)節(jié)點(diǎn)，以及 ZKFC 屬于 HDFS 服務(wù)的一個(gè)組件，最后 Body Host Roles 描述了 ZKFC 重啟操作后應(yīng)該屬于啟動(dòng)狀態(tài)。

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

完整邏輯圖如下：

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

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

后記

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

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

作者：陳燃

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

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