Hadoop运维记录系列【收集整理】

整理转载于:博客之星

http://slaytanic.blog.51cto.com/2057708/1038676


集群里面有三台服务器需要升级CPU。恰恰是三台,符合Hadoop集群配置的replication数量。运维人员没有沟通,通知了一下,然后就瞬间停了3台服务器。这下整个集群基本就废了。存数据当然没问题,但是查数完全不能查了。之后留守的数据组人员就发现集群无论如何也起不来了,只能打电话把我叫回来。


检查三台服务器无法启动的原因,其实起来了两台datanode和三台tasktracker,但无论什么样的reduce都做不了,会报错。另外有一台datanode无法启动。


一、解决tasktracker存在,但无法reduce的问题


看了一下50030的jobtracker页面,发现被停机的三台服务器主机名错误。被关机的服务器重新启动后,jobtracker里面的主机名列表有服务器名称变成了什么bta.net.cn。这明显是主机名被改了,hadoop在跟踪tasktracker的时候无法做内部的DNS解析,结果转到了外网的DNS上面。登上这三台服务器,发现果然bash提示符上显示的hostname被改掉了,变成了OPS自己起的名字叫什么web30。查看/etc/hosts文件,没有错误。那么用root账户执行 "hostname hadoop-node-xx",用以将主机名改回原来的。退出root,再重新登录,切换root,主机名变更完成。


之所以要执行退出并重新登录。是因为,即使你在当前终端下变更了hostname,但这时在当前root终端下,仍然认为hostname是web30。这时即便你用hadoop账户启动hadoop,也会认为主机名是web30。所以必须退出当前TTY,重新切换root和hadoop,主机名才会正常。


修改主机名后,切换到hadoop用户,启动hadoop,正常启动。提示log文件为hadoop-hadoop-tasktracker-hadoop-node-xx.log。所以这里有个小技巧,查看hadoop创建的日志名字,是可以判断你是否正确设置了hostname。当然,绝对不能一下停3台。轮流停止3台服务器的tasktracker,并重新启动。jobtracker中的主机列表显示正常,reduce可以正常进行了。


二、解决单个datanode无法启动的问题。


这里分为两个小问题。


1. datanode曾错误的用root账户启动过,导致文件权限被变更。


经询问,OPS开机后,同事没有切换到hadoop用户启动datanode,而是在这个节点上用root账户启动的了datanode。发现弄错了之后,然后又停掉了切换到hadoop用户启动,就发现无法启动了。


通过观察日志发现,datanode日志大量报出Java.IO的exception,很乱,但究其根源,是访问blk_xxxx...块permission denied。所以立刻定位问题,是由于使用root账户启动,硬盘中的blk._xxxx..文件被置为了仅root用户读写权限造成的。于是在错误变更权限的硬盘上执行 "chown -R hadoop:hadoop *" 即可。重新启动datanode,正常启动。


2. 正常启动只能支持2-3分钟,然后datanode就又挂了。


先tail -f 打开datanode日志,然后启动datanode。日志大量报,Scheduling block blk_xxxx... but block is valid。大概是这话把,刷的太快记不清了。意思就是说,计划放置某某block,但是该block存在并合法,所以放弃。根据hadoop工作原理分析,是namenode需要往datanode上写入数据,但是分配的块名称在该节点上已经存在,并且数据校验合法,所以拒绝写入并放弃,同样的错误超过该datanode的容许范围,则挂掉了。那么问题也同样出在root账户启动上,root账户启动之后,正常工作了一段时间。并以root权限放置了一些block在硬盘上,问题1里面将这些block置为了hadoop权限。但namenode认为这些文件已经不存在了,所以需要replication,但是replication过程中发现这些文件又存在,并且合法。所以就挂掉了。


问题的解决就很简单了,删除掉一些报错的block文件,datanode正常启动没有问题。再做一下balance,集群又跑的嗖嗖的。


集群配置--注意事项

 

1. 将完整的/etc/hosts文件放置在每台服务器上,hadoop的域名和IP转换要用到hosts文件

 

2. 请确保hadoop所绑定使用的端口没有被防火墙所拦截。

 

3. 请确保集群中各服务器间网络连接正常

 

4. 在几个相关的配置文件中写入了正确主机名或IP信息

 

 

 安装和配置的FAQ

 

是不是一定需要SSH免密码登录?

不是的,集群状况下Hadoop并不是必须做ssh密钥,除非需要单点启动

 

是不是一定要做LDAP?

不是的,LDAP是在做大集群管理时可以方便的管理服务器集群,并非给Hadoop专用的。

 

Hadoop对硬件的要求?

当然是越高越好。

我们 NN 96Gmem,2TBx4,8coreCPU

DN 32Gmem,2TBx4,8~16coreCPU

 

 运维故障分析与解决(一)

 

ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Incompatible namespaceIDs in /home/hadoop/tmp/dfs/data: namenode namespaceID = 39895076; datanode namespaceID = 1030326122

 

原因: namenode 被重新格式化,datanode数据版本与namenode不一致

解决: 1.删除datanode所有文件

2.修改datanode dfs/data/current/VERSION与namenode相同

 

 运维故障分析与解决(二)

 

ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: DatanodeRegistration(192.168.2.19:50010, storageID=DS-1082898260-202.106.199.39-50010-1348575582644, infoPort=50075, ipcPort=50020):DataXceiveServer: Exiting due to:java.lang.OutOfMemoryError: Java heap space

(注:上面这个ERROR并不一定全会发生,有时会出现无ERROR出现datanode就关闭的情况)

ERROR org.apache.hadoop.mapred.TaskTracker: Caught exception: java.io.IOException: Call to hadoopmaster/192.168.1.43:9001 failed on local exception: java.io.IOException: Connection reset by peer

 

原因: 常规数据交换量过大,导致通信故障datanode无法连接namenode

任务数据交换量过大,导致tasktracker与jobtracker通信故障

解决: 1.增大带宽

2.配置机架感知脚本topology.script.file.name

3.关闭均衡器

 

 运维故障分析与解决(四)

 

ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: org.apache.hadoop.util.DiskChecker$DiskError

Exception: Invalid value for volsFailed : 3 , Volumes tolerated : 0

 

原因: 磁盘损坏

解决: 关机换硬盘,2台以内服务器损坏无需关心数据丢失,hadoop存储策略以服务器为单位,不以硬盘为单位

 

 运维故障分析与解决(五)

 

2012-09-25 20:19:42,634 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: dnRegistration = DatanodeRegistration(bt-199-039.bta.net.cn:50010, storageID=, infoPort=50075, ipcPort=50020)

 

原因: 主机名转换错误,datanode无法启动

解决: 设置hostname和/etc/sysconfig/network,然后重启datanode

 

 运维故障分析与解决(六)

 

Hive查询FileNotFound Exception

 

原因: 文件不存在错误

故障一:文件的确不存在

故障二:权限问题导致数据没有正确insert写入到hive读取路径

解决: dfs.permissions = false或设置hive读取路径正确的可写权限。

 

 运维故障分析与解决(七)

 

INFO org.apache.hadoop.hdfs.server.datanode.DataNode: writeBlock blk_-8336485569098955809_2093928 received exception java.io.IOException: Permission denied

 

原因: 之前用错误账户启动hadoop,dfs存储所使用的本地文件夹被变更用户和组,导致文件夹不可写。datanode无法启动。

解决: 切换高权限用户,将dfs存储的本地文件夹chown -R成hadoop本身用户和组,重启datanode

 


 运维和故障分析总结

 

一、遇到问题看日志,log4j的日志记录很详细。

 

二、多使用谷歌而不是百度,如果谷歌可以用的话。

 

三、多使用工具,开源工具或自己编写。

 

四、熟悉操作系统自带的工具

 

算是个比较典型的故障,磁盘满导致的task tracker无法启动。

故障是一台tasktracker挂了,怎么也起不来,报错信息如下。

 

 
 
  1. 2013-03-26 17:34:57,620 ERROR org.apache.hadoop.mapred.TaskTracker: Can not start task tracker because ENOENT: No such file or directory 
  2.         at org.apache.hadoop.io.nativeio.NativeIO.chmod(Native Method) 
  3.         at org.apache.hadoop.fs.FileUtil.execSetPermission(FileUtil.java:699) 
  4.         at org.apache.hadoop.fs.FileUtil.setPermission(FileUtil.java:654) 
  5.         at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:509) 
  6.         at org.apache.hadoop.fs.RawLocalFileSystem.mkdirs(RawLocalFileSystem.java:344) 
  7.         at org.apache.hadoop.fs.FilterFileSystem.mkdirs(FilterFileSystem.java:189) 
  8.         at org.apache.hadoop.mapred.TaskTracker.initialize(TaskTracker.java:723) 
  9.         at org.apache.hadoop.mapred.TaskTracker.<init>(TaskTracker.java:1459) 
  10.         at org.apache.hadoop.mapred.TaskTracker.main(TaskTracker.java:3742) 
  11.  
  12. 2013-03-26 17:34:57,621 INFO org.apache.hadoop.mapred.TaskTracker: SHUTDOWN_MSG:  
  13. /************************************************************ 
  14. SHUTDOWN_MSG: Shutting down TaskTracker at hadoop-node-51/192.168.1.51 
  15. ************************************************************/ 

从表面上看,这是一个找不到文件的错误,下面还报了一堆跟创建目录和权限设置相关的错误。然后翻看了相关的源码,发现跟这些都没关系。

上google搜了一圈也没有什么斩获,都是与此无关的报错。

按照报错是权限设置的问题进行分析,以为是有人不小心改了mapred文件夹下的文件的权限,导致hadoop无法创建文件夹和读取文件造成的。于是去mapred文件夹查看,发现权限都是正确的。但是还是强行chown了一遍,但是没起作用。tt仍然起不来。

后来看了一下df,发现几块硬盘中的一块100%了,完全一点空间都不剩。进去看了一下,是因为有人在跑任务的时候,把map/reduce中间结果的临时数据文件扔到了那块硬盘里,也没有及时清理,所以导致磁盘满了。

让相关人员清理了中间文件,task tracker立刻就正常启动。

 

这个报错是比较神奇的,按说跟磁盘相关的事情,hadoop起码应该报一个DiskChecker的故障,但是却报了一个找不到文件的故障。一方面说明hadoop的有些报错调用的exception并不完全准确,在设置了dfs保留分区的情况下,硬盘满了,报错是跟硬盘无关的反而报了权限错误。一方面也说明运维hadoop的人需要拓宽思路,有时候一件事表象,不代表这件事背后的原因就是这样的,一定要去找到那个truth。




  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值