[TOC] # 機架感知配置 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 INFO org.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="" while read 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 INFO org.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/hadoop dfsadmin -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/hadoop dfsadmin -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 FATAL org.apache.hadoop.hdfs.server.datanode.DataNode: Initialization failed for block pool Block pool BP-1732631201-192.168.147.68-1385000665316 (storage id DS-878525145-192.168.147.69-50010-1385002292231) service to dbj68/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 the same level of the network topology. at org.apache.hadoop.net.NetworkTopology.add(NetworkTopology.java:382) at org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode(DatanodeManager.java:746) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.registerDatanode(FSNamesystem.java:3498) at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode(NameNodeRpcServer.java:876) at org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolServerSideTranslatorPB.registerDatanode(DatanodeProtocolServerSideTranslatorPB.java:91) at org.apache.hadoop.hdfs.protocol.proto.DatanodeProtocolProtos$DatanodeProtocolService$2.callBlockingMethod(DatanodeProtocolProtos.java:20018) at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:453) at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1002) at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1701) at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1697) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:415) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1408) at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1695) at org.apache.hadoop.ipc.Client.call(Client.java:1231) at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:202) at $Proxy10.registerDatanode(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:164) at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:83) at $Proxy10.registerDatanode(Unknown Source) at org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolClientSideTranslatorPB.registerDatanode(DatanodeProtocolClientSideTranslatorPB.java:149) at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.register(BPServiceActor.java:619) at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake(BPServiceActor.java:221) at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:660) at java.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 ~~~ # datanode節點超時時間設置 hadoop datanode節點超時時間設置 datanode進程死亡或者網絡故障造成datanode無法與namenode通信，namenode不會立即把該節點判定為死亡，要經過一段時間，這段時間暫稱作超時時長。HDFS默認的超時時長為10分鐘+30秒。如果定義超時時間為timeout，則超時時長的計算公式為： `timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval` 而默認的heartbeat.recheck.interval 大小為5分鐘，dfs.heartbeat.interval默認為3秒。 需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的單位為毫秒，dfs.heartbeat.interval的單位為秒。所以，舉個例子，如果heartbeat.recheck.interval設置為5000（毫秒），dfs.heartbeat.interval設置為3（秒，默認），則總的超時時間為40秒。 hdfs-site.xml中的參數設置格式： ~~~ <property> <name>heartbeat.recheck.interval</name> <value>2000</value> </property> <property> <name>dfs.heartbeat.interval</name> <value>1</value> </property> ~~~ # hadoop安裝部署問題 hadoop的日志目錄（/home/hadoop/app/hadoop-2.6.4/logs） hadoop啟動不正常 用瀏覽器訪問namenode的50070端口，不正常，需要診斷問題出在哪里： a、在服務器的終端命令行使用jps查看相關進程 （namenode1個節點 datanode3個節點 secondary namenode1個節點） b、如果已經知道了啟動失敗的服務進程，進入到相關進程的日志目錄下，查看日志，分析異常的原因 1）配置文件出錯，saxparser exception； ——找到錯誤提示中所指出的配置文件檢查修改即可 2）unknown host——主機名不認識，配置/etc/hosts文件即可，或者是配置文件中所用主機名跟實際不一致 （注：在配置文件中，統一使用主機名，而不要用ip地址） 3）directory 訪問異常—— 檢查namenode的工作目錄，看權限是否正常 start-dfs.sh啟動后，發現有datanode啟動不正常 a）查看datanode的日志，看是否有異常，如果沒有異常，手動將datanode啟動起來 sbin/hadoop-daemon.sh start datanode b）很有可能是slaves文件中就沒有列出需要啟動的datanode c）排除上述兩種情況后，基本上，能在日志中看到異常信息： 1、配置文件 2、ssh免密登陸沒有配置好 3、datanode的身份標識跟namenode的集群身份標識不一致（刪掉datanode的工作目錄） # HDFS冗余數據塊的自動刪除 在日常維護hadoop集群的過程中發現這樣一種情況： 某個節點由于網絡故障或者DataNode進程死亡，被NameNode判定為死亡，HDFS馬上自動開始數據塊的容錯拷貝；當該節點重新添加到集群中時，由于該節點上的數據其實并沒有損壞，所以造成了HDFS上某些block的備份數超過了設定的備份數。通過觀察發現，這些多余的數據塊經過很長的一段時間才會被完全刪除掉，那么這個時間取決于什么呢？ 該時間的長短跟數據塊報告的間隔時間有關。Datanode會定期將當前該結點上所有的BLOCK信息報告給Namenode，參數dfs.blockreport.intervalMsec就是控制這個報告間隔的參數。 hdfs-site.xml文件中有一個參數： ~~~ <property> <name>dfs.blockreport.intervalMsec</name> <value>3600000</value> <description>Determines block reporting interval in milliseconds.</description> </property> ~~~ 其中3600000為默認設置，3600000毫秒，即1個小時，也就是說，塊報告的時間間隔為1個小時，所以經過了很長時間這些多余的塊才被刪除掉。通過實際測試發現，當把該參數調整的稍小一點的時候（60秒），多余的數據塊確實很快就被刪除了。 當namenode發現集群中的block丟失數量達到一個閥值時，namenode就進入安全模式狀態，不再接受客戶端的數據更新請求 # namenode安全模式 在正常情況下，namenode也有可能進入安全模式： 集群啟動時（namenode啟動時）必定會進入安全模式，然后過一段時間會自動退出安全模式（原因是datanode匯報的過程有一段持續時間） 也確實有異常情況下導致的安全模式 原因：block確實有缺失 措施：可以手動讓namenode退出安全模式，`bin/hdfs dfsadmin -safemode leave` 或者：調整safemode門限值： `dfs.safemode.threshold.pct=0.999f` # ntp時間服務同步 第一種方式：同步到網絡時間服務器 ~~~ # ntpdate time.windows.com ~~~ 將硬件時間設置為當前系統時間。 ~~~ #hwclock –w ~~~ 加入crontab： `30 8 * * * root /usr/sbin/ntpdate 192.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.0 nomodify 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 server suitable for synchronization found`出現這個問題的原因可能有2： 1. 檢查ntp的版本，如果你使用的是ntp4.2（包括4.2）之后的版本，在restrict的定義中使用了notrust的話，會導致以上錯誤。 使用以下命令檢查ntp的版本： `# ntpq -c version` 下面是來自ntp官方網站的說明： ~~~ The behavior of notrust changed between versions 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 cryptographically authenticated." This forces remote time servers to authenticate themselves to your (client) ntpd ~~~ 解決： 把notrust去掉。 2. 檢查ntp server的防火墻。可能是server的防火墻屏蔽了upd 123端口。 可以用命令 ~~~ #service iptables stop ~~~ 來關掉iptables服務后再嘗試從ntp客戶端的同步，如果成功，證明是防火墻的問題，需要更改iptables的設置。 # java.io.IOException: HADOOP_HOME or hadoop.home.dir are not set.的問題 來自https://www.cnblogs.com/huxinga/p/6875929.html 報錯如下： ~~~ 300 [main] DEBUG org.apache.hadoop.util.Shell - Failed to detect a valid hadoop home directory java.io.IOException: HADOOP_HOME or hadoop.home.dir are not set ~~~ **解決辦法一：** ~~~ 根據 http://blog.csdn.net/baidu_19473529/article/details/54693523 配置hadoop_home變量 下載winutils地址https://github.com/srccodes/hadoop-common-2.2.0-bin下載解壓 ~~~  依然報相同的錯誤 **解決辦法二：** 在java程序中加入 ~~~ System.setProperty("hadoop.home.dir", "/usr/local/hadoop-2.6.0"); ~~~ 依然報錯 **解決辦法三：** 根據該提示：  依然報錯 今天早上再次執行該程序，將上傳到HDFS部分的代碼給注釋掉后發現日志報錯信息如下： ~~~ 132 [main] DEBUG org.apache.hadoop.util.NativeCodeLoader - Trying to load the custom-built native-hadoop library... 134 [main] DEBUG org.apache.hadoop.util.NativeCodeLoader - Failed to load native-hadoop with error: java.lang.UnsatisfiedLinkError: no hadoop in java.library.path ~~~ 1）check Hadoop library： ~~~ root@Ubuntu-1:/usr/local/hadoop-2.6.0/lib/native# file libhadoop.so.1.0.0 ~~~ ~~~ It's 64-bite library ~~~ 2）Try adding the HADOOP_OPTS environment variable: ~~~ root@Ubuntu-1:~# vi /etc/profile //environment variable export HADOOP_OPTS="-Djava.library.path=${HADOOP_HOME}/lib/native/" It doesn't work, and reports the same error. ~~~ 3）Try adding the HADOOP_OPTS and HADOOP_COMMON_LIB_NATIVE_DIR environment variable: ~~~ export HADOOP_COMMON_LIB_NATIVE_DIR=${HADOOP_HOME}/lib/native export HADOOP_OPTS="-Djava.library.path=${HADOOP_HOME}/lib/" It still doesn't work, and reports the same error. ~~~ 4）Adding the Hadoop library into LD_LIBRARY_PATH ~~~ root@Ubuntu-1:~# vi .bashrc export LD_LIBRARY_PATH=/usr/local/hadoop/lib/native/:$LD_LIBRARY_PATH It doesn't work, and reports the same error. ~~~ 5）append word native to HADOOP_OPTS like this ~~~ export HADOOP_OPTS="$HADOOP_OPTS -Djava.library.path=$HADOOP_HOME/lib/native" It doesn't work, and reports the same error. ~~~ win下依舊無法使用java代碼上傳文件到HDFS copy了一份hadoop-2.6.0文件到本機，更改bin目錄和path ，顯示無效的path，遂更改回去 今天早上開機 試了一下 發現它已經好了 其實上述的設置已經可以解決大部分遇到這類問題的人群