怎么处理HDFS问题

本文主要介绍“如何处理HDFS问题”。在日常操作中，我相信很多人对如何处理HDFS问题有疑问。边肖查阅了各种资料，整理出简单易用的操作方法，希望能帮助大家解决“如何处理HDFS问题”的疑惑！接下来，请和边肖一起学习！

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

hdfs有目录扫描机制。默认情况下，所有块将每6小时扫描一次，以确定它们是否与内存中的块图一致。涉及

https://blog . cloud era.com/HDFS-data node-scanner-and-disk-checker-explained/

当小文件较多时，扫描时特征明显。——磁盘的iops很高，但吞吐量很低。当然，这不是datanode心跳超时的原因，真正的原因是扫描后的结果。比如对比后发现有2万块不一致。当修复这些块时，它们会保持对对象FsDatasetImpl的锁定。如果磁盘速度较慢，可能需要5分钟甚至10分钟才能完成处理，从而一直阻塞读、写、心跳的线程。

您可以详细了解HDFS-14476在修复磁盘和内存中不一致的块时锁定时间过长，包括一些特性、证据和块修复逻辑，详情请见。

解决方案是，我们在这里添加了一个补丁(它已经合并到2.10和3.x中)。在处理异常块时，我们应该休息2秒钟来处理正常请求，以防止datanode卡住甚至离线。

修复后的效果也很明显，datanode的心跳也顺畅了很多。

2.名称节点迁移被取消，客户端无法写入。

本文结合HDFS取消命名节点的实践，总结了在线迁移HDFS命名节点的方法。迁移/取消的思路是保持namenode主机名不变，滚动迁移备用节点。

但在我们的迁移实践中发现，hdfs namenode迁移后，集群正常，但hdfs客户端访问异常。在像纱线这样的长任务场景中，文件读取和写入总是会失败，直到纱线节点管理器重新启动。

具体问题如下：

客户端使用configuredfailloverproxyprovider。客户端启动后，会根据当时的inetsocket创建两个namenode代理，nn1和nn2，在任何网络异常情况下都不会重新创建。

Client updateAddress方法可以检测到namenode ip已经更改，但是因为没有捕获到该异常，所以下次回收正确的namenode ip应该是正常的。但是，抛出异常后，客户端会重新连接namenode。但是上面的namenode代理仍然是旧地址，SetupConnection异常，进入updateAddress判断逻辑，返回true建立连接，陷入死锁。

复制步骤

打开一个hdfsclient，写一个长时间放的hdfs文件。

更新hdfs新名称节点主机名-ip。

停止旧nn2，启动新nn2

更新客户端的名称节点主机名-IP(客户端仍在操作文件)。

切换到新的名称节点HDFS ha admin-故障转移nn1nn2。

此时，您会发现客户端不断报告错误。

在纱线客户端启动的周期中，即使写入了新文件，仍然会报告错误。

修补configuredfailoverproxyprovider，即客户端故障转移后，进行updateAddress判断，如果有ip变化，则createProxy。请验证此修补程序是否也有效。但是，最好在客户端统一捕获，因为还有其他类型的HaProvider可能也有这个问题。

这个问题的补丁已经整合到Apache Hadoop 3.4中，参见Hadoop-17068客户端在NameNode IP addr改变时永远失败。我们使用的版本是2.6.0-cdh6.4.11，已经并入。

除了解决根本原因问题之外，在namenode迁移操作期间，还可以在旧节点上启用端口转发，然后可以逐个重新启动纱线，以避免造成大范围的故障。

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

现象：当集群将满时，批处理机的释放空间扩大。运行2周的客户端突然报告文件写入失败。

原因：当一些数据节点已满时，hdfs会自动选择其他可用的空闲节点。由于dfs.datanode.du.reserved的配置不正确，仍将选择完整节点。尤其是df。

s.datanode.du.reserved如果小于分区block reserved，在磁盘用满时就会出现

org.apache.hadoop.ipc.RemoteException(java.io.IOException): File 
/kafka/xxxtmp.parquet could only be replicated to 
0 nodes instead of minReplication 
(=1).  \
There are 
14 datanode(s) running 
and no node(s) are excluded 
in this operation.

解决：

• 扩容完，跑rebalance

• 修改磁盘分区的block reserved，使其小于 dfs.datanode.du.reserved. 见 hdfs datanode Non DFS Used与Remaining .

• 增加单个datanode容量告警

4. 做 rebalance 时速度很慢

启动 rebalance 命令./start-balancer.sh -threshold 10，如果需要提高速度可以修改限流带宽hdfs dfsadmin -setBalancerBandwidth 52428800
但是 datanode 上同时接收 blocks 并发数，是不能在线调整的（或者说只能调小），调整hdfs-site.xml默认的balance参数，并重启

dfs.balancer.moverThreads=1000
dfs.balancer.dispatcherThreads=200
dfs.datanode.balance.max.concurrent.moves=50

如果启动balance时，尝试以更高的并发执行，datanode会判断没有足够的线程接收 block: IOException: Got error, status message Not able to copy block … because threads quota is exceeded。
当 move 出现失败时，迁移速度是指数级下降的，因为move block失败默认会sleep一段时间。

./start-balancer.sh 
-threshold 
5\
 -Ddfs.datanode.balance.max.concurrent.moves=20 \
 -Ddfs.datanode.balance.bandwidthPerSec=150000000 \
 -Ddfs.balancer.moverThreads=500 \
 -Ddfs.balancer.dispatcherThreads=100

5. 给datanode在线增加磁盘

腾讯云上的机器，可以直接在原有 datanode 上直接挂在新的磁盘，快速给hdfs扩容。
增加磁盘，不需要重启datanode。(前提是设置了 dfs.datanode.fsdataset.volume.choosing.policy为AvailableSpaceVolumeChoosingPolicy)

1. 挂载后，先建立hadoop数据目录并修正权限

2. 在hdfs-site.xml 里加上新目录配置 dfs.datanode.data.dir

3. 可以使用 reconfig 命令使其生效： hdfs dfsadmin -reconfig datanode dn-x-x-x-x:50020 start

6. namenode设置了HA，但故障时未成功切换

现象：active namenode 内存故障，主备切换失败
原因：dfs.ha.fencing.methods设置为了ssh，但是并不能登录其他namenode执行fence
解决：生成ssh key，免密码登录。或者改成shell(/bin/true)，强切。注意，修改fence方式后，需要重启zkfc。

7. hdfs client input/output error

现象：执行 hdfs 客户端命令报错 input/output error，试着拷贝 hadoop / jdk 的介质目录，亦发现文件损坏。有时会发现 jvm core
原因：磁盘存在坏块，刚好hdfs或者jdk的 jar 库损坏。通过观察 messages 发现有 sda IO Input/Output Error
使用badblocks -s -v -o bb.log /dev/sda 可以看到磁盘损坏了哪些扇区
解决：从其他机器，拷贝一份正常的介质

8. hdfs误将 data 盘作为数据盘

误将系统盘作为了dfs.datanode.data.dir，运行一段时间后，这个分区很容易最先满。
这个是配置上的问题，理解datanode的工作方式，可以快速的将这个分区里的block挪到正确的磁盘分区。
处理方法就是停止datanode，拷贝/data block到其它分区，删掉/data的配置。因为datanode上block的位置是每次启动的时候，扫描上报给namenode，所以可以做物理拷贝。
可以使用拷贝命令cp -a /data/hadoopdata/current/BP-*-*/current/finalized/* /data1/hadoopdata/current/BP-*-*/current/finalized/ ，不能拷贝整个 hadoopdata 目录，因为VERSION文件里面的storageID不同。

9. 使用decomiss方式将datanode退服时，客户端读写异常

现象：将datanode加入 exclude ，正常 decomissing 的方式退役节点，应用层反馈 spark 任务部分异常，报错 Unable to close file because the last block doest not have enough number of replicas ，但该集群一些其它的文件读写任务正常。
原因：spark任务会频繁的创建、删除application目录。在decomissing时，部分磁盘性能低的节点，磁盘更加繁忙，导致出现 last contact 心跳时间长
解决：经过验证，发现直接 kill datanode进程的方式，不影响spark任务。但必须保证一个一个的kill，否则会出现 missing block. （这不一定是解决问题最好的办法，但的确有效）

10. namenode editlog 长时间未做checkpoint

standby namenode的一个作用是，定期合并从journalnode上获取的editlog，生成新的元数据fsimage，然后推送到active namenode。
当standby namenode出现异常，如进程退出、软件bug(比如我们遇到过 IOException: No image directories available!)，导致长时间未合并editlog。一旦需要发生切换或者重启namenode，有可能导致启动时间过长，严重的editlog合并需要的内存不足，无法启动namenode.

如果内存不足，一种解决办法是借一台高内存临时机器合并editlog:

• 把standby停下来，将hdfs的软件介质和配置文件，拷贝到高内存机器

• 同时拷贝dfs.namenode.name.dir 目录中最新能用的 fsimage_xxx 和它之后的所有 edits_xxx-xxx

• 在临时机器上启动 namenode 进程，会自动从对应目录加载 fsiamge 、合并editlog

预防比补救要重要，一定要监控namenode上 TransactionsSinceLastCheckpoint 这个指标，我们的阈值是达到 5000000 就告警。

11. HDFS 3.x datanode 出现大量 CLOSE-WAIT

这个问题 HDFS-15402 是在定期对 datanode http://127.0.0.1:50075/jmx jmx 进行探测的时候产生的，我们有 5 个 hadoop 3.1.3 的集群都存在该问题。在 hadoop 2.x 中正常。
50075 端口上产生过多 close-wait 的影响是，正常的 webhdfs 会出现 504 Gateway-timeout

[root@dn-9-4-xxx-yy 
/tmp]# ss -ant|grep :50075 |grep CLOSE-WAIT|wc -l
16464
[root@dn-9-4-xxx-yy 
/tmp]# ss -ant|grep :50075 |grep CLOSE-WAIT|head -3
CLOSE-WAIT 
123    0                9.4.xxx.yy:50075           
9.4.xxx.yy:39706
CLOSE-WAIT 
123    0                9.4.xxx.yy:50075           
9.4.xxx.yy:51710
CLOSE-WAIT 
123    0                9.4.xxx.yy:50075           
9.4.xxx.yy:47475
 
lsof 
-i:39706
COMMAND    PID USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
java    134304 hdfs 
*307u  IPv4 429yy7315      0t0  TCP dn-9-4-xxx-yy:50075->dn-9-4-xxx-yy:39706 (CLOSE_WAIT)
  
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp      123      0 9.4.xxx.yy:50075            9.4.xxx.yy:39706            CLOSE_WAIT  134304/java

CLOSE-WAIT 状态是客户端(curl)发起关闭tcp连接时，服务端(datanode)收到了FIN-ACK，但在关闭socket时一直没有完成。正常流程是关闭socket完成，然后向客户端发送FIN

所以问题出在datanode server上，与knox还是haproxy客户端没有关系。并且这个问题调整os内核参数是没有用的，除非kill datanode，否则close-wait状态会永久存在。使用网上的kill_close_wait_connections.pl 能够清理这些 close-wait，之后 webhdfs 请求变得好转。

目前避开的方法就是，不再请求 datanode jmx 做监控，只获取 namenode 上的指标。datanode 上采集 os 级别的指标。

12. knox 无法上传 8G 文件

在官方 jira 里我们提了这个问题 KNOX-2139，当我们使用 webhdfs with knox 上传 8589934592 bytes 大小的文件，会出现 (55) Send failure: Broken pipe，在 hdfs 只能看到一个空文件。而且在版本 knox 1.1, 1.2 中是必现，在 0.8 版本正常。

简单 debug 了一下代码，knox 拿到的请求 contentLength 为 0，8G 以外的情况 contentLength 为-1。

我们后来使用 haproxy 代替 knox 解决 knox 自身上传速度慢和这个 8G 文件的问题。在 备份系统上传优化：从knox到haproxy 有介绍我们的实现

不过在最新的 1.4 版本，8G问题又消失了。根据官方的恢复，可能跟 jetty 的升级有关。

13. Unable to load native-hadoop library for your platform

Unable to load native-hadoop library for your platform… using builtin-java classes

经常在执行 hdfs 客户端命令时会有这样的提示，其实是个老生常谈的问题。

简单说就是系统里没有找到原生的 hadoop 库 libhdfs.so，这个库是 C 写的，性能比较好。缺少但不影响使用，因为 hadoop 里有 java 实现的客户端库。

出现这个我总结原因有 3 个：

1. hadoop 安装包里没有自带 libhdfs.so
   这个情况占很大一部分。去到目录${HADOOP_HOME}/lib/native/，看下是否有libhdfs.so,libhdfs.a,libhadoop.so,libhadoop.a。如果没有的话，可以重新下一个完整的二进制包，把lib/native拷出来用
   这种看到才是正常的

./bin/hadoop checknative
20/05/14 20:13:39 INFO bzip2.Bzip2Factory: Successfully loaded 
& initialized native-bzip2 library system-native
20/05/14 20:13:39 INFO zlib.ZlibFactory: Successfully loaded 
& initialized native-zlib library
Native library checking:
hadoop:  true 
/data1/hadoop-hdfs/hadoop-dist/target/hadoop-2.6.0-cdh6.4.11-tendata/lib/native/libhadoop.so.1.0.0
zlib:    true 
/lib64/libz.so.1
snappy:  true 
/data1/hadoop-hdfs/hadoop-dist/target/hadoop-2.6.0-cdh6.4.11-tendata/lib/native/libsnappy.so.1
lz4:     true revision:10301
bzip2:   true 
/lib64/libbz2.so.1
openssl: true 
/usr/lib64/libcrypto.so

实在不行就在自己的 os 上编译一个。

mvn clean package 
-Pdist,native 
-DskipTests 
-Dtar 
-Dbundle.snappy 
-Dsnappy.lib=/usr/local/lib

1. so 文件存在，但路径不对
   现在的版本，默认路径都能找得到 so 库。这个 Hadoop “Unable to load native-hadoop library for your platform” warning 里面介绍的大部分方法，都是在教怎么设置路径。真实原因很少会因为路径不对，不过这个答案靠谱 https://stackoverflow.com/a/30927689 ，也就是我们的情况 3

2. 编译的版本，在我们的 os 上依赖库不全
   遇到过这种，glibc 库版本不够：

$ ldd lib/native/libhadoop.so
lib/native/libhadoop.so: /lib64/libc.so.6: version `GLIBC_2.14' 
not found 
(required by lib/native/libhadoop.so)
	linux-vdso.so.1 =>  (0x00007ffd1db6d000)
/$LIB/libonion.so 
=> /lib64/libonion.so 
(0x00007f5bfd37d000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f5bfce40000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5bfcc23000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f5bfc88f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5bfd266000)

$ strings 
/lib64/libc.so.6 |grep GLIBC_
可以看当前系统支持哪些版本的 glibc

但是 glibc 安装升级有风险，如果要安装 2.14 版本务必先做好测试。

14. 处理 missing blocks

hdfs 集群出现 missing block，无非就是 namenode 里还记录的 block 元数据信息，但是所有副本都丢失了。如果是同时挂了多个机器，或者损坏了多个机器上的磁盘，是有可能会出现。
遇到过 2 次人为产生 missing blocks:

1. kill 一个 datanode 进程，就出现 missing block

2. 先设置所有文件的 replication 为 1，一小段时间后，再设置为 2

这两种情况都算是 bug，对应的文件确实无法 get 下来了。但第 1 中情况还好，经过排除日志，发现实际这些丢失的 blocks 本就接收到了删除命令，过一段时间后，missing block 一般会自动消失。第 2 中情况，是真的意外丢 block 了，比较严重。不要轻易把 replication 设置为 1，再改回去可能丢 block。

如果确认这些 missing block 可以消除，可以通过 fsck 命令手动处理：

// 如果missing blocks数不是很多，可以直接逐个delete
hdfs fsck file_name 
-delete

// 如果missing blocks较多，可以从namenode上拿到corrupt块
hdfs fsck 
/ -list-corruptfileblocks 
-openforwrite 
| egrep 
-v 
'^\.+$' | egrep 
"MISSING|OPENFORWRITE" | grep 
-o 
"/[^ ]*" | sed 
-e 
"s/:$//" > missing_blocks.txt

15. 应该关注的告警

实际还有些许多问题，比如用户supergroup 权限问题、rack-aware.sh文件缺失的问题，限于篇幅就不列举了。
问题是不断会出现的，但及时对大部分场景做到监控工具，能够提前发现问题。下面是整理并上线的关键告警指标：

• datanode lastcontact
  datanode 与 namenode 心跳监控。心跳时间长意味这这个 dn 没响应了，默认超过10m30s 没响应，dn会脱离集群。

• namenode and datanode web probe
  namenode 50070 与 datanode 50075 从外部探测，并且 datanode 会根据 include里面的地址自动增减。我们使用修改过了 telegraf http_response 插件,支持动态读取url，比如 exec bash get_datanode_urls.sh

• dirctory max files
  单目录下的文件数告警。hdfs默认限制单目录下最大的文件数100万，由配置项dfs.namenode.fs-limits.max-directory-items决定。
  这个指标数据来源于 fsimage 目录画像分析。

• transactions not merged
  standby 未滚动的editlog数。长期未checkpoint会导致下次namenode启动消耗过多内存，甚至启动失败。

• missing blocks
  异常blocks数

• test write file
  在2个namenode节点上，定期使用 hdfs put/get 写入文件。如果失败会告警

• non-active namenode
  hdfs集群namenode有且只有一个active，一个standby。其它情况告警

• cluster capacity
  集群总体容量监控

• node usage, ioutil
  单个 datanode 磁盘空间使用率预警，ioutil持续5分钟大于95%预警。

• failover occurs
  hdfs namenode发生failover

• namenode heap size
  namenode heap size使用比率。blocks数量多，内存使用越多。

到此，关于“怎么处理HDFS问题”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注网站，小编会继续努力为大家带来更多实用的文章！