Hadoop运维笔记（1）

本帖最后由 xioaxu790 于 2015-2-5 20:27 编辑

问题导读
1、如何理解Hadoop运维？
2、频繁出现Deadnode是什么原因？
3、datanode报错如何解决？

（一）Hadoop运维笔记之 Datanode的Last Contact值异常增大导致频繁出现Deadnode
我们在线上采用的是CDH的Hadoop发行版，但从CDH3迁移到CDH5之后，Bug层出不穷。:(

CDH5.0.x版本没有什么严重的Bug，但是Namenode之间的状态同步却有问题。
具体表现为，在需要Decommission某个节点时，必须在Active Namenode上操作，如果在Standby Namenode上操作，其Decommissioning状态不会同步到Active Namenode上，也不会真正的Decommissioning。
而即使在Active Namenode上操作的话，Decommissioned状态也不会同步到Standby Namenode；
通过升级到CDH5.1.0之后，我们解决了这个问题，但没想到的是，后面版本的Bug会更加严重。

在CDH5.1.0版本中，有严重的snapshot操作导致edits记录紊乱使Namenode崩溃的问题，在定位到了其匹配的Bug后，我们只能继续通过升级到CDH5.2.0解决这个问题。

但CDH5.2.0又引入了一个新的Bug，就是Namenode与Datanode的心跳会因为正在运行的job而被block，虽然Datanode的负载并不高，但仍然会导致Last Contact值不断增大。
而默认的心跳超时时间是630秒，超过这个数值之后，Namenode就自动将Datanode列入Deadnodes当中。
我们所有的开发和运维花费了一周的时间做各种分析和调试，都没能解决这个问题，也没有找到与问题完全匹配的Bug。
最后，因为一个同行的哥们儿也遇到了相同的问题，他通过升级到CDH5.3.0将问题解决了。
于是，我们在无计可施的情况下，也升级到了CDH5.3.0，果然解决了Last Contact值增高的心跳问题。

于此，不得不感叹，CDH5的Bug真是多，有的还会导致非常严重的问题，但目前已经上了贼船，也就只能自求多福了。

从CDH5.2.0之前的旧版本直接升级到CDH5.3.0的文档：
http://www.cloudera.com/content/ ... r_cdh5_upgrade.html

从CDH5.2.0升级到CDH5.3.0的文档：
http://www.cloudera.com/content/ ... latest_upgrade.html

升级Hive与Oozie到CDH5.3.0对应版本的文档：
http://www.cloudera.com/content/ ... g_hive_upgrade.html
http://www.cloudera.com/content/ ... _oozie_upgrade.html

（二）Hadoop运维笔记之更换du命令降低datanode磁盘IO

背景介绍：
近期，不少datanode节点的磁盘IO比较高，主要原因还是由于job数量的增多，以及规模的增大。
但任何可以降低磁盘IO消耗的手段，我们都可以尝试一下。

比如，我们经常可以看到hdfs用户在执行"du -sk"命令：

[root@idc1-server2 ~]# ps -ef| grep "du -sk"

hdfs     17119 10336  1 00:57 ?        00:00:04 du -sk /data1/dfs/dn/current/BP-1281416642-10.100.1.2-1407274717062
hdfs     17142 10336  1 00:57 ?        00:00:03 du -sk /data5/dfs/dn/current/BP-1281416642-10.100.1.2-1407274717062
hdfs     17151 10336  1 00:57 ?        00:00:05 du -sk /data6/dfs/dn/current/BP-1281416642-10.100.1.2-1407274717062
...
复制代码

随着datanode上的数据不断增加，这样频繁的du操作，会耗时比较长，在CPU和磁盘IO很闲的时候，每次也都会耗时5秒左右，而在服务器负载比较高的时候，这样的操作就会耗时很长时间。

于是，我们便考虑通过将原有的du命令替换，并基于df命令来编写一个新的du命令来取而代之。

[root@idc1-server2 ~]# mv /usr/bin/du /usr/bin/du.orig
[root@idc1-server2 ~]# vim /usr/bin/du

#!/bin/sh

mydf=$(df -Pk $2 | grep -vE '^Filesystem|tmpfs|cdrom' | awk '{ print $3 }')
echo -e "$mydf\t$2"
[root@idc1-server2 ~]# chmod +x /usr/bin/du
复制代码

不过这样的话，统计出来的结果不就不准确了吗？
但具体情况具体应对，一般来说，Hadoop的datanode都会采用不同的磁盘并划分分区来存储数据，那么使用df统计出来的结果，误差应该是很小的。

（三）Hadoop运维笔记之 Snappy创建libhadoop.so导致datanode报错

为了解决上一篇文章中提到的Bug，我们将线上的CDH5升级到了目前最新的CDH5.2.0，但升级之后，有一部分服务器的datanode不能正常启动，报错如下：

2014-11-20 19:54:52,071 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Unexpected exception in block pool Block pool <registering> (Datanode Uuid unassigned) service to idc1-server1/10.100.1.100:8020
com.google.common.util.concurrent.ExecutionError: java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio.NativeIO.link0(Ljava/lang/String;Ljava/lang/String;)V
        at com.google.common.util.concurrent.Futures.wrapAndThrowExceptionOrError(Futures.java:1126)
        at com.google.common.util.concurrent.Futures.get(Futures.java:1048)
        at org.apache.hadoop.hdfs.server.datanode.DataStorage.linkBlocks(DataStorage.java:870)
        at org.apache.hadoop.hdfs.server.datanode.BlockPoolSliceStorage.linkAllBlocks (BlockPoolSliceStorage.java:570)
        at org.apache.hadoop.hdfs.server.datanode.BlockPoolSliceStorage.doUpgrade (BlockPoolSliceStorage.java:379)
        at org.apache.hadoop.hdfs.server.datanode.BlockPoolSliceStorage.doTransition (BlockPoolSliceStorage.java:313)
        at org.apache.hadoop.hdfs.server.datanode.BlockPoolSliceStorage.recoverTransitionRead (BlockPoolSliceStorage.java:187)
        at org.apache.hadoop.hdfs.server.datanode.DataStorage.recoverTransitionRead (DataStorage.java:309)
        at org.apache.hadoop.hdfs.server.datanode.DataNode.initStorage(DataNode.java:1109)
        at org.apache.hadoop.hdfs.server.datanode.DataNode.initBlockPool(DataNode.java:1080)
        at org.apache.hadoop.hdfs.server.datanode.BPOfferService.verifyAndSetNamespaceInfo (BPOfferService.java:320)
        at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake (BPServiceActor.java:220)
        at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:824)
        at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio.NativeIO.link0 (Ljava/lang/String;Ljava/lang/String;)V
        at org.apache.hadoop.io.nativeio.NativeIO.link0(Native Method)
        at org.apache.hadoop.io.nativeio.NativeIO.link(NativeIO.java:838)
        at org.apache.hadoop.hdfs.server.datanode.DataStorage$2.call(DataStorage.java:862)
        at org.apache.hadoop.hdfs.server.datanode.DataStorage$2.call(DataStorage.java:855)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        ... 1 more
2014-11-20 19:54:52,073 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Ending block pool service for: Block pool <registering> (Datanode Uuid unassigned) service to idc1-server1/10.100.1.100:8020
复制代码

但搜遍了Google也未能找到匹配的信息，唯一沾点边的都是一些在Windows平台上因为缺少lib导致的问题。
而在我们的环境中，只有一部分的服务器有以上问题，对比了所有Hadoop相关的软件包之后都没法发现有什么不同，这给我们分析问题带来了很大的干扰。

最后，我们尝试通过strace来跟踪datanode的进程。

yum install strace
strace -f -F -o /tmp/strace.output.txt /etc/init.d/hadoop-hdfs-datanode start
lsof | grep libhadoop.so

java 18527 hdfs mem REG 253,0 122832 270200 /usr/java/jdk1.7.0_45/jre/lib/amd64/libhadoop.so
复制代码

发现它读取了一个lib文件：/usr/java/jdk1.7.0_45/jre/lib/amd64/libhadoop.so，而其它正常的服务器的datanode进程则是读取的/usr/lib/hadoop/lib/native/libhadoop.so。
经过验证发现/usr/java/jdk1.7.0_45/jre/lib/amd64/libhadoop.so是在安装Snappy软件包时创建的，在移走了它之后，datanode终于正常启动了。

看来，虽然datanode在启动时指定了 -Djava.library.path=/usr/lib/hadoop/lib/native，但jre中的lib被载入的优先级还是要高一些。

#################################
本文转载自：http://heylinux.com/archives/3418.html