【51CTO.com原创稿件】本文首先将简要介绍我们生产环境中 Hadoop 集群现状、Ambari 的关键技术，然后将重点阐述我们 Ambari 管理监控线上 Hadoop 集群的技术方案，介绍线上接管过程中碰见的问题和解决方式。
公司在保持游戏事业快速增长的同时也认识到数据的重要性，在大数据规划层面，为了快速加强我司的游戏数据整合能力、分析能力与行动能力，我们已经在 2014 年年底启动，结合成本、效率等多种因素选用 Apache 开源的 Hadoop 技术。
最初以 Hadoop v2.2.0 社区版搭建以其为核心的集群，结合自研的作业编排、数据调度等系统，打造了满足游戏业务中包括平台运营、广告投放等数据的收集、分析与挖掘需要的大数据平台。
然而，随着公司游戏事业在国内、海外，页游、手游布局的扩大，支撑公司在游戏发行与游戏研发方面不断增长的数据资源与服务的集群规模也在不停增长。
Hadoop 游戏数据集群承载着游戏发行与游戏研发中主要包括用户行为数据、平台运营数据等数据的多方采集、处理与分析，为公司游戏发行各环节提供有力的数据保障。
目前 Hadoop 游戏数据集群规模已经发展到上百节点，集群的计算能力支撑着 TB 级别的日增数据量，以及上万次作业的处理规模。
但无论是我们的日常集群管理与监控，还是 2016 年对集群从 v2.2.0 至 v2.7.3 的线上升级，我们发现对集群的管理上都不够系统与全面，集群运维不够简便与智能。
主要有以下不足：
- 集群中资源的安装、扩容、升级不方便，特别是资源组件间的依赖配置管理难。
- 集群中各个 Service 缺少统一的集群整体监控，往往只能通过查单 Host 机器性能指标辅助排查问题和性能调优，导致效率低下。
- 集群资源各个 Component 的监控，无法充分利用其 Metrics 指标，基于时间序进行统一的健康观察，排查稳定性难。
- 平台整合现有集群监控运维工具难，也缺乏直观的用户界面，不方便有效地查勘平台的信息和进行管理。
因此 2017 年我们经过调研与测试业界主流的一些统一的平台管理方案，目标是提高集群的稳定性、易管理性、安全性，在对 CDH、Ambari 等作竞品分析后，我们选择了 Ambari 这个 Hortonworks 贡献给 Apache 的顶级开源项目。
选择的原因总体来说主要有：
- Ambari 是 Hortonworks 贡献给 Apache 开源社区的顶级项目，属于 Hadoop 生态中的重要组成部分，Hortonworks 本身也提供一些基于 ApacheHadoop 开发良好的商业应用组件，例如 HDP 数据平台。
- Ambari 不仅整合了常用的运维管理工具，更重要的本身专注于 Hadoop 集群管理方案，所以它的优势就在于 Hadoop 集群的供应、管理和监控等，最能解决我们的需求痛点。
- Ambari 基于 Web 的特点能够直现给使用者直观用户界面，能够极大提升管理效率和降低本身开发成本。
因此，我们基于 Ambari 摸索了一套接管线上 Hadoop 集群(下文中 Hadoop 游戏数据集群将简称为 Hadoop 集群)的技术方案并成功实践之，如同 Ambari 从零供应一个集群一样，将基于 Web 的 Ambari 充分利用在了对集群的管理与监控上。
生产环境中 Hadoop 集群现状
首先介绍我们生产环境中 Hadoop 集群的现状，Hadoop 集群主要承担了数据接入存储、离线计算的职责，同时提供其上数据调度等自研系统的基础服务。生产环境中 Hadoop 使用的版本是 v2.7.3，下面介绍其主要组件。
首先 HDFS 采用了 HA with QJM 的高可用架构，即采用 Standby Namenode 热备、多节点协同同步 Active/Standby Namenodes(不同物理机器)之间元数据日志的方式，降低之前单点 Namenode 因为故障而导致的集群服务不可用的时间，提高集群的可用性。
并且如下图中，Active/StandBy Namenode 节点各自运行了基于 Zookeeper 集群自动监控 Namenodes 状态、自动选举保证集群 Namenode 只有一个处于 Active 状态的 ZKFailoverController。
图 1 HDFS HA with QJM
接着是用于集群资源分配与作业调度的 Yarn 框架，我们采用了 Yarn 的 FairScheduler 公平调度策略，并且根据不同业务线集群使用成本投入占比，划分了作业执行队列以及队列使用的资源池，各个资源池合理定义了最大同时运行作业数、Min/Max 可参与分配的资源(Vcore 数、mem 大小)、动态竞争其他空闲队列资源池资源权重等参数。
除开业务线使用的各队列之外，还定义了 Default 的共享作业队列，分配其较小的资源用于保证其他一些例如集群数据的共享查询等应用。
图 2 YARN FairScheduler 资源分配图
集群 ETL 离线作业处理与数据查询我们主要基于 Hive，Hive 是 SQL on Hadoop 的数据仓库工具，具备良好的类似以关系型数据库的方式存储管理接入数据、提供对外数据处理接口特性，以 Hive 为基础我们打造了大数据中心，安全、简洁、便捷地统一接入数据以及对外统一提供数据处理基础服务。
并且在发展过程中，为了提高数据中心服务水平，我们将 Hive 版本升级至 v2.1，其 HiveServer2 服务能够更好支持并发和身份认证以及开放 API 客户端(如 ODBC 和 JDBC)，且其更好支持内存计算(TEZ+LLAP)也为后续升级提供了基础。
图3 Hive 2.1 应用架构图
除开上述主要介绍的 Hadoop 集群中组件应用之外，我们还有包括 Flume+Kafka 分布式日志采集与队列数据分发的完整数据流架构，该架构使用 Zookeeper 集群做协同服务和配置管理，在这里不一一赘述。
最后是 Hadoop 集群原有的监控和告警逻辑，在进程监控这块我们采用 Crontab 周期性从主控节点 ssh 至集群每个节点，轮询检查每个主要进程的运行状况，一旦发现进程挂掉则告警且重新启动；在性能监控这块(例如 Yarn 任务堆积数)我们也是采用 Crontab 周期性的调组件监控接口获取相关 Mertrics 数值，告警异常值的方式。
至此我们已经梳理完毕生产环境中 Hadoop 集群现状，其上支撑的业务之广、使用人之多，就决定了我们 Ambari 线上接管集群不容有失，且需要最大限度降低接管过程中对业务造成的影响。
Ambari 相关技术介绍
接下来我们将简单介绍 Apache Ambari 相关技术，Ambari 是 Hortonworks 贡献给 Apache 开源管理 Hadoop 集群的顶级开源项目上文已提及，主要用于 Hadoop 集群的部署、监控与告警，Ambari 整体架构如下图，主要由 5 部分组成：
图 4 Ambari 整体架构图
- Ambari Web: 用户交互界面，通过 HTTP 发送使用 Rest Api 与 Ambari Server 进行交互。
- Ambari Server: Web 服务器，用于和 Web、Agent 进行交互并且包含了 Agent 的所有控制逻辑，Server 产生的数据存储在 DB 中。
- Ambari Agent: 守护进程，主要包含节点状态与执行结果信息汇报 Server 以及接受 Server 操作命令的两个消息队列。
- Host: 安装实际大数据服务组件的物理机器，每台机器都有 Ambari Agent 服务与 Metrics Monitor 守护进程服务。
- Metrcis Collector: 主要包括将 Metrics Monitor 汇报的监控信息存储到 Hbase，以及提供给 Ambari Server 的查询接口。
- Ambari 整体管理集群方面以 Ambari Server 为核心，维护着一个 FSM 有限状态机，包含平台中所有部署 Agent 并注册的节点、部署的服务与组件的状态变化信息、配置文件并且持久化在 Ambari Server 端的 DB 中。
对外一方面通过 rest Api 接口方式与 Ambari Web 交互，一方面接受来自 Agent 的定时心跳请求，所有交互信息中包含了节点状态、事件信息、动作命令中其中至少一种，由 Ambari Server 统一协调命令和维护状态结果，然后给 Agent 下发的相关 command，Ambari Agent 接受命令执行相关逻辑并返回状态结果。
Ambari 整体监控方面通过 Ambari Server 获取 Ambari Metrics Collector 中聚集后的从各个节点 Ambari Metrics Monitor 上报的单节点监控指标数据，在 Ambari Web 中给出图形化的展示。
Ambari 是 HDP 数据平台套件的一部分，HDP 是 Ambari 管理集群的技术栈基础。HDP 即 Hortonworks Data Platform，是 Hortonworks 完全开源以 Yarn 为核心整合 Apache Hadoop 技术的一个安全的企业级数据平台，HDP 涵盖了几乎所有 Hadoop 的数据离线处理技术，以及最新的实时处理技术满足用户需求，如下图所示，其 2017 年开源的 HDP v2.6 正好支持 Hadoop v2.7.3。
图 5 HDP 数据平台技术涵盖
Ambari 支持对 HDP 的供应或者说 Ambari 基于 HDP 数据平台，下面是几个核心概念：
- Stack：Ambari 支持管理的 HDP 整个技术栈，本身技术栈也有版本区分，例如 HDP 2.6 就是 Hortonworks 基于 Apache Hadoop v2.7.3 与 Apache 协议的 2017 年发行版。
- Service：Ambari 支持管理的某个具体服务，比如 HDP 中的 HDFS、Yarn 等，可以部署、管控的一个完整 Framework 技术方案。
- Component：Ambari 支持管理的最小组件单位，由于 Service 服务大多数为分布式应用，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 集群提供服务的影响。
问题描述
围绕上述这两方面，首先我们梳理了集群上支撑系统的所有使用接口，包括调度系统中使用的 HDFS RestApi，数据中心使用的 Hive Jdbc、ThriftApi，实时采集和分发系统使用的 Zookeeper 服务。
其中涉及到的主要技术组件例如 HDFS、Hive、Zookeeper，HDP 中各组件的版本应该向下兼容最好版本一致(Hadoop v2.7.3、Hive 2.1.0 等等)，保证功能特性满足。
根据 HDP 提供的组件信息，我们选择了 HDP v2.6.0.2，并且针对 HDP v2.6 对其包含的组件功能特性与社区版各组件功能特性进行对比，确保了 HDP v2.6.0.2 支持现有所有功能特性。
然后是支持 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 版本对比
从上面的对比图中可以发现，Ambari 是支持管理大多数与线上集群组件版本一致的组件的。
但是也有例外，例如 Hive，Ambari 支持管理的版本比线上集群中的低，而我们生产环境中数据中心等上层应用都是基于 Hive 2.1.0 接口运行的。
所以 Ambari 接管线上集群不得不解决Hive的兼容性问题，才能最终达到 Ambari 管理为我们所用的生产集群的目标。
接着需要考虑的是 Ambari 自动供应的 HDP 集群怎样与线上 Hadoop 集群兼容，就拿其中比较重要的一个必要条件来说：接管后的 HDP HDFS 能够唯一管理线上已有集群数据，而要能够顺利实现这一目标就得 Ambari 管理的 HDP 能够代替原有 Hadoop 集群。
所以 Ambari 接管线上集群的问题就转化成了集群升级的问题，升级问题要考虑的是最小化停机的影响以及能够回滚恢复，以及充分利用 Ambari 的特性。
解决思路
现在已经了解到了此次 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 执行逻辑，完整的一次交互是用户在 Ambari Web 界面操作 -> Ambari Server 请求处理&命令下发具体机器 -> 具体机器 Ambari Agent 执行相关操作，而在这里 Ambari Agent 启动 Hive(实际分为 HiveMetaStore、HiveServer、HiveClient 等 Component，每个 Component 启动执行逻辑一致，故在这里统一称为启动 hive)过程包括了解析下发命令、从 DB 拉取配置信息、更新配置文件、启动 Hive。
因为配置文件对于各个 Hive 中 Component 一致，所以更新配置文件的执行逻辑也一致，并且 hive2 是能够向下兼容 hive 中的所有配置项的，因此在更新 hive 配置文件的逻辑最后增加同步配置至 hive2 配置的功能，就实现了在 Ambari Web 页面也能够更新本不支持的 hive2 的配置了，并且因为 Ambari 有自定义配置项功能支持所以也不用担心 hive2 配置项 hive 中不支持的问题。
图 8 hive 更新配置增加同步至 hive2 功能
配置支持的问题解决了，然后是 Hive 启动的问题，启动逻辑更加简单即默认以 hive/bin 目录下启动脚本启动相关组件之前会尝试去获取机器的 HIVE_HOME 系统环境变量，所以在节点提前配置 hive2 的相关系统环境变量，则启动逻辑会以 hive2/bin 目录下的启动脚本启动相关组件，同样的关闭、重启等逻辑也会按照 hive2 的逻辑执行。
至此通过类似”移花接木”的方式实现了 Ambari 管理 Hive v2.1.0 的目标，即在 Ambari Web 页面上的管理操作的生效对象为 HDP Hive2 即 Hive v2.1.0。
接着是 Ambari 接管线上集群如何转化成线上升级，集群升级中的要点包括：旧版本元数据的备份(Namenode、Journalnodes 等)，旧版本配置在新版本配置的覆盖和调优，可能升级失败的回滚方案准备，实施升级时段选在集群使用空闲时间，升级前的演练等。
这些方案此次 Ambari 接管线上集群升级同样受用，但是同时也要考虑一些特殊的细节：第一，Ambari 支持的 Hadoop 集群供应并没有直接 HA with QJM 的方案，在 HDFS 部署时必须按照 SNN 冷备方案部署然后调整为 HA with QJM 的步骤。
第二，集群中的 Zookeeper 服务支持的一些实时型业务就决定了 Zookeeper 服务不能与 Hadoop 升级那样需要停机而造成服务不可用的空窗期。
第三，Ambari 管理的组件程序运行 role 与现有组件程序运行 role 的不同导致的主要包括文件权限等问题，以及由于此前 Hadoop 集群经历过节点扩容、节点配置个性化差异如何在 Ambari 统一配置管理中避免冲突的问题。
而且我们需要保证的目标包括了：
- 架构上与原有集群一致，比如 nn 节点、dn 节点的分布等，尽可能与原有集群组件机器分配一致。
- 升级最重要的是我们的数据资产，数据不能丢，所以重要配置比如 hdfs 各存储日志文件目录、索引文件目录等等必须一致。
- 再就是各组件重要参数，比如服务命名空间、文件块大小、资源调度策略等等，也要尽可能一致。
所以综上所述，我们将 Ambari 接管线上集群升级拆分为下面几大步骤：
图9 Ambari 接管线上集群升级步骤
在升级前的准备部分中将把所有的相关资源提前部署以及配置好，线上升级操作部分中只操作 Ambari 启动相关组件，完成线上集群运行组件的替换，所以集群停机影响时间缩短至 Hadoop、Hive 相关启动的时间，最大化减小了停机的影响。
升级前准备工作主要分为两个部分：第一，按照 Ambari 官网提供的部署方式部署并启动 Ambari 各组件，然后在 Ambari Web 上按照 Ambari Cluster Install Wizard 并且根据线上现有集群的组件分布，选择相应 HDP 组件的部署节点，确保将 HDP 各组件部署节点与线上集群各组件运行节点保持一致后，Ambari 将会在各节点 Install HDP 的各组件，最后由于节点已有运行组件的端口冲突会导致 Start 失败，不过不影响 Ambari 成功完成部署 HDP 各组件。
第二，Ambari 线上升级前环境准备首先最重要的是与现有集群的配置同步，同样在 Ambari Web 界面中操作，这里需要注意的是现有集群不同节点的差异化配置在 Ambari 中使用 Config Group 同样进行差异化配置，比如集群中 DataNode 机器节点在磁盘上的差异情况，在 Ambari 中配置不同节点组对应的配置如下图：
图10 不同 DataNode 节点组 Blocks 目录差异化配置
依次对 Hadoop、Hive 等组件完成配置同步；接着是准备所有执行逻辑脚本，包括刚才提到的涉及到功能修改的相关 Ambari Agent python 功能脚本以及升级上线操作时的包括备份 NN、JN 元数据、统一修改系统环境变量等命令脚本，至此升级前的所有准备工作全部完成。
线上升级操作部分也分为两部分：
第一，Ambari 线上升级 Hadoop，首先是 Zookeeper 集群的升级，采用从 Zookeeper 的 follower 机器开始一台一台停掉线上、Ambari 启动相应节点，因为在配置同步过，所以 Ambari 启动的 zk 是读取原有 zk 的数据，待所有 follower 节点操作完毕之后操作 leader 节点。
然后是 Hadoop 的升级，Hadoop 升级前暂时关闭所有程序访问入口(提前公告通知)，Hadoop 升级中最重要的是 Hdfs 的升级。Hdfs 的升级分为 SNN 冷备方案 HDFS 启动与 Enable HA with QJM 两步：
- 第一步让原有集群进入安全模式确保没有数据写入时，备份所有 Namenode、Journalnode 节点元数据，执行关闭集群脚本在确保 Hadoop 组件全部关闭后执行修改所有节点系统环境变量脚本(修改为新 HDP 集群的系统环境变量)。
根据 Ambari 中提示启动 HDFS，由于 Namenode 重启需要一定时间(在这里不介绍 Namenode 重启优化了)，等待集群 check blocks 直至自动退出安全模式后至此 SNN 冷备方案的 HDFS 正式启动成功。
- 第二步在 Ambari 中操作 Enbale HA with QJM，每一步的操作根据操作指南即可，需要注意的是过程当中可能会出现原有的 Stand By Namenode 元数据缺少因为第一步中单 Namenode 运行过程中产生的部分元数据，可以同步 Namenode 中 fsimage 与 editLog 文件至 Stand By Namenode 并重新 initializeShareEdits。
正常情况下在 Enable HA 最后 Ambari 又会重启一次 HDFS，重启完成之后至此 HDFS 升级完毕，依次启动 Mapreduce2、Yarn 服务，整体 Hadoop 升级完毕。
第二，Ambari 线上升级 Hive，在第一部分 Hadoop 成功升级后相对来说 Hive 的升级比较容易，在更新 Hive Metastore 中相关元数据信息(DBSCHEMA)之前首先对数据库进行备份，更新 HiveMetaStore Schema、执行启动 Hive 即可，因为已经部署了修改逻辑后的代码部分，Hive 将以 Hive v2.1.0 在线上提供服务。
上面四大步骤顺利完成之后，Ambari 就成功接管了线上集群，集群支撑的上层服务可以开放入口给使用者使用了。后续围绕 Ambari 的监控功能，使用其 api 接口可以定制各种个性化的监控和告警服务，至此 Ambari 成功接管线上集群。
Ambari 接管线上 Hadoop 集群实践
上文中想必读者已经了解了我们 Ambari 实践最终想要达到的目标，其中存在的主要问题以及问题解决的思路，现在我们介绍 Ambari 接管线上 Hadoop 集群的实践过程。
因为此次 Ambari 接管线上 Hadoop 集群动的是我们集群或者说是大数据平台的最底层，影响范围大所以每个步骤环节我们都谨小慎微确保无误，防止一丁点的疏忽导致整体大数据平台崩盘的”蝴蝶效应”出现。
所以我们从开发集群开始，目标是在使用 Ambari 从零搭建集群过程中，了解其核心特性和对机器运行环境的所有依赖；然后是在我们 Hadoop 测试集群上，Hadoop 测试集群不仅有与生产 Hadoop 集群同样的环境与配置，并且也支撑着同样的用于测试目的的上层应用系统。
在灰度集群上我们按照上文中四步骤完整演练了较多次，总结了一些其中碰见的问题和应急解决方案，除开节点规模和数据量比不上线上 Hadoop 集群之外，升级方案方面已经确定。
最后是使用在测试集群中的上线方案，选择恰当的时机在线上环境完整执行了一遍，Ambari 线上操作部分整体耗时控制在了 2h 以内，Ambari 接管后集群整体运行正常，支撑的上层应用无报错。
下面将把 Ambari 接管线上 Hadoop 集群实践过程中的关键点着重讲述，让读者了解接管升级实践过程中需要关注的部分。
配置同步
Ambari 接管的目标是对于集群使用者来说感受不到集群本身的变化，所以能否接管线上集群的关键点之一在于集群配置的同步，准确点是说 Ambari 使用的 HDP 中各个 Component 组件系统参数、应用参数、运行时环境变量等都需要保持一致，下面将介绍几个主要配置文件中的重要配置项。
以下图中的 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 运行的最大内存大小等参数，Ambari 默认的都比较小，这一点需要特别注意根据原有集群的运行 Namenode 进程运行时内存参数来调节这些参数。
然后再来看看 Yarn 相关的配置项，我们以 yarn-site.xml 配置文件中主要配置项为例：橙色标注的部分为需要根据原有集群做调整的部分，其中包括需要根据具体节点内存大小情况来合理选择 NodeManager 可用于分配的最大内存，增加 mapreduce_shuffle 选项以支持集群中的 MapReduce 程序。
当然还有 Yarn 的调度策略，在生产集群环境介绍中已提到使用的是根据业务划分的 FairScheduler，而 Ambari 中默认使用的是 Capacity Scheduler，所以需要特别注意调度策略以及相关的配置与原有保持一致。
图 11 HDFS core-site.xml 主要配置项
图 12 Yarn yarn-site.xml 主要配置项
最后是一些组件的数据存储路径的配置，Ambari 能够接管线上集群，必须 HDP 各组件使用之前的数据来保证，所以数据存储路径的配置也是至关重要的。
图 13 主要组件的主要数据存储路径配置项
升级操作
在升级操作前，我们会关闭所有访问集群的应用入口，特别是集群数据接入与定时作业这一块，保证集群没有数据继续写入后，我们接着关闭所有之前的集群进程运维监控脚本，防止升级过程中原有集群组件进程运行的恢复影响升级。
接着为了方便在 Namenode 统一执行关闭集群操作，我们根据关停脚本的逻辑即各节点会找到存放对应进程(Datanode、NodeManager)PID 文件路径，根据文件记录的 PID 执行 Kill 操作。
但是由于部分 PID 文件存放在系统 tmp 文件夹下可能已经被删除，所以我们提前在各个节点部署了检查各自运行进程并还原可能缺失的 PID 文件的脚本，并且在正式关停前，统一执行还原进程 PID 文件，NN、JN 节点元数据文件信息备份后才执行关停操作。
然后在 Ambari 升级 Hadoop 之前，我们通过 Hdfs 管理界面记录系统的元数据信息，并且在 Ambari 完成整体 Hadoop 升级后，我们详细对比了 Hdfs 记录的元数据信息(下图中选择的为 Ambari 接管测试集群的统计数据)：
图15 Ambari 接管测试集群升级前后文件对比
在确定升级前后 Blocks 完全一致后，整体 Hadoop 升级确认完成。最后是 Ambari 升级 Hive，在步骤 2 集群关停操作完成之后，我们同步进行了 Hive MetaStore DB 的备份，因为 HiveMetaStore DB 只存储 Hive 相关元数据信息，所以 hivemeta DB 本身不大，备份起来速度也较快。
在正式 Ambari Hive 升级之前，使用 SchemaTool 工具更新 hivemeta 库，最后启动 Hive。
我们在 Hadoop 与 Hive 升级启动完毕之后，我们迅速使用命令脚本模拟包括调度系统、数据中心等线上系统访问集群，测试新上线集群对外接口的可用性，确保测试都通过后，我们正式开放了各个上层应用，至此整体的上线时间耗时控制在了 2h 以内，整体升级操作时间轴如下：
图16 线上集群升级各过程时间轴
后续运用
Ambari 接管线上集群后，在 Ambari Web 中可以对集群中所有组件进行统一管理：
图17 集群组件操作界面
上图中为集群中组件列表，以 HDFS 为例，对于 HDFS 的操作列表中包括了对 NameNode、DataNode、JournalNode 等的常用操作，通过界面即可统一操作。
统一配置管理将不同的配置文件分类给出，使用者根据相应的配置项属性名填写属性值同步即可，用户可自定义配置项，配置同步后有历史版本概念，多版本之间可以对比。
Ambari Web 中将监控集群捕获到的关键操作指标值通过良好的 Widget 可视化，帮助我们日常能够快速排查和解决问题，在主动预防问题上面提高了不少效率。
例如我们通过观察 Yarn Pending Apps 的个数，发现堆积比较严重的时段后，会合理去调整作业的执行时间；通过观察集群整体 CPU 与内存的利用率，可以快速定位集群计算能力的瓶颈即 CPU 使用率较高但是内存使用率相对较低，然后我们会合理调整 Yarn 中 Container 对于 CPU 利用的策略等。
图19 监控指标值可视化
由于我们可以在统一的 Ambari Web 界面中对集群组件进行操作、配置管理，基于 Ambari 集群统一管理特性标准与规范化了集群的运维管理操作，相应的操作例如增加删除节点、组件迁移、配置修改等，都有明确的权限范围以及完整的操作历史记录，并且将 Ambari 所有使用者入口做统一管理，公司内部相关人员只能在权限范围内对集群进行有迹可循的操作。
图20 集群管理者各角色权限表
如上表将对于集群的运维管理操作角色权限分成四个 Level，最低的 Level 是能够在 Ambari Web 中查看集群的运行状态、配置、告警等信息。
但是对于集群没有任何的操作权限，此类权限开放给所有需要对集群运行健康状态有关注的集群使用者，例如可以在 Tez View 中查看自己的作业运行情况，在 Yarn 管理界面中查看负载等等。
然后在针对集群可操作人群，同样划分了操作组件级别、集群整体级别两个 Level，一般的集群运维人员可以去管理其中组件、进行调优，而上升到集群统筹规划这一层面，则需要对整体架构熟知的集群架构人员去管理。
最后超级管理员除开上述所有权限之外，多了一层 Ambari 本身系统级别的管理。
管理权限按层级划分，既能够满足不同集群使用者的要求，同样也保护了集群的运行安全和稳定。
然后我们根据 Ambari 提供的监控功能开发了相应的配套处理程序，目的在于第一使用我们自己的告警系统去替代 Ambari 中不太友好的告警系统；第二充分利用 Ambari api 不仅实现告警而且能够在故障出现时一定程度上尝试自动恢复。提高我们在集群监控、管理方面的效率。
首先 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 则返回该进程的状态信息，如果是 PUT 且增加 json 请求内容则是对 ZKFC 的一次具体操作，从 RequestInfo 中 context 的描述可以看出是对 ZKFC 的重启操作，operation_level 描述了具体操作对象的信息属于哪个集群哪个节点，以及 ZKFC 属于 HDFS 服务的一个组件，最后 Body Host Roles 描述了 ZKFC 重启操作后应该属于启动状态。
介绍完了 Ambari 中的操作 API，我们利用 api 的特性设计了一套完整的自动发现组件疑似严重错误、确认错误并告警、尝试恢复的功能配件。
完整逻辑图如下：
定期扫描 dm_monitor_info，Ambari 中定义的告警项的周期扫描状态，发现组件存在的最近一次的隐患，确认组件是否真正处于服务不可用的状态(可能是集群在维护即 maintainance_state=‘ON’)后，记录该次告警信息，周期性尝试自动恢复正常之前告警系统报告消息，直到恢复后最后一次向告警系统报告成功恢复消息后，消除此次告警信息。
根据上线后运行近半年的统计，累计自动恢复组件时间分布如下图，Ambari 中最小扫描周期为一分钟，所以按照分钟级别的扫描出疑似组件问题与自动恢复的平均时间在五分钟之内，且绝大多数故障恢复在一分钟，大大提高了组件的服务可用性。
后记
在 Ambari 接管线上集群后已经稳定运行了半年之久，它帮助我们大大提高了集群管理、监控方面的效率，在帮助我们性能排查、科学调优方面给了很大的帮助。
当然 Ambari 管理与监控集群只是大数据平台基础建设的第一步，在智能化、企业级大数据平台基础建设过程中，我们会利用其提供的 HDP 平台服务不断提高大数据平台基础服务水平。
作者：陈燃
简介：硕士，三七互娱大数据开发工程师，一直专注于围绕 Hadoop 为主的大数据平台研发工作。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
