hadoop平常運維與升級總結

平常運維 升級 問題處理方法

平常運維

進程管理

因爲配置文件的更改，須要重啓生效，

或者是進程本身因某種致命緣由終止，

或者發現進程工做出現異常等狀況下，須要進行手動進程的關閉或啓動，

或者是增刪節點過程當中的須要，

進程的關閉與啓動，使用

hadoop-daemon.sh start|stop datanode/namenode/journalnode/zkfc

yarn-daemon.sh start|stop nodemanager/resourcemanager

檢查進程是否完成關閉：

jps 或者 ps –ef | grep datanode|namenode|journalnode|zkfc|nodemanager|resourcemanager

注意：要清楚本身關閉的每個進程對正在運行的集羣會產生什麼樣的影響

集羣健康檢查

hdfs fsck / 進行文件系統健康檢查，是否有塊丟失，如何處理？

hdfs fsck 也能夠用來查看你關心的某些文件的塊的分佈狀況。

Hdfs fsck /path –files –blocks –locations 能夠顯示詳細的文件，block位置等信息。

Datanodes 是否有死的節點，有可能進程還在可是狀態是不正常的。

ResourceManager的管理頁面上觀察是否有lost的nodemanager節點，查找緣由，解決。

進程日誌文件檢查：檢查其中頻繁出現的異常，從warn級別的信息中每每能發現出現異常錯誤的緣由，搜索查找緣由，修改配置文件或作其餘的調整。

新增節點

硬件安裝

1）操做系統自己的安裝，關閉防火牆，selinux

2）修改limits.conf sysctl.conf 保持一致

3）建立hadoop用戶

4）生成ssh無密鑰訪問

Root: 直接拷貝其餘系統的.ssh文件夾 整個集羣使用一個

Hadoop:生成密鑰 分發到某一固定節點，如namenode

最後從含有完整公鑰的機器上把authorizedkeys 從新分發到各節點一份

5）修改主機名與集羣保持一致，

sed –i ‘s/HOSTNAME=.*/HOSTNAME=dn1’ /etc/sysconfig/network

6）修改/etc/hosts

這個也能夠在namenode上進行，配置好新增節點的ip信息，在ssh配好後，

能夠直接分發到全部節點，不只是新增節點。

7）同步文件

假設這個節點上只運行datanode,nm之類的

從已有節點同步jdk,hadoop到相同的目錄(不用複製hadoop的日誌文件，太大無用)

(rsync –v nn1:/app/cdh23502/ /app)

從已有節點複製 .bash_profile文件到新節點，而且source .bash_profile使之生效

測試 java –version 和 hadoop version 是否正常工做

8）測試本地庫是否正常

Hadoop checknative

若是沒有安裝本地庫壓縮請安裝相應程序

建立數據盤的根目錄，並把此權限賦給hadoop用戶

9）在nn1上修改etc/hadoop/slaves，在裏面添加新增的節點hostname.

修改機架感知信息，通常是在一個文本文件裏面，經過python加載，修改完成分發。

在新增節點上啓動datanode,nodemanager等進程

10）經過 hdfs dfsadmin –report 或 在webui 上觀察datanode是否向namenode註冊成功。

必要的時候運行：hadoop dfsadmin -refreshNodes

平衡數據

Start-balancer.sh

Hdfs balancer –help

Hdfs balancer –threshold 5

Hdfs-site.xml

dfs.datanode.balance.bandwidthPerSec：1m

dfs.datanode.balance.max.concurrent.moves :5

要理解數據平衡的基本原理，根據threshold計算集羣點節點存儲是否平衡，而後迭代進行移動，至到達到相對平衡，而後進程自動退出。

刪除節點

若是須要主動把所在節點的數據轉移，則建議使用：

先在配置的excludes文件中添加要刪除的節 點，而後執行下面命令

hadoop dfsadmin –refreshNodes

網上有資料代表，有同窗使用這種方式進行數據的轉移，在節點的磁盤被使用殆盡的狀況下，平衡進程太慢，節點退役反而很快，退役後格式化磁盤，而後加回來，加快了數據的平衡處理。

處理磁盤問題

datanode 的配置能夠在線更新了，http://blog.cloudera.com/blog/2015/05/new-in-cdh-5-4-how-swapping-of-hdfs-datanode-drives/

在大的hadoop生產集羣中，每一臺機器都會配置多塊硬盤，而硬盤的損壞也是常態，如何讓硬盤的損壞不影響正常的生產呢？

若是在hdfs-site.xml中把 dfs.datanode.failed.volumes.tolerated 設置爲 大於0的數字，則datanode 容許配置的磁盤有配置數量的損壞。

不然，若是配置爲0 ，若發生了磁盤的損壞，Datanode進程會shutdown.

若是咱們不想datanode進程自動關閉，能夠合理配置dfs.datanode.failed.volumes.tolerated .

而後從日誌監控中發現有磁盤發生損壞的狀況發生，咱們能夠修改hdfs-site.xml中dfs.datanode.data.dir 的配置，

去掉壞掉的盤，而後執行

hdfs dfsadmin –reconfig datanode dnxx:50020 start

hdfs dfsadmin –reconfig datanode dnxx:50020 status

之類的，讓datanode在線更新配置

換上新盤後，再刷新一下配置便可。

這樣不用關閉Datanode進程。若是是低版本的，能夠直接把發生問題的磁盤路徑從配置的dfs.data.dir從去掉，而後啓動datanode進程，而後修好後再加回來，重啓datanode進程。

也能夠調整 容錯的數量，dfs.datanode.failed.volumes.tolerated，思路是同樣的，只是低版本的是須要重啓動datanode進程。

處理長時間不能完成的任務

mapred job -fail-task

mapred job -kill-task

二者的不一樣，前者把任務失敗掉，這個任務就不會再分配給這個節點運行，而kill的task則還可能會分給這個節點運行，並且fail-task的過多，這個節點會被加入黑名單。

升級

升級有風險，cdh之間小版本的升級可能不須要修改hdfs的元數據，只須要替換應用包便可。若是是大版本的升級，則須要升級hdfs文件的元數據。

今天主要說一下hadoop的升級，在生產中，咱們一塊兒升級套件，如hive和hbase等，這時候須要和開發人員多交流，我以前作開發有過經歷，項目中寫的hive語句與調用方式在一次hive的升級後變得不可用，須要花一段時間進行調整。

如下的連接記錄了我作的升級實驗，hadoop2.35.0.2升級到hadoop2.6cdh5.5 .

緣由，我所在山東移動使用hadoop2.35.0.2 ，並且有新集羣已經部署,hadoop2.6.

兩臺機器，nn1,nn2搭建的ha,同時又擔任nn,dn,rm,nm,jn,zkfc,zk等職能。

如下是升級回滾再升級的記錄。僅供參考，同時參考了cdh官網的說明，官網主要是使用CM的。

1 官網上下載hadoop2.6cdh5.5.tar包和hadoop的rpm包

rpm2cpio hadoop.rpm | cpio –div

能夠從裏面找到咱們須要的native的文件 。

2 複製原cdh下的etc/下的全部文件到hadoop2.6下的etc/hadoop

3 進入安全模式，生成fsimage文件 ，並備份整個metadata 文件夾

hdfs dfsadmin -safemode enter
hdfs dfsadmin –saveNamespace

cd /hdp/dfs/name
tar -cvf nn_backup_data.tar .

4. 關停全部相關的進程

stop-all.sh
stop-hbase.sh
ps -aef | grep java

5 紛發新的文件到其餘節點

6 修改.bash_profile（根據你本身的配置）把HADOOP_HOME 指向新的目錄

並紛發到全部機器上，並加載這個文件 使其生效。

7 先啓動jn 而後升級hdfs metadata

hadoop-daemons.sh start journalnode

hdfs namenode -upgrade
hadoop-daemons.sh start datanode

根據你的block的數量狀況，可是通常會很快的。我這邊遇到的狀況下，一直會報：緩存管理器在掃描之類的日誌，好像是bug.不影響升級。

8 回滾

升級後,namenode ，journalnode和datanode下面的相關version等文件有變更.回滾的操做以下：

先操做journalnode的：

能夠直接進入journalnode配置目錄下，把current的改爲new,把previous的改爲current.

或執行

hadoop-daemons.sh start journalnode -rollback（何嘗試）

hdfs namenode –rollback

hadoop-daemons.sh start datanode –rollback

9升級後測試

pdsh -w nn1,nn2 "source /home/student/.bash_profile; zkServer.sh start"

在nn2上，hdfs namenode –bootstrapStandby

同步新生成的fsimage

start-dfs.sh

start-yarn.sh

hadoop jar /app/cdh26550/share/hadoop/mapreduce2/hadoop-mapreduce-examples-2.6.0-cdh5.5.0.jar wordcount pi 10 100

問題處理

問題歸類

1． 我的操做：錯誤的判斷所作的操做或誤操做

2． 錯誤配置:35%的問題都是由於錯誤或不合理的配置引起的

必定要深刻理解配置參數的含義，要根據本身集羣的狀況定製，不是放之四海而皆準的固定的答案。

操做系統級別的配置

Hadoop/hdfs/yarn自己的配置 (內存參數等)

3． 硬件錯誤（常見硬盤錯誤）

4． 資源耗盡（nodemanager 健康檢查報告）

方法論

1． 查看出現問題進程日誌文件（$HADOOP_HOME/logs）

2． Dump相關進程，查看進程棧相關代碼

Javacore 文件中也有當前棧的信息可供分析

3． 查看系統信息/var/log/messages 或 dmesg 查看是否有顯示相關錯誤，如硬件錯誤或文件系統的錯誤

若是是map/reduce任務的錯誤，查看相關的輸出stdout,syslog,syserr中能夠找到相關根本的緣由。(class not found …)