基于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. 优化升级核心流程(包下载、安装、更新方式);

参考:

展开阅读全文

没有更多推荐了,返回首页