datenode节点超时时间设置，Hadoop启动不正常,HDFS冗余数据块的自动删除,NameNode安全模式问题,ntp时间服务同步,机架感知配置

在日常维护hadoop集群的过程中发现这样一种情况：

         某个节点由于网络故障或者DataNode进程死亡，被NameNode判定为死亡，HDFS马上自动开始数据块的容错拷贝；当该节点重新添加到集群中时，由于该节点上的数据其实并没有损坏，所以造成了HDFS上某些block的备份数超过了设定的备份数。通过观察发现，这些多余的数据块经过很长的一段时间才会被完全删除掉，那么这个时间取决于什么呢？

该时间的长短跟数据块报告的间隔时间有关。Datanode会定期将当前该结点上所有的BLOCK信息报告给Namenode，

         参数dfs.blockreport.intervalMsec就是控制这个报告间隔的参数。

         hdfs-site.xml文件中有一个参数：

         其中3600000为默认设置，3600000毫秒，即1个小时，也就是说，块报告的时间间隔为1个小时，所以经过了很长

         时间这些多余的块才被删除掉。通过实际测试发现，当把该参数调整的稍小一点的时候（60秒），多余的数据块

         确实很快就被删除了。

4.NameNode安全模式问题

当namenode发现集群中的block丢失数量达到一个阀值时，namenode就进入安全模式状态，不再接受客户端的数据更新请求

在正常情况下，namenode也有可能进入安全模式：

         集群启动时（namenode启动时）必定会进入安全模式，然后过一段时间会自动退出安全模式（原因是datanode汇报的过程有一段持续时间）

也确实有异常情况下导致的安全模式

         原因：block确实有缺失

         措施：可以手动让namenode退出安全模式，bin/hdfsdfsadmin -safemode leave

                     或者：调整safemode门限值：  dfs.safemode.threshold.pct=0.999f

5.ntp时间服务同步

第一种方式：同步到网络时间服务器

 #ntpdate time.windows.com

将硬件时间设置为当前系统时间。

#hwclock –w

加入crontab：   

30 8 * * * root /usr/sbin/ntpdate192.168.0.1; /sbin/hwclock -w 每天的8:30将进行一次时间同步。

重启crond服务：

service crond restart

第二种方式：同步到局域网内部的一台时间同步服务器

一、搭建时间同步服务器

1、编译安装ntp server

rpm -qa | grep ntp

若没有找到，则说明没有安装ntp包，从光盘上找到ntp包，使用

rpm -Uvh ntp***.rpm

进行安装

2、修改ntp.conf配置文件

vi /etc/ntp.conf

①、第一种配置：允许任何IP的客户机都可以进行时间同步

将“restrict default nomodify notrap noquery”这行修改成：

restrict default nomodify notrap

配置文件示例：/etc/ntp.conf

②、第二种配置：只允许192.168.211.***网段的客户机进行时间同步

在restrict default nomodify notrap noquery（表示默认拒绝所有IP的时间同步）之后增加一行：

restrict 192.168.211.0 mask 255.255.255.0nomodify notrap

3、启动ntp服务

service ntpd start

开机启动服务

chkconfig ntpd on

4、ntpd启动后，客户机要等几分钟再与其进行时间同步，否则会提示“no server suitable for synchronization found”错误。

二、配置时间同步客户机

手工执行 ntpdate <ntp server> 来同步

或者利用crontab来执行

crontab -e

0 21 * * * ntpdate 192.168.211.22 >>/root/ntpdate.log 2>&1

每天晚上9点进行同步

附：

当用ntpdate -d 来查询时会发现导致 no server suitable for synchronization found 的错误的信息有以下2个：

错误1.Server dropped: Strata too high

在ntp客户端运行ntpdate serverIP，出现no server suitable for synchronization found的错误。

在ntp客户端用ntpdate –d serverIP查看，发现有“Server dropped: strata too high”的错误，并且显示“stratum 16”。而正常情况下stratum这个值得范围是“0~15”。

这是因为NTP server还没有和其自身或者它的server同步上。

以下的定义是让NTP Server和其自身保持同步，如果在/ntp.conf中定义的server都不可用时，将使用local时间作为ntp服务提供给ntp客户端。

server 127.127.1.0

fudge 127.127.1.0 stratum 8

在ntp server上重新启动ntp服务后，ntp server自身或者与其server的同步的需要一个时间段，这个过程可能是5分钟，在这个时间之内在客户端运行ntpdate命令时会产生no server suitable for synchronization found的错误。

那么如何知道何时ntp server完成了和自身同步的过程呢？

在ntp server上使用命令：

# watch ntpq -p

出现画面：

Every 2.0s: ntpq -p                                                                                                            Thu Jul 10 02:28:32 2008

    remote           refid      st t when poll reach   delay  offset jitter

==============================================================================

192.168.30.22   LOCAL(0)         8 u  22   64    1   2.113 179133.   0.001

LOCAL(0)        LOCAL(0)        10 l  21   64    1   0.000   0.000  0.001

注意LOCAL的这个就是与自身同步的ntp server。

注意reach这个值，在启动ntp server服务后，这个值就从0开始不断增加，当增加到17的时候，从0到17是5次的变更，每一次是poll的值的秒数，是64秒*5=320秒的时间。

如果之后从ntp客户端同步ntp server还失败的话，用ntpdate –d来查询详细错误信息，再做判断。

错误2.Server dropped: no data

从客户端执行netdate –d时有错误信息如下：

transmit(192.168.30.22)transmit(192.168.30.22)

transmit(192.168.30.22)

transmit(192.168.30.22)

transmit(192.168.30.22)

192.168.30.22: Server dropped: no data

server 192.168.30.22, port 123

.....

28 Jul 17:42:24 ntpdate[14148]: no serversuitable for synchronization found出现这个问题的原因可能有2：

1。检查ntp的版本，如果你使用的是ntp4.2（包括4.2）之后的版本，在restrict的定义中使用了notrust的话，会导致以上错误。

使用以下命令检查ntp的版本：

# ntpq -c version

下面是来自ntp官方网站的说明：

The behavior of notrust changed betweenversions 4.1 and 4.2.

In 4.1 (and earlier) notrust meant"Don't trust this host/subnet for time".

In 4.2 (and later) notrust means"Ignore all NTP packets that are not cryptographicallyauthenticated." This forces remote time servers to authenticate themselvesto your (client) ntpd

解决：

把notrust去掉。

2。检查ntp server的防火墙。可能是server的防火墙屏蔽了upd123端口。

可以用命令

#service iptables stop

来关掉iptables服务后再尝试从ntp客户端的同步，如果成功，证明是防火墙的问题，需要更改iptables的设置。

6.机架感知配置

Hadoop机架感知

1.背景

     Hadoop在设计时考虑到数据的安全与高效，数据文件默认在HDFS上存放三份，存储策略为本地一份，同机架内其它某一节点上一份，不同机架的某一节点上一份。这样如果本地数据损坏，节点可以从同一机架内的相邻节点拿到数据，速度肯定比从跨机架节点上拿数据要快；同时，如果整个机架的网络出现异常，也能保证在其它机架的节点上找到数据。为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。如果在读取程序的同一个机架上有一个副本，那么就读取该副本。如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。那么Hadoop是如何确定任意两个节点是位于同一机架，还是跨机架的呢？答案就是机架感知。

     默认情况下，hadoop的机架感知是没有被启用的。所以，在通常情况下，hadoop集群的HDFS在选机器的时候，是随机选择的，也就是说，很有可能在写数据时，hadoop将第一块数据block1写到了rack1上，然后随机的选择下将block2写入到了rack2下，此时两个rack之间产生了数据传输的流量，再接下来，在随机的情况下，又将block3重新又写回了rack1，此时，两个rack之间又产生了一次数据流量。在job处理的数据量非常的大，或者往hadoop推送的数据量非常大的时候，这种情况会造成rack之间的网络流量成倍的上升，成为性能的瓶颈，进而影响作业的性能以至于整个集群的服务

2.配置

  默认情况下，namenode启动时候日志是这样的：

2013-09-22 17:27:26,423 INFOorg.apache.hadoop.net.NetworkTopology: Adding a new node:  /default-rack/ 192.168.147.92:50010

每个IP 对应的机架ID都是 /default-rack ，说明hadoop的机架感知没有被启用。

要将hadoop机架感知的功能启用，配置非常简单，在 NameNode所在节点的/home/bigdata/apps/hadoop/etc/hadoop的core-site.xml配置文件中配置一个选项:

<property>

 <name>topology.script.file.name</name>

 <value>/home/bigdata/apps/hadoop/etc/hadoop/topology.sh</value>

</property>

      这个配置选项的value指定为一个可执行程序，通常为一个脚本，该脚本接受一个参数，输出一个值。接受的参数通常为某台datanode机器的ip地址，而输出的值通常为该ip地址对应的datanode所在的rack，例如”/rack1”。Namenode启动时，会判断该配置选项是否为空，如果非空，则表示已经启用机架感知的配置，此时namenode会根据配置寻找该脚本，并在接收到每一个datanode的heartbeat时，将该datanode的ip地址作为参数传给该脚本运行，并将得到的输出作为该datanode所属的机架ID，保存到内存的一个map中.

     至于脚本的编写，就需要将真实的网络拓朴和机架信息了解清楚后，通过该脚本能够将机器的ip地址和机器名正确的映射到相应的机架上去。一个简单的实现如下：

#!/bin/bash

HADOOP_CONF=/home/bigdata/apps/hadoop/etc/hadoop

while [ $# -gt 0 ] ; do

 nodeArg=$1

 exec<${HADOOP_CONF}/topology.data

 result=""

  whileread line ; do

   ar=( $line )

   if [ "${ar[0]}" = "$nodeArg" ]||["${ar[1]}" = "$nodeArg" ]; then

     result="${ar[2]}"

   fi

 done

 shift

  if[ -z "$result" ] ; then

   echo -n "/default-rack"

 else

   echo -n "$result"

  fi

 done

topology.data,格式为：节点（ip或主机名） /交换机xx/机架xx

192.168.147.91 tbe192168147091 /dc1/rack1

192.168.147.92 tbe192168147092 /dc1/rack1

192.168.147.93 tbe192168147093 /dc1/rack2

192.168.147.94 tbe192168147094 /dc1/rack3

192.168.147.95 tbe192168147095 /dc1/rack3

192.168.147.96 tbe192168147096 /dc1/rack3

需要注意的是，在Namenode上，该文件中的节点必须使用IP，使用主机名无效，而Jobtracker上，该文件中的节点必须使用主机名，使用IP无效,所以，最好ip和主机名都配上。

这样配置后，namenode启动时候日志是这样的：

2013-09-23 17:16:27,272 INFOorg.apache.hadoop.net.NetworkTopology: Adding a new node:  /dc1/rack3/ 192.168.147.94:50010

说明hadoop的机架感知已经被启用了。

查看HADOOP机架信息命令: 

./hadoop dfsadmin -printTopology

Rack: /dc1/rack1

  192.168.147.91:50010 (tbe192168147091)

  192.168.147.92:50010 (tbe192168147092)

Rack: /dc1/rack2

  192.168.147.93:50010 (tbe192168147093)

Rack: /dc1/rack3

  192.168.147.94:50010 (tbe192168147094)

  192.168.147.95:50010 (tbe192168147095)

  192.168.147.96:50010 (tbe192168147096)

3.增加数据节点，不重启NameNode

 假设Hadoop集群在192.168.147.68上部署了NameNode和DataNode,启用了机架感知，执行bin/hadoopdfsadmin -printTopology看到的结果：

Rack: /dc1/rack1

  192.168.147.68:50010 (dbj68)

现在想增加一个物理位置在rack2的数据节点192.168.147.69到集群中，不重启NameNode。

首先，修改NameNode节点的topology.data的配置，加入:192.168.147.69 dbj69 /dc1/rack2,保存。

192.168.147.68 dbj68 /dc1/rack1

192.168.147.69 dbj69 /dc1/rack2

然后，sbin/hadoop-daemons.sh start datanode启动数据节点dbj69,任意节点执行bin/hadoopdfsadmin -printTopology 看到的结果：

Rack: /dc1/rack1

  192.168.147.68:50010 (dbj68)

Rack: /dc1/rack2

  192.168.147.69:50010 (dbj69)

说明hadoop已经感知到了新加入的节点dbj69。

注意：如果不将dbj69的配置加入到topology.data中，执行sbin/hadoop-daemons.sh start datanode启动数据节点dbj69，datanode日志中会有异常发生，导致dbj69启动不成功。

2013-11-21 10:51:33,502 FATALorg.apache.hadoop.hdfs.server.datanode.DataNode: Initialization failed forblock pool Block pool BP-1732631201-192.168.147.68-1385000665316 (storage idDS-878525145-192.168.147.69-50010-1385002292231) service todbj68/192.168.147.68:9000

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.net.NetworkTopology$InvalidTopologyException):Invalid network topology. You cannot have a rack and a non-rack node at thesame level of the network topology.

  atorg.apache.hadoop.net.NetworkTopology.add(NetworkTopology.java:382)

  atorg.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode(DatanodeManager.java:746)

  atorg.apache.hadoop.hdfs.server.namenode.FSNamesystem.registerDatanode(FSNamesystem.java:3498)

  atorg.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode(NameNodeRpcServer.java:876)

  atorg.apache.hadoop.hdfs.protocolPB.DatanodeProtocolServerSideTranslatorPB.registerDatanode(DatanodeProtocolServerSideTranslatorPB.java:91)

  atorg.apache.hadoop.hdfs.protocol.proto.DatanodeProtocolProtos$DatanodeProtocolService$2.callBlockingMethod(DatanodeProtocolProtos.java:20018)

  atorg.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:453)

  atorg.apache.hadoop.ipc.RPC$Server.call(RPC.java:1002)

  atorg.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1701)

  atorg.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1697)

  atjava.security.AccessController.doPrivileged(Native Method)

  atjavax.security.auth.Subject.doAs(Subject.java:415)

  atorg.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1408)

  atorg.apache.hadoop.ipc.Server$Handler.run(Server.java:1695)

  atorg.apache.hadoop.ipc.Client.call(Client.java:1231)

  atorg.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:202)

  at$Proxy10.registerDatanode(Unknown Source)

  atsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

  atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

  atjava.lang.reflect.Method.invoke(Method.java:601)

  atorg.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:164)

  atorg.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:83)

  at$Proxy10.registerDatanode(Unknown Source)

  atorg.apache.hadoop.hdfs.protocolPB.DatanodeProtocolClientSideTranslatorPB.registerDatanode(DatanodeProtocolClientSideTranslatorPB.java:149)

  atorg.apache.hadoop.hdfs.server.datanode.BPServiceActor.register(BPServiceActor.java:619)

  atorg.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake(BPServiceActor.java:221)

  atorg.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:660)

  atjava.lang.Thread.run(Thread.java:722)

4.节点间距离计算

 有了机架感知，NameNode就可以画出下图所示的datanode网络拓扑图。D1,R1都是交换机，最底层是datanode。则H1的rackid=/D1/R1/H1，H1的parent是R1，R1的是D1。这些rackid信息可以通过topology.script.file.name配置。有了这些rackid信息就可以计算出任意两台datanode之间的距离，得到最优的存放策略，优化整个集群的网络带宽均衡以及数据最优分配。

distance(/D1/R1/H1,/D1/R1/H1)=0  相同的datanode

distance(/D1/R1/H1,/D1/R1/H2)=2  同一rack下的不同datanode

distance(/D1/R1/H1,/D1/R2/H4)=4  同一IDC下的不同datanode

distance(/D1/R1/H1,/D2/R3/H7)=6  不同IDC下的datanode