基于Ambari 滚动、快速升级实现调研(内源版本)

背景

当前现状

当前的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系统快速迭代至新的版本；
* 最优化操作流程，最小化操作动作；

手动操作流程(理想状态)

1. 编译新的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

1. 进行必要的备份；

   • Ambari-Server数据库的备份/ambari-server backup；
   • Hive/Ranger等有状态数据库信息的备份；
   • HBase/HDFS 做snaptshot，保障回滚前最新版本；
   • …

2. 在Ambari版本管理页面注册新的Ambari版本

我们暂定下一个版本将YARN从2.7.3升级至2.8.2；

• 首先确认当前Ambari中已有Ambari版本，目前版本为NDP-3.4：

  1. 安装新版本包至各机器（并没有真实安装）；

  2. 开始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