Hadoop深度运维:Apache集群原地升级Ambari-HDP

作者介绍
冯武,目前在瓜子从事大数据集群运维管理,主要负责Hadoop、Ansible、Ambari、Cloudera Manager等技术栈的维护调优工作。

公司从建设Hadoop起,采用了Apache社区版本的Hadoop,随着业务的发展,集群规模越来越来大,现已突破百余节点。

在频繁的更改配置、增删节点、监控告警等操作中,传统手工运维的弊端被放得越来越大,日常维护消耗了工程师大量的时间和精力。

现状的产生是可以理解的,公司基础架构的发展往往始于快速搭建,然后在崩溃中挣扎,最后瓶颈痛苦后经历重构。本文将介绍,我们团队如何一步一步优化Hadoop运维部署架构。

一、梳理痛点,调研并制定最优方案

1、老集群主要痛点

多个组件,HA配置,部署方案存在风险:

  • HDFS HA配置不够完善;

  • Yarn没有HA;

  • HiveServer2 / Hive MetaStore没有HA;

  • NameNode与JournalNode混合部署;

  • Zookeeper与DataNode混合部署。

哪台机器安装哪些进程,不可知:

  • 历史遗留问题,首先各机器服务安装清单不齐全,需手工维护;

  • 安装各类小工具,已不可考证。

没有机架感知(rack level)相关配置:

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

各组件的conf管理方式原始,各节点配置没有统一管理:

  • 调参,目前依赖逐台机器的con_bak方式;

  • conf没有版本控制,各worker节点可能各不相同,导致资源错配、浪费;

  • conf没法按机器分组,也没有记录维护分组的地方。

无客户端管理:

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

HDFS依赖的JournalNode仍然和NameNode混合部署:

  • NameNode主盘的IOPS已经很高了。

日常运维麻烦:

  • 重启一个进程,至少需要4步:ssh到跳板机→ssh到目标机→切换Hadoop用户→重启服务命令;

  • 滚动重启没有正规化的trigger,很难做集群级别的调参。

监控报警不全:

  • 没有Hadoop工具集的统一探针服务;

  • 人工给各组件添加prometheus collector工作压力巨大。

机器操作系统不统一:

  • 40% ubuntu;

  • 60% centos。

没有用DNS解析,需要维护/etc/hosts。

2、解决方案的思考

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

  • 方案一,采用Ansible工具进行半自动管理,经过一段时间使用,批量部署修改效率明显提升,但是配置管理等依然不方便,容易失误;

  • 方案二,先采用Ansible过渡,采用Cloudera Manager托管现Apache集群,在托管测试中发现CDH 5.x的Hadoop版本为2.6.0,而公司用的Hadoop版本为2.7.2,有大版本的跨跃,且被托管需要Hadoop降版本,这个无法实现,所以失败;

  • 方案三,先采用Ansible过渡,采用Ambari托管现Apache集群,采用HDP 2.6.5版本与现集群几乎匹配,可升级。

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命令启动Name Node就可以升级NameNode;DataNode同理,HDP启动DataNode只要配置中指向老集群的数据目录即可。如此,Apache的HDFS就可升级成HDP版本。

下图是整个集群升级前后的部署全景对比:

image

(点击图片可查看清晰大图)

下图是整个集群的操作流程:

image

(点击图片可查看清晰大图)

二、各组件升级的技术本质和挑战

升级顺序是:

Zookeeper → HDFS → Yarn → HBase

升级的通用思想是:备份老集群的元数据目录,用HDP版本的进程,使用新备份出来的元数据目录启动。如果遇到任何错误,可以迅速回滚(使用Apache版本的进程,使用老的元数据目录重启)。

备份元数据的好处是,新HDP进程启动过程中发生任何问题,不会污染老的元数据。

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

1、Zookeeper升级

1)停止Apache的zk & 安装HDP的zk(data_dir不同):

image

2)Copy zk data到HDP data_dir覆盖&同步配置文件:

image

3)启动HDP zk&下线Apache zk:

image

4)验证:如此,Zookeeper就升级完成了,同理可快速回滚。

2、HDFS升级

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

1)记录HDFS老状态,3台master节点为ubuntu系统:

image

2)停止Apache HDFS & 备份元数据。

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

image

4)新centos机器上安装HDP HDFS&同步配置文件:

image

5)拷贝Apache HDFS NameNode & JournalNode的元数据到HDP HDFS目录并覆盖:

image

6)同步配置并启动HDP JournalNode & NameNode:

image

7)安装DataNode &启动:

image

8)启动DataNode数据汇报完成,完成升级:

image

9)验证:HDFS数据上传下载测试&数据完整行校验。

3、Yarn升级

1)停止Apache Yarn &安装HDP Yarn:

image

2)同步配置&启动HDP Yarn &下线Apache Yarn:

image

3)Enalbe Yarn HA:

image

4)验证:进行简单MR / Hive / tez / Spark测试。

5)问题:怎么去兼容new / old client?

A:在升级Yarn的过程中,发现old client提交job时找不到org.Apache.Hadoop.mapreduce.v2.app.M RAppMaster,经过分析与以下两个参数有关:

  • mapreduce.framework.name

在HDP中是支持多版本mapreduce的,所以开启了这个参数用于存放多版本任务所需lib。而old client没开启这个参数导致问题,所以在server的关闭该参数。

  • **yarn.application.classpath **

该classpath在new / old classpath中不一致,(如old client由于历史原因指定了YARN_HOME的)所以考虑怎么能在启动Yarn启动container时找到$YARN_HOME呢?

  1. 在yarn-env中export $YARN_HOME;

  2. 并将该变量$YARN_HOME指向container内部yarn.nodemanager.admin-env;

  3. 将old client的lib软链接(或者copy)到new nodemanager节点相应$YARN_HOME下。

4、HBase升级

1)停止Apache HBase &安装HDP HBase:

image

2)同步配置启动HDP HBase &下线Apache HBase:

image

3)验证:进行get / put测试基本测试。

4)问题:怎样能既快速又最小影响地停止HBase呢?直接stopregionserver会产生大量的WALlog,升级启动时恢复数据容易出错,且耗时较长,grancfulstop最后region相互迁移不仅耗时长,最后也需要大量的WALlog恢复。

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

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

  • flush table刷写memstore,减少WALlog恢复。

三、收获经验

1、工作协调最关键

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

  • 提前与各使用方沟通运维窗口期,找到各业务线能达成一致的业务低峰期作为运维窗口期,把对业务的影响降到最低。我们在沟通过程中,就发生了首次协商的时间,因为部分团队没发达成一致,最后在第二次充分沟通后才找到合适的运维窗口期,使全公司数据团队达成一致;

  • 建一个“专项作战群”,不定期同步项目进度,让所有参与方感受到项目的热度;

  • 协调各Hadoop组件管理员,在升级前后,参与server端的确认和恢复工作;

  • 协调各业务方接口人,在升级前后,参与应用/服务的确认和恢复工作,保障业务快速恢复。

2、团队协作

  • 梳理整个上线运维窗口期所有操作的checklist,团队实施人员按照分工操作配合;

  • 一定要明确分工。有人负责主流程操作,有人在“专项作战群”对接业务方接口人;

  • checklist一定要多人相互review,在事前确保万无一失,避免当场遇到问题手忙脚乱。

3、压缩停机时间

本次Hadoop升级,预支了6个小时的停服窗口期。但运维中的每一项工作,仍然要不断地压缩操作时长。

1)能前置的工作尽量前置:

  • 新机器准备,新机器操作系统统一;

  • ambari-server安装& ams安装;

  • ambari集群配置文件准备。

这里着重说下Ambari集群的配置脚本化。在改为Ambari集群后,首先要把所有slave节点加入Ambari托管,再梳理老集群所有组件的所有配置,然后apply到Ambari集群上。

而在Ambari添加节点&更改每一个组件的配置,如果通过webUI逐项更改,都耗时太长。经过调研,我们将以上所有工作自动化:

  • 使用API安装组件,提升效率;

  • 使用configs.py设置配置参数,节约手动配置时间,例如在ambari-server节点上:

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

2)充分压缩单项操作的操作时长:

操作自动化。

此次升级工作中,我们采用的是Ansible自动化工具来批量执行大量操作,包括停止集群脚本、etc_hosts 配置脚本、bashrc 配置脚本、agent 刷配置脚本、测试脚本。根据需要,预先编写好playbook并在ansible-AWX中配置妥当,就可以在升级过程中一键执行。不仅省去了手工执行的时间消耗,并行执行也大大提高操作效率,压缩操作时长。

下面是playbook样例:

ambari_install/

├── group_vars

├── inventory

│ ├── ambari_agent

│ ├── ambari_bashrc

│ ├── ambari_hosts

│ ├── ambari_ln

│ └── ambari_slave

├── README.md

├── roles

│ ├── ambari_agent

│ │ └── tasks

│ │ └── main.yml

│ ├── ambari_bashrc

│ │ ├── files

│ │ │ └── bashrc_default

│ │ └── tasks

│ │ └── main.yml

│ ├── ambari_hosts

│ │ ├── files

│ │ │ ├── hosts_default

│ │ │ └── hosts_old

│ │ └── tasks

│ │ └── main.yml

│ └── ambari_ln

│ └── tasks

│ └── main.yml

└── roles.yml

配置到ansible-AWX的project/inventory/templates

image
image
image

这样就可以一键运行了。

3)尽可能并行化某些操作步骤:

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

4、多做演练

  • 从运维窗口期的前1个月开始,每周进行全流程演练;

  • 每次演练,不定时地强制要求回滚;

  • 最后一次,在公司的全局测试环境,做最后一次“演练”。

你可能感兴趣的:(Hadoop深度运维:Apache集群原地升级Ambari-HDP)