ambari hdfs 启动报错_HDFS 运维常见问题处理

腾讯游戏CROS体系的DBA维护着多套互娱数据平台的核心HDFS集群，积累了不少维护经验。

1. 定期block全盘扫描，引起dn心跳超时而脱离集群

hdfs有一个目录扫描机制，默认6小时会全盘扫描一次所有block，判断与内存里的那份blockMap是否一致。参考
https://blog.cloudera.com/hdfs-datanode-scanners-and-disk-checker-explained/ 。

在小文件比较多的情况，扫描的时候特征很明显——磁盘的iops很高，但吞吐量很低。当然这不是引起datanode心跳超时的原因，真正的原因是处理扫描后的结果，比如比较完发现有20000个block不一致，在修复这些block时不断的持有了 FsDatasetImpl 这个对象的一把锁，在磁盘比较慢的情况下，可能需要5分钟甚至10分钟处理完，从而一直阻塞读、写、心跳的线程。

详细的可以了解 HDFS-14476 lock too long when fix inconsistent blocks between disk and in-memory，包括一些特征、证据，以及block修复逻辑，细节比较多。

解决办法是，我们这边加了个patch(已合入官方版本 2.10和3.x)，在处理异常block的时候，中间休息2秒，处理一下正常的请求，不至于datanode卡住甚至离线。
修复后的结果也是很明显，datanode心跳平滑了许多：

2. namenode迁移裁撤，遇到客户端无法写入

在需要迁移/裁撤namenode时，一般思路是保持 namenode hostname 不变，滚动迁移 standby 的方式迁移。

但是在我们的迁移实践中，发现 hdfs namenode 完成迁移后，集群正常，但 hdfs 客户端访问异常。在 yarn 这样的长任务场景下，会导致文件读写一直失败，直到 yarn nodemanager 重启。

具体问题是这样的：

client使用的是 ConfiguredFailoverProxyProvider ，client启动之后会根据当时的inetsocket创建nn1,nn2两个namenode proxy，这个在任何网络异常的情况下都不会重新创建。

client 的 updateAddress 方法能检测到namenode ip发生了变化，但由于那个异常没有捕获，本该在下次循环使用正确的 namenode ip 就能正常，但抛出异常后导致client重新连接namenode，然而上面的 namenode proxy 还是旧地址，SetupConnection 异常，又进入updateAddress判断逻辑，返回true又去建连接，陷入了死结。

复现步骤

1. 打开一个hdfsclient，长时间写一个文件 hdfs put

2. 更新hdfs新namenode hostname-ip

3. stop old nn2, start new nn2

4. 更新客户端的namenode hostname-ip (client还在操作文件)

5. 切换到新namenode hdfs haadmin -failover nn1 nn2

6. 此时会发现client一直报错
   在yarn客户端启动的周期内，哪怕是新文件写入，依旧会报错

对 ConfiguredFailoverProxyProvider 打了个patch，就是在client failover之后，也进行updateAddress判断，如果有ip变动，就重新 createProxy。验证这个patch同样有效。不过在client那边统一捕获会比较好，因为还有其他类型的HaProvider可能也有这个问题。

这个问题的 patch 已经被合入 Apache Hadoop 3.4，见 HADOOP-17068 client fails forever when namenode ipaddr changed。我们用的版本是 2.6.0-cdh5.4.11 ，patch也已合入官方版本。

除了从根源问题上解决，也可以在 namenode 迁移操作时，在老节点上启用端口转发，再逐个重启 yarn，避免引起大范围故障。

3. 集群dn不均衡导致文件写入失败

现象：集群将满时，扩容了批机器缓解空间。运行了2个星期客户端突然报文件写入失败
原因：hdfs在部分datanode空间满的情况下，理论会自动挑选其它可用的空闲节点。由于 dfs.datanode.du.reserved配置不当，导致依然会选中满节点。具体是dfs.datanode.du.reserved如果小于分区block reserved，在磁盘用满时就会出现

o