背景
当前现状
当前的Ambari自身仍然不支持版本的升级,所以下一个版本NDP-3.3.0该如何升级存在着疑问:
- 比如说当前的NDP-3.2.0,如果猛犸上线新的的mammut 4.16对应的的NDP-3.3.0版本,该怎么操作?
- 或者在NDP-3.3.0版本中做了hadoop从2.7.3到2.8.2的升级,这个时候该如何操作?
尽管内部开发了支持包替换的升级方式,但该方法只能做一种临时解决方案,其有如下不足:
* 需要大量的人工介入:打开、关闭包替换开关,手动地修改下一个版本的配置,重启服务;
* 不支持Ambari本身的升级,无法继承新版本的特性等等。
所以对Ambari本身提出的需求有:
- 支持Ambari本身大版本的升级,比如从NDP-3.2.0到NDP-3.3.0的升级;
- 支持各个组件版本的jar包升级,比如hadoop 2.7.3到2.8.2的包替换;
- 支持各个组件版本的conf升级,比如mammut下一个版本可能有许多配置项的更新;
- 支持python执行脚本的升级,在下一个版本中有可能部署方式会有很大的不同,如果升级了ambari需要支持此种不同的部署方式;
当然除了本身功能升级功能的支持,还要尽量做到如下:
- 尽量少地人工介入;
- 尽量少地影响线上服务;
一、难点
1. 如何升级组件服务?
当前内源Ambari安装服务组件的方式跟社区有很大的不同,社区所有组件的安装是基于debian/centos发布的repo包进行安装的;但内源版本放弃了该种安装方式,采用直接tar解压安装的方式;
所以在升级的过程,需要梳理好该如何进行包的升级;
2. 如何操作升级?
当前Ambari社区版本是支持Express/Rolling升级的,但由于内源版本和社区版本已经有了很大的不一致(比如上述的repo机制),所以整个安装流程需要打通,兼容我们内源版本。这期间需要解决的问题:
* Ambari-Web前端支持手动点击升级操作;
* 梳理升级流程,解决内源版本不支持的状态;
* 解决包更新逻辑;
3. 保障操作的完整性?
由于组件越来越多,怎么样在升级操作的流程中保障最终升级符合操作的要求?
* 升级结果包替换的正确与否?
* 配置是否正确?
* 升级过程有无造成有状态服务组件的脏数据?
* Ambari数据库状态是否符合要求?
4. 社区版必要文件的缺失?
由于Ambari代码主要为Hortonworks开源出来,并主要为其HDP平台服务的,许多实现逻辑中均依赖HDP自身的一些基础脚本。目前发现缺失的脚本有:
* hdp-select: 实现各个版本软链切换的脚本;
* conf-select: 实现各个版本conf文件切换的脚本;
5. 实现必要的备份、回滚工作?
升级操作毕竟是有风险的,在进行处理之前,务必保障备份工作,以备在必要的情况下进行回滚操作;
二、设计与实现
整体设计流程
参考社区实现逻辑为主,同时兼容内源版本运行;
升级流程主要包含两步实现:安装新版本的包和执行自定义升级脚本;
安装新版本的包
在社区版本中通过更新repo的方式来完成新版本包的安装;
[TODO] 内源版本最好的解决方案也是在install_packages()时进行新版本包安装;
但是由于当前内源版本安装包实现逻辑,同时在暂时无法在已有代码上使用tar包版本更新
来代替基于repo的install_packages()
升级,所以暂时使用的折中方案:
- 在install package阶段(安装新版本包)并不做真实的新版本的tar包安装;
- 而是在下一步骤时,基于以后的
包替换开关
在restart阶段进行包替换;
自定义升级脚本
- 去除冗余、无用的依赖
- 根据我们实际的使用情况自定义升级脚本;
- 同时支持快速和滚动升级逻辑;
三、Uprade操作流程(调研)
本阶段进展:
* 支持主要核心组件:HDFS/YARN/HBase/Spark/Hive/Ranger;
* 完成内源ambari系统快速迭代至新的版本;
* 最优化操作流程,最小化操作动作;
手动操作流程(理想状态)
- 编译新的Ambari版本,并安装更新Ambari-Server和Ambari-Agent,在debian中为deb包,在centos中未rpm包。在Ambari-server机器上操作:
dpkg -i ambari-server_2.5.1.0-0-dist.deb
ambari-server setup
进行必要的备份;
- Ambari-Server数据库的备份/ambari-server backup;
- Hive/Ranger等有状态数据库信息的备份;
- HBase/HDFS 做snaptshot,保障回滚前最新版本;
- …
在Ambari版本管理页面注册新的Ambari版本
我们暂定下一个版本将YARN从2.7.3升级至2.8.2;
首先确认当前Ambari中已有Ambari版本,目前版本为NDP-3.4:
安装新版本包至各机器(并没有真实安装);
开始Upgrade;
[TODO] 注意在开始升级前,务必开启
包替换开关
:/var/lib/ambari-server/resources/scripts/configs.py –user admin –password admin –action set –host hzadg-mammut-platform1.server.163.org –cluster cluster1 –config-type cluster-env –key reinstall_component_package –value true[TODO] 在升级结束以后关闭该开关:/var/lib/ambari-server/resources/scripts/configs.py –user admin –password admin –action set –host hzadg-mammut-platform1.server.163.org –cluster cluster1 –config-type cluster-env –key reinstall_component_package –value false
选择快速升级;
开始执行升级脚本;
完成升级前清理不必要的备份文件(按照提示);
完成升级;
[TODO] 升级过程中降级演练
[TODO] 滚动升级演练
具体Express Uprade流程(自定义升级脚本,后续逐渐扩展)
自定义执行快速升级、滚动升级过程;
[TODO] 滚动升级暂时不支持;
- [手动]关闭YARN队列;
- [自动]按照顺序关闭High Level组件:
- atlas;
- spark history->spark thriftserver;
- hive server -> hive_metastore;
- nodemanager -> resourcemanager;
- historyserver;
HBase/HDFS等有状态组件并没有关闭:后续需要做备份操作;
备份有状态组件
- [手动]Hive metastore手动备份;
- [自动]HBase执行snapshot;
- [自动]HDFS执行express升级;
- [手动]Ranger元信息备份;
[自动]按照熟悉关闭Low Level(核心)组件:
- hbase_regionserver -> hbase_master -> phoenix_query_server;
- kafka_broker;
- datanode->namenode->secondary_namenode->zkfc->journalnode;
- ranger_usersync -> ranger_admin -> ranger_tagsync;
- zookeeper;
[自动]升级目标stack
- 调用
org.apache.ambari.server.serveraction.upgrades.UpdateDesiredStackAction
升级至目标stack;
- 调用
[自动]升级服务配置
- 根据upgrades/config-upgrade.xml里定义的任务执行修改针对各个组件的配置;
[自动][Kerberos环境]
- 调用
org.apache.ambari.server.serveraction.upgrades.UpgradeUserKerberosDescriptor
更新kerberos描述符;
- 调用
[自动]升级NDP路径
- 调用
script/ru_set_all.py
将current路径指向目标路径;
- 调用
[自动][第一批]开始重启底层服务组件:
- zookeeper_server/zookeeper_client;
- ranger_admin/rangerusersync;
- journalnode/zkfc/namenode/secondary_namenode/hdfs_client;
- datanode;
- 等待safemode退出;
- kafka;
- historyserver->mapreduce_client;
- resource_manager->yarn_client;
- nodemanager;
- [手动] 如果设置了
yarn.resourcemanager.work-preserving-recovery.enabled
,需要手动开始yarn queues队列; - hbase_master->hbase_regionserver->hbase_client->phoenix_query_server;
- sqoop_client;
[自动][第一批]校验底层服务组件是否正常
- zookeeper;
- ranger;
- hdfs;
- kafka;
- yarn;
- mapreduce2;
- hbase;
[自动][第二批]开始重启上层服务组件:
- hive_metastore->hive_server;
- hive_client;
- spark2_jobhistoryserver->spark2_thriftserver;
- spark2_client;
- altas_server;
- atlas_client;
[自动][第一批]校验底层服务组件是否正常
- hive;
- spark2;
- atlas;
[自动] 最终版本校验
- 调用
org.apache.ambari.server.serveraction.upgrades.ComponentVersionCheckAction
进行组件版本校验;
- 调用
最终升级
- [手动] 确认结束升级;
- [手动] 删除HBase Snapshots;
- [自动] 结束非滚动升级(调用namenode.py@finalize_non_rolling_upgrae);
- [自动] 调用
org.apache.ambari.server.serveraction.upgrades.FinalizeUpgradeAction
保存集群状态;
Express/Non-Rolling 降级(回滚)
- [手动]从备份的元信息中恢复Hive Metastore;
- [手动]从备份的云信息中恢复Ranger Admin;
HDFS Express升级流程梳理
准备阶段:
During an Express Upgrade.
If in HA, on the Active NameNode only, examine the directory dfs.namenode.name.dir and
make sure that there is no "/previous" directory.
Create a list of all the DataNodes in the cluster.
hdfs dfsadmin -report > dfs-old-report-1.log
hdfs dfsadmin -safemode enter
hdfs dfsadmin -saveNamespace
Copy the checkpoint files located in ${dfs.namenode.name.dir}/current into a backup directory.
Finalize any prior HDFS upgrade,
hdfs dfsadmin -finalizeUpgrade
Prepare for a NameNode rolling upgrade in order to not lose any data.
hdfs dfsadmin -rollingUpgrade prepare
结束滚动升级:
hdfs dfsadmin -rollingUpgrade finalize
四、当前存在的问题
问题一:开始更新时repo_version命名不合法
这个问题应该是社区里的bug,在通过上述步骤注册新的版本比如说3.5.1.0在升级时被认为是不合法的,当前解决方案:
update repo_version set version=’3.5-10’,display_name=’NDP-3.5-10’ where repo_version_id=201;
ambari-server restart
问题二:当前版本HBase不支持snapshot_all
解决方案: 点击继续
问题二:org.apache.ambari.server.serveraction.upgrades.ComponentVersionCheckAction
校验失败
select * from hostcomponentstate;
update hostcomponentstate set version=’3.5-10’;
问题三: org.apache.ambari.server.serveraction.upgrades.FinalizeUpgradeAction
校验失败
select * from host_version;
update host_version set state=’INSTALLED’ where repo_version_id=151;
update host_version set state=’CURRENT’ where repo_version_id=201;
问题四:切换版本的问题
如何进行切换版本?
五、后续需要解决的问题
1. 解决已经存在的问题,避免手动操作流程;
2. 核对升级过程中配置项更新、覆盖规则(避免线上升级过程中的误操作);
3. 优化、丰富非滚动、滚动升级脚本;
4. 优化升级核心流程(包下载、安装、更新方式);
参考:
- API for HDP upgrade: https://community.hortonworks.com/questions/177958/api-for-hdp-upgrade.html
- 4 Required subjects before upgrade:https://community.hortonworks.com/questions/177974/4-required-subjects-before-upgrade.html
- Ambari Rolling & Express Upgrade: https://community.hortonworks.com/articles/2473/rolling-upgrade-express-upgrade-in-ambari.html
- Management Packs: https://cwiki.apache.org/confluence/display/AMBARI/Management+Packs
- How-To Define Stacks and Services: https://cwiki.apache.org/confluence/display/AMBARI/How-To+Define+Stacks+and+Services#How-ToDefineStacksandServices-ServiceUpgrade
- “Upgrade” table missing from Ambari database: https://community.hortonworks.com/questions/26244/upgrade-table-missing-from-ambari-database.html
- https://community.hortonworks.com/articles/20759/what-to-check-when-upgrade-downgrade-seems-to-be-s.html
- http://han-zw.iteye.com/blog/2323309