Hadoop集群运维相关笔记 hdfs参数设置调优等
文章目录
-
- 1. HDFS
-
- 1.1 DataNode服务经常僵死
-
- 描述
- 分析
- 解决
- 1.2 DataNode因数据盘损坏重启失败
-
- 描述
- 分析
- 解决
- 1.3 优化Hadoop Balancer平衡的速度
- 2. HBASE
-
- 2.1 master服务无法启动error or interrupt while splitting logs
-
- 描述
- 分析
- 解决
- Ref
本篇博客将持续更新一些遇到过的Hadoop大数据集群的问题，包括HBASE HDFS的常见问题及相关的解决方案
1. HDFS
1.1 DataNode服务经常僵死
描述
集群一共设置了8个DataNode，经常不知道什么原因会导致其中3 4 个一直处于僵死状态，重启可以恢复单身过一段时间又会有同样的问题。如果长时间不管，甚至还会namenode服务挂掉。
分析
通过查看/data/var/log/hadoop/hdfs/目录下面DataNode的log日志可以看到:
java. io. IOException: Premature EOF from inputstream
文件操作超租期，实际上就是data stream操作过程中文件被删掉了。通常是因为Mapred多个task操作同一个文件，一个task完成后删掉文件导致。这个错误跟dfs.datanode.max.transfer.threads参数到达上限有关。这个是datanode同时处理请求的任务上限，指定用于在DataNode间传输block数据的最大线程数，老版本的对应参数为dfs.datanode.max.xcievers
若集群中需要运行HBASE则需要设置更多，网上建议设置为16k。
解决
将dfs.datanode.max.transfer.threads 原本为1024调大至10240之后灰度重启DataNode所有节点，隔一定时间后查看服务正常。
1.2 DataNode因数据盘损坏重启失败
描述
DataNode单点离线，且一直尝试重启DataNode失败
分析
查看该节点DataNode日志，可以看到
Invalid dfs.datanode.data.dir /data4/hadoop/hdfs/data :
java.io.FileNotFoundException: File file:/data4/hadoop/hdfs/data does not exist
初步判断是有个数据盘坏了，读取不到相应数据，导致每次重启都会失败。
解决
因为需要保障线上服务，需要立刻启动DataNode服务。
hdfs有一个配置dfs.datanode.failed.volumes.tolerated可以指定datanode可以容忍多少个失败的目录，默认是0，表示只要失败一个datanode就无法启动。
将该配置修改为1之后再灰度重启DataNode服务，成功。
后续操作则为更换坏盘：
尝试新建文件报错如下
touch 111
touch: cannot touch `111': Read-only file system
硬盘的健康状况
smartctl -H /dev/sdd
result后边的结果：PASSED，这表示硬盘健康状态良好
如果这里显示Failure，那么最好立刻给服务器更换硬盘
可以肯定是这块sdd硬盘出现问题，可以将此节点服务器，从hadoop群集中排除，
umount这块硬盘，之后更换个新的，重新格式化mount，再将服务器重新加入到hadoop群集中即可。
网上有些朋友说进行linux修复模式，fsck下硬盘，但是为了避免再出现问题，还是直接换个新的。
1.3 优化Hadoop Balancer平衡的速度
Hadoop的HDFS集群在使用一段时间后，各个DataNode节点的磁盘使用率肯定会出现不平衡的情况，也就是数据量层面的数据倾斜。
我们都知道当HDFS出现数据不平衡的时候，就会造成MapReduce或Spark等应用程序无法很好的利用本地计算的优势，而且Datanode节点之间也没有更好的网络带宽利用率，某些Datanode节点的磁盘无法使用等等问题。
可以参考 https://blog.51cto.com/xiaoxiaozhou/2139249
2. HBASE
2.1 master服务无法启动error or interrupt while splitting logs
描述
集群因为网络问题，几个节点几小时处理网络孤立状态，导致hbase master服务与几个region server服务挂掉。
网络恢复之后，尝试启动master，频繁拉起失败
分析
查看master日志，有以下报错
org.apache.hadoop.hbase.master.MasterFileSystem: Failed splitting of [inc-dp-hbase-02,60020,1335429401869, inc-dp-hbase-03,60020,1335429401847]
java.io.IOException: error or interrupt while splitting logs in [hdfs://inc-dp-hbase-01.hst.bjc.kfc.alidc.net:9000/hbase/.logs/inc-dp-hbase-02,60020,1335429401869-splitting, hdfs://inc-dp-hbase-01.hst.bjc.kfc.alidc.net:9000/hbase/.logs/inc-dp-hbase-03,60020,1335429401847-splitting] Task = installed = 1 done = 0 error = 0
at org.apache.hadoop.hbase.master.SplitLogManager.splitLogDistributed(SplitLogManager.java:268)
at org.apache.hadoop.hbase.master.MasterFileSystem.splitLog(MasterFileSystem.java:276)
at org.apache.hadoop.hbase.master.MasterFileSystem.splitLogAfterStartup(MasterFileSystem.java:216)
at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:487)
at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:326)
at java.lang.Thread.run(Thread.java:662)
在尝试分割WAL目录文件的时候出错，导致HMaster服务异常终止
解决
有两种解决方法，这里采取了第一种
- 将wals下文件备份到其他地方；
- 在hdfs-site.xml配置中设置
hbase.master.distributed.log.splitting参数value为false
原理
在之前的博客hbase技术细节第三节RegionServer的故障恢复中，讲述了Distributed Log Splitting 分布式日志切分的实现，分布式就不是master单独在恢复了，而是充分使用各个RegionServer上的资源，利用多个RegionServer来并行切分Hlog，提高切分的效率。
但是这种方式有个弊端是会产生很多小文件（切分的Hlog数 宕机的RegionServer上的Region数）。比如一个RegionServer有20个Region，有50个Hlog，那么产生的小文件数量为2050=1000个。如果集群中有多台RegionServer宕机的情况，小文件更是会成倍增加，恢复的过程还是会比较慢。
master服务启动失败原因应该是因为集群region数量较多，生产的小文件数量太多，导致处理失败。
Ref
- https://community.cloudera.com/t5/Support-Questions/Is-there-any-recommendation-for-dfs-datanode-max-transfer/td-p/120288
- https://blog.csdn.net/levy_cui/article/details/51143058
- https://blog.csdn.net/jiangheng0535/article/details/19114415