HDFS 2.7.2 滚动升级 3.3.4-奇安信实践

1.升级背景

在2017年底就已经发布了 Hadoop3.0版本。到目前为止， Hadoop 发布的最新版本为3.3.4。在 Hadoop3 中有很多有用的新特性出现，如支持 ErasureCoding、多 NameNode、Standby NameNode read、FairCallQueue、DataNode Disk Balance、HDFS RBF 等等。除此之外，还有很多性能优化以及 BUG 修复。其中里面提到的 ErasureCoding 特性，数据可靠性保持不变的情况下可以降低数据的存储副本数量，结合公司的降成本目标，我们对此已经做了深入的调研。同时，在实际问题处理过程中我们也发现，我们遇到过的一些 BUG 以及想做的一些优化点，社区早已经修复或者实现。内部使用的 Hadoop 版本对应社区的2.7.2，由于社区很多 BUG 修复是不会移植到太低版本的，我们解决问题时花费了较多精力在移植与测试验证中。如果升级到 HDFS3.3及以上 版本，可以站在巨人肩膀上继续工作，做一些更有意义的事情。

2.升级目标

此次升级目标主要有四点：

1、解决 冷数据压力 和 小文件压力，降本增效

2、升级需要采用热升级，不影响业务的正常运行

3、有完备的降级方案，升级有异常时可迅速降级（回退）

4、保证HDFS升级后和现有组件兼容，不影响其他组件的正常服务

3.升级方式方案

升级方式有两种：Express 和 Rolling，Express 升级过程是停止现有服务，然后使用新版本启动服务；Rolling 升级过程是滚动升级，不停服务，对用户无感知。对于公司来说，当然滚动升级是最好的方案。

我们主要是对服务端进行升级，包括 JournalNode，NameNode，ZKFC，DataNode 组件。Client 端 Spark，Hive，Flink 等等很多组件依赖，目前这些组件还不支持 Hadoop3，因此 Client 版本暂时保持不变。所以最后的总体升级策略是只升级hdfs 服务端版本，依赖hadoop 的组件（比如Spark/hive/flink/hbase等） 依然使用hadoop2.7.2 版本的客户端和hdfs 3 版本服务端进行交互。

原2.7.2版本经测试无法直接升级3.3.4在认证和回退降级中存在一些问题，所以需要在升级3.3.4升级前进行一次前置升级，升级至过度版本，以避免一些升级带来的问题影响上层组件：

升级过度版本是一个普通的升级，直接换包依次滚动重启namenode、datanode即可，这里不详细说明，主要详细说明的是升级3.3.4版本的过程，升级&回退方案如下图：

详情参见：Apache Hadoop 3.3.4 – HDFS Rolling Upgrade

4.遇到的问题

问题1：datanode降级失败

hadoop3.x数据块目录存储结构从256 x 256个目录变成了32 x 32个目录，所以在降级时无法降级相关issue如下：

【HDFS-8791】（hadoop3.3.4需回退此patch，datanode才可降级）： DataNode layoutVersion改变的原因：Hadoop社区自 HDFS-2.8.0 commit HDFS-8791 后，对DataNode的Layout进行了升级，DataNode Block Pool数据块目录存储结构从256 x 256个目录变成了32 x 32个目录。目的是通过减少DataNode目录层级来优化Du操作引发的性能问题，回退了此patch后，DataNode Du带来的性能问题怎么解决，在下面的HDFS-14313中进行了优化，hadoop3.3.4已包含

【HDFS-14313】（hadoop3.3.4已包含patch内容）：从内存中计算DataNode使用空间，不再使用Du操作。

此问题只涉及2.8.0以下版本升级需要回退HDFS-8791，2.8.0之后版本数据块目录存储结构从256 x 256个目录变成了32 x 32个目录，升级降级不会遇到此问题。

hadoop2.8.0以下版本滚动升级hadoop3.3.4前，hadoop3.3.4源码需要回退HDFS-8791，否则datanode无法降级。

问题2：namendoe降级失败

报错信息：

经调研此处存在潜在的FSImage损坏，HDFS-13596中提到了一个commit可以解决此问题（https://github.com/lucasaytt/hadoop/commit/8a41edb089fbdedc5e7d9a2aeec63d126afea49f

此commit在fsimage中支持扩展字符串表，修复潜在的FSImage损坏

hadoop2.7.2报错位置源码：

HDFS-13596中提到了一个commit与报错位置相关源码改动：

经过测试，若升级后确需降级，则需要在原版本（测试时使用2.7.2）合并commit：https://github.com/lucasaytt/hadoop/commit/8a41edb089fbdedc5e7d9a2aeec63d126afea49f，同时将PermissionStatusFormat中的GROUP和USER都改为24

问题3：升级过程中出现无法正常读写情况（开启了kerberos）

现象：在升级一个namenode到hadoop3.3.4，并将此namenode切换为acitve后，读写程序开始报错：

经过排查发现hadoop3.3.4namenode为active之后datanode读写的日志（HMAC是不一致的）

所以在开启kerberos的升级过程中，hadoop3.3.4版本的namenode与hadoop2.7.2版本的datanode存在计算HMAC不一致的问题

hadoop2.7.2和ahdoop3.3.4的BlockTokenIdentifier类对比

HDFS-14509提供了解决方案，我们直接将token message转化为byte数组，而不经过转换为BlockTokenIdentifier对象的步骤，这样 hadoop 版本之间BlockTokenIdentifier对象的差异，就不会影响password的生成。

问题4：hdfs升级3.3.4后，会转冷数据为EC，但hdfs客户端是2版本不支持ec

经过研究决定将3.3.4版本的客户端的ec逻辑移植到2版本中，在集群升级3.3.4版本之前，客户端先升级到支持EC的2版本