cdh安裝注意點
ntp命令:
/bin/systemctl restart ntpd.service 開啟ntp
systemctl enable ntpd 設定開機自啟
systemctl status ntpd 檢視狀態
ntpstat 檢視狀態
Yarn服務無法啟動1
有一次同事拿著我寫的安裝手冊去安裝CDH,結果在啟動Yarn服務這一步一直失敗,而且沒有log檔案生成,也就是根本就不知道是什麼錯誤。
經過百般嘗試後依然無果。於是問同事是不是嚴格按照我的文件上來的,同事說是。結果又嘗試和排查了很多次後,同事突然說,我想起來了,打通ssh沒按照你的來,你是生成key了分發到其它機器,其實有種口令直接就能分發key到其它機器,不用在本機生成。比如這樣ssh-copy-id -p 8282 -i ~/.ssh/id_rsa.pub
然後,我懷著崩潰的心情告訴了他,哥哥,master機器也要能免密碼登入自己啊!!
最後,做好master機器免登入自己後即可成功安裝。
Yarn服務無法啟動2
報錯資訊:
- Error found before invoking supervisord: dictionary update sequence element #78 has length1; 2 is required
複製程式碼
這個錯誤是CM的一個bug,解決方法為修改/opt/cm-5.3.0/lib64/cmf/agent/src/cmf/util.py檔案。將其中的程式碼:
- pipe = subprocess.Popen(['/bin/bash', '-c', ". %s; %s; env" % (path, command)],
- stdout=subprocess.PIPE, env=caller_env)
複製程式碼
修改為:
- pipe = subprocess.Popen(['/bin/bash', '-c', ". %s; %s; env | grep -v { | grep -v }" % (path, command)],
- stdout=subprocess.PIPE, env=caller_env)
複製程式碼
然後重啟所有Agent即可。
HDFS服務無法啟動
若HDFS服務無法啟動,通常是第二次嘗試安裝中才會遇到,這是隻要將上次安裝時設定的Namenode和DataNode資料夾下的資料全部刪除即可。
Host Monitor和Service Monitor服務無法啟動
這個錯誤的報錯資訊如下:
- 2015-03-23 16:08:10,518 ERROR com.cloudera.cmon.firehose.Main: Error creating LevelDB subject record store.
- java.lang.IllegalStateException
- at com.google.common.base.Preconditions.checkState(Preconditions.java:133)
- at com.cloudera.cmon.tstore.leveldb.LDBResourceManager.register(LDBResourceManager.java:273)
- at com.cloudera.cmon.tstore.leveldb.LDBPartitionManager.<init>(LDBPartitionManager.java:270)
- at com.cloudera.cmon.tstore.leveldb.LDBPartitionManager.createLDBPartitionManager(LDBPartitionManager.java:196)
- at com.cloudera.cmon.tstore.leveldb.LDBTSSubjectRecordTable.create(LDBTSSubjectRecordTable.java:84)
- at com.cloudera.cmon.tstore.leveldb.LDBSubjectRecordStore.create(LDBSubjectRecordStore.java:197)
- at com.cloudera.cmon.tstore.leveldb.LDBSubjectRecordStore.create(LDBSubjectRecordStore.java:178)
- at com.cloudera.cmon.firehose.Main.main(Main.java:517)
複製程式碼
初步一看,應該是這個兩個服務所用的LevelDB檔案沒有正確的建立,於是刪除/var/lib下兩者的目錄並重試,還是失敗。於是嘗試在其它機器上安裝這2個服務,怎奈每次後退到選擇安裝機器的那一步時,關於Host Monitor和Service Monitor設定的專案就不見了,就算出現了且設定到其它機器上也不會安裝在其它機器上,還是安裝在master機器上。
後在google論壇上看到有人說可能是記憶體設定過低或者“程序開啟最大檔案數”過低造成的。考慮到開啟控制代碼這步操作在安裝CDH之前就已經進行且重來沒有出過問題,於是就沒有考慮。結果嘗試數次過後還是不行。
最後無奈中看了下控制代碼數ulimit -n,發現居然是1024。然後登入其它slave節點檢視,發現都是配置的65535。這是什麼情況?同樣的配置,會出現不同的結果。最後查看了ulimit -u等配置,發現除了master節點的控制代碼數配置沒有生效以外,其它的都生效了。
最後無意中嘗試了下telnet登入master節點,發現ulimit -n的結果居然是65535。好吧,至此終於知道原因了。master節點由於有DCN網路的IP,所以為了應對安全掃描安裝了沒有心臟漏血漏洞的高版本ssh,而其它slave節點並沒有安裝。看來是ssh登入造成的開啟控制代碼數出現了異常。只不過我到現在為止都不知道為何系統級別的設定會受到登入方式的影響。
解決方法:由於只有控制代碼數配置未生效,於是在.bashrc中添加了ulimit -HSn 65535。重新安裝,終於成功啟動Host Monitor和Service Monitor服務。
8888,50070,8088等埠無法訪問
現象:master機器通過wget可以正確的得到頁面,但是外網卻無法獲取,而且網路的設定是正確的。
檢視端口占用發現這些埠全部繫結在內網IP上而不是0.0.0.0。
解決方法:去各自的配置檔案中配置即可,選擇繫結至0.0.0.0埠,然後重啟即可。
oozie服務啟動失敗
通常是第二次嘗試安裝中才會遇到,報錯內容大概是資料庫已存在。
解決方法:刪除/var/lib/oozie/data資料夾即可。
HUE服務啟動失敗
報錯資訊是找不到libxslt.so.1。
解決方法:yum install libxslt即可。