hadoop集群深度运维之--Apache升级Ambari-HDP

背景

公司从建设hadoop起，采用了apache 社区版本的hadoop，随着公司业务的发展，集群规模越来越来大，现已突破百余节点。在频繁的更改配置、增删节点、监控告警等操作中，传统的手工运维的弊端被放的越来越大，日常维护消耗了工程师的大量的时间精力。现状的产生是可以理解的，公司基础架构的发展往往始于快速搭建，然后在崩溃中挣扎，最后瓶颈痛苦后经历重构。本篇文章介绍，我们团队如何一步一步优化hadoop运维部署架构。

目录

1. 梳理老集群痛点，调研最优解决方案，制定技术方案
2. 详细介绍各组件升级的技术本质 和 挑战
3. 思考本次大型运维工作得到的经验

=====================================分割========================

1.梳理老集群痛点，调研最优解决方案，制定技术方案

1.1 老集群主要痛点

1.多个组件，HA配置，部署方案存在风险。

• hdfs HA 配置不够完善
• yarn 没有HA
• hiveserver2 / hive metastore 没有HA
• namenode 与 journalnode 混合部署
• zookeeper 与 datanode 混合部署

2.哪台机器安装哪些进程，不可知。

• 历史遗留问题，首先各机器服务安装清单不齐全，需手工维护
• 安装各类小工具，已不可考证

3.没有机架感知（rack level）相关配置。

• hdfs的持久性会经受考验，没有跨机架的3副本。

4.各组件的conf管理方式原始，各节点配置没有统一管理。

• 调参，目前依赖逐台机器的con_bak方式。
• conf没有版本控制，各worker节点可能各不相同。导致资源错配，浪费。
• conf 没法按机器分组，也没有记录维护分组的地方。

5.无客户端管理。

• 客户端如果管理不到位。影响admin做大部分的参数调优，部署调整。严重影响hadoop的可维护性。

6.hdfs 依赖的 journalnode 仍然 和 namenode混合部署。

• namenode主盘的iops已经很高了。

7.日常运维麻烦。

• 重启一个进程，至少需要4步：1.ssh到跳板机 2.ssh到目标机 3.切换hadoop用户 4.重启服务命令。
• 滚动重启没有正规化的trigger，很难做集群级别的调参。

8.监控报警不全。

• 没有hadoop工具集的统一探针服务
• 人工给各组件添加prometheus collector工作压力巨大

9.机器操作系统不统一

• 40% ubuntu
• 60% centos

10.没有用dns解析，需要维护/etc/hosts

1.2 思考解决方案

为了一次性解决以上尽可能的多的痛点，不得不思考跳出手工运维的大坑。我们整理出了三种方案：

• 方案一，采用ansible 工具进行半自动管理，经过一段时间使用，批量部署修改效率明显提升，但是配置管理等依然不方便，容易失误；
• 方案二，先采用ansible过渡，采用cloudera manager托管现apache集群，在托管测试中发现cdh5.x的hadoop版本为2.6.0 而公司用的hadoop版本为2.7.2，有大版本的跨跃，且被托管需要hadoop降版本，这个无法实现，所以失败；
• 方案三，先采用ansible过渡，采用ambari托管现apache集群，采用hdp 2.6.5版本与现集群几乎匹配，可升级。

1.3 我们的选择

平台升级一般有2种大的选择：

第一种是原地升级即直接在原有平台上操作，该办法操作效率较高，马上看到效果，但往往风险较高，比如升级失败回滚方案不完善，可能HDFS还有丢数据的风险；

第二种是拷贝数据的方式升级，需要额外的服务器资源，需要新搭平台，然后把旧的平台的数据拷贝过去，数据拷贝完毕后，再把旧集群的机器下线了慢慢加入到新集群，该方法一般实施周期较长，但是风险较小。

根据实际情况（成本/可行性分析）考虑，最后选择方案三：apache集群原地升级ambari-hdp

原地升级该怎么做？主要有以下思考：

第一，升级的重中之重是hdfs，只要hdfs完成托管且数据不丢失，其他组件yarn、hbase就能水到渠成，这样我们主要精力放到hdfs的升级上面。

第二， apache集群的hdfs版本为2.7.2，hdp的为2.7.3，namenode元数据的结构是一致的。

第三，hdp 版本和 Apache的解析数据的方式、原理是一样的，只有进程启动的方式、配置文件的目录不一样。

所以只要把apache hdfs的元数据拷贝到hdp的元数据目录，然后用hdp命令启动namenode就可以升级namenode；datanode同理，hdp启动datanode只要配置中指向老集群的数据目录即可。如此，apache的hdfs就可升级成hdp版本。

下图介绍整个集群升级前后 部署全景 对比：

下图介绍整个集群的操作流程：

2.详细介绍各组件升级的技术本质 和 挑战

升级顺序是：zk-> hdfs->yarn->hbase

升级的通用思想是：备份老集群的 元数据目录，用hdp版本的进程，使用新备份出来的元数据目录启动。 如果遇到任何错误，可以迅速回滚（使用apache版本的进程，使用老的 元数据目录重启）。 备份元数据的好处是，新hdp进程启动过程中发生任何问题，不会污染老的元数据。

每个组件在升级过程中，都有一些特殊的难点，分别阐述：

2.1 ZOOKEEPER升级

1.停止apache的zk & 安装hdp的zk（data_dir 不同）

2.copy zk data 到hdp data_dir 覆盖 & 同步配置文件

3.启动hdp zk & 下线apache zk

4.验证

如此，zookeeper就升级完成，同理可快速回滚。

2.2 HDFS升级

hdfs 的三台管理节点操作系统是ubuntu，不能直接升级，这里预备了用于替换的centos 机器，在安装hdp hdfs时，需要先切换hostname +ip 到新centos系统的机器进行安装。

1. 记录hdfs老状态，3台master节点为ubuntu系统

2.停止apache hdfs & 备份元数据

3.准备centos新机器 & 切换hostname+IP

4.新centos机器上安装hdp hdfs & 同步配置文件

5.拷贝apache hdfs namenode & journalnode 的元数据到hdp hdfs目录并覆盖

6.同步配置并启动hdp journalnode & namenode

7.安装datanode & 启动

8.启动datanode数据汇报完成，完成升级

9.验证

hdfs 数据上传下载测试& 数据完整行校验

2.3 YARN 升级

1.停止apache yarn & 安装hdp yarn

2.同步配置 & 启动hdp yarn & 下线apache yarn

3.enalbe yarn HA

4.验证

进行简单MR/hive/tez/spark测试

5.问题

Q1:怎么去兼容new / old client？

A1:在升级yarn的过程中，发现old client 提交job时找不到 org.apache.hadoop.mapreduce.v2.app.MRAppMaster，经过分析与以下两个参数有关
mapreduce.framework.name
在hdp中是支持多版本mapreduce的，所以开启了这个参数用于存放多版本任务所需lib。而old client没开启这个参数导致问题，所以在server的关闭该参数。

yarn.application.classpath
该classpath在new / old classpath 中不一致（如old client 由于历史原因指定了$YARN_HOME，但是在hdp中是没有的$YARN_HOME），所以考虑怎么能在启动yarn启动container时找到$YARN_HOME呢？
a.在yarn-env中export $YARN_HOME
b.并将该变量 $YARN_HOME指向container内部yarn.nodemanager.admin-env
c.将old client的lib 软链接（或者copy）到new nodemanager节点相应 $YARN_HOME下

2.4 HBASE 升级

1.停止apache hbase & 安装hdp hbase

2.同步配置启动 hdp hbase & 下线apache hbase

3.验证

进行get /put 测试基本测试

4.问题

Q1:怎么样能即 快速 又 最小影响的停止hbase呢？ 直接stop regionserver 会产生大量的WAL log，升级启动时恢复数据容易出错，且耗时较长，grancful stop 最后region相互迁移不仅耗时长也最后也需要大量的WAL log恢复。

A：停机时，保证不产生额外的WAL，且保证速度。

1.disable table 来停止继续写入数据,等升级完成后enble table 恢复写入。由于disable_all 执行效率低，建议采取了多进程的方式并行disable table

2.flush table 刷写memstore，减少WAL log恢复

3 思考本次大型运维工作得到的经验

3.1 工作协调是最关键的

本次hadoop升级，涉及到shutdown整个集群。意味着全公司的所有大数据pipelien都会经历一次停止/启动。要规划好全公司所有大数据工程师的一致行动，是很有挑战的一件事情。有一些经验总结：

• 提前与各使用方沟通运维窗口期，找到各业务线能达成一致的业务低峰期端作为运维窗口期，把对业务的影响降到最低。我们在沟通的过程中，就发生了首次协商的时间，因为部分团队没发达成一致，最后再第二次充分沟通后才找到合适的运维窗口期，使全公司数据团队达成一致。
• 建议《专项作战群》。不定期同步项目进度。让所有参与方感受到项目的热度。
• 协调各hadoop组件管理员， 在升级前后，参与server端的确认和恢复工作。
• 协调各业务方接口人，在升级前后，参与应用/服务的确认和恢复工作，保障业务快速恢复。

3.2 团队协作

• 梳理整个上线运维窗口期 所有操作的check list , 团队实施人员按照分工操作配合。
• 一定要明确分工。 有人负责主流程操作，有人在《专项作战群》对接 业务方接口人。
• checklist一定要多人相互review，在事前确保万无一失，避免当场遇到问题 手忙脚乱。

3.3 压缩停机时间

本次hadoop升级，预支了6个小时的停服窗口期。但运维中的每一项工作，仍然要不断的压缩操作时长。1.能前置的工作尽量前置 2.充分压缩单项操作的操作时长 3.尽可能并行化 某些操作步骤。

3.3.1 能前置的工作尽量前置

• 新机器准备，新机器操作系统统一
• ambari-server 安装 & ams安装
• ambari集群配置文件准备

这里着重说下 ambari集群的配置脚本化。 在改为ambari集群后，首先要 1.把所有slave节点加入ambari托管。2. 梳理老集群所有组件的所有配置，然后apply到ambari集群上。而在ambari添加节点 & 更改每一个组件的配置，如果通过webUI逐项更改，都耗时太长。经过调研，我们将以上所有工作自动化：

1. 使用API安装组件，提升效率
2. 使用configs.py设置配置参数，节约手动配置时间，例如在ambari-server 节点上：

python  /var/lib/ambari-server/resources/scripts/configs.py  -n $cluster -l $hostname -c hadoop-env  -a set   -f hadoop-env.json

3.3.2 充分压缩单项操作的操作时长

• 操作脚本化 & ansible。包括停止集群脚本、etc_hosts 配置脚本、bashrc 配置脚本、agent 刷配置脚本、测试脚本化

3.3.3 尽可能并行化 某些操作步骤。

不同的人负责执行不同的脚本

3.4 多做演练

1. 从运维窗口期的前1个月开始，每周进行全流程演练。
2. 每次演练，不定时的强制要求回滚。
3. 最后一次，在公司的 全局测试环境 ，做最后一次“演练”。

=================================================================

打个广告，guazi大数据团队持续招聘大数据人才，感兴趣的同学可以私信我 或 @汪涉洋 私聊。