一. 問(wèn)題描述

今天早上到公司，突然收到CDH集群某個(gè)節(jié)點(diǎn)的存儲(chǔ)量的告警，如下圖所示:

image.png

從圖中可以看出，每個(gè)節(jié)點(diǎn)的HDFS空間是相同的，大多節(jié)點(diǎn)HDFS使用量在40%左右，而出問(wèn)題的這個(gè)節(jié)點(diǎn)居然直逼80%，鑒于之前問(wèn)題出現(xiàn)過(guò)多次，且每次都是利用空余時(shí)間使用HDFS的rebalance進(jìn)行解決的，此處需要找出具體問(wèn)題，規(guī)避此類(lèi)問(wèn)題。

二. 解決方案

2.1 查看節(jié)點(diǎn)安裝的組件

image.png

2.2 排查HDFS配置

初步排查了一下各個(gè)節(jié)點(diǎn)的HDFS配置，暫未發(fā)現(xiàn)問(wèn)題，且各個(gè)節(jié)點(diǎn)HDFS的配置是通過(guò) Cloudera Manager進(jìn)行配置的，配置也相同，不存在某個(gè)節(jié)點(diǎn)的HDFS相關(guān)配置出現(xiàn)問(wèn)題，進(jìn)而出現(xiàn)個(gè)別節(jié)點(diǎn)資源使用率高的情況。

2.3 排查Yarn配置

2.3.1 首先查看下nodemanager的日志

對(duì)比出問(wèn)題的節(jié)點(diǎn)和正常的節(jié)點(diǎn)，從審計(jì)日志量來(lái)看，出問(wèn)題的節(jié)點(diǎn)審計(jì)日志明顯比正常節(jié)點(diǎn)多。

image.png

審計(jì)日志內(nèi)容均是申請(qǐng)AM的，現(xiàn)在的問(wèn)題是為什么cdh10節(jié)點(diǎn)的AM比其他節(jié)點(diǎn)多那么多?

image.png

2.3.2 查看container分配情況

正在運(yùn)行container:
從下面截圖來(lái)看，未發(fā)現(xiàn)啥異常情況。

image.png

從歷史分配情況來(lái)看:
對(duì)比了cdh10和cdh7，發(fā)現(xiàn)近7天分配的container是均勻的。

image.png

image.png

2.3.3 查看調(diào)度機(jī)制

那么此時(shí)可以這么理解，當(dāng)集群處于空閑時(shí)，突然來(lái)了一個(gè)任務(wù)，那么此時(shí)因?yàn)樗衏ontainer的優(yōu)先級(jí)相同，優(yōu)先選擇的就是本節(jié)點(diǎn)的container，而第一個(gè)container 用于啟動(dòng)作業(yè)的AM進(jìn)程，這也就對(duì)應(yīng)了之前的，chd10節(jié)點(diǎn)申請(qǐng)AM會(huì)比其他節(jié)點(diǎn)多很多。

image.png

我們知道AM用于協(xié)調(diào)，并不直接參與預(yù)算，真正參與運(yùn)算的是container，而HDFS一般是計(jì)算節(jié)點(diǎn)優(yōu)先寫(xiě)一份數(shù)據(jù)導(dǎo)datanode，然后再寫(xiě)其他副本。但是從上一步的分配情況來(lái)看，container分布是均勻的，

2.3.4 查看集群任務(wù)情況

從 job history上來(lái)看，可以看到，集群內(nèi)小任務(wù)比較多，而因?yàn)槭荂DH集群，調(diào)度采用的是 Fair Scheduler(公平調(diào)度器),沒(méi)有給小任務(wù)預(yù)留一部分集群資源。

image.png

2.3.5 集群負(fù)載情況

從集群的負(fù)載情況來(lái)看，集群存在明顯的業(yè)務(wù)高峰期和空閑期。

image.png

image.png

image.png

2.3.6 resourcemanager與nodemanager是否可以混合部署

搜索到某個(gè)大佬給得說(shuō)法:

image.png

一般是建議分開(kāi)進(jìn)行部署。

2.4 初步判斷

初步判斷，由于cdh10節(jié)點(diǎn)，既包含resourcemanager又包含nodemanager，且對(duì)于優(yōu)先級(jí)相同的 Containers，優(yōu)選選擇滿(mǎn)足本地性的 Container，參與計(jì)算的Container會(huì)優(yōu)先寫(xiě)一份到本地的HDFS，故cdh10節(jié)點(diǎn)寫(xiě)HDFS會(huì)比較多。

于是建議運(yùn)維先進(jìn)行 HDFS rebalance，然后將cdh10節(jié)點(diǎn)nodemanager進(jìn)行刪除。

2.5 最終結(jié)論

近期比較忙，沒(méi)讓運(yùn)維的處理，然后又有flume消費(fèi)Kafka的數(shù)據(jù)實(shí)時(shí)同步到HDFS，因?yàn)橹叭笔б徊糠謹(jǐn)?shù)據(jù)，然后某幾個(gè)節(jié)點(diǎn)在補(bǔ)錄數(shù)據(jù)，剛好補(bǔ)錄歷史數(shù)據(jù)的進(jìn)程出現(xiàn)了問(wèn)題，就把這部分?jǐn)?shù)據(jù)從HDFS上刪除了，打算重新補(bǔ)錄。

刪除后發(fā)現(xiàn)，cdh10和cdh3的HDFS使用量突然降下來(lái)了，問(wèn)題最終浮出水面。

cdh10和cdh3上剛好就是補(bǔ)錄數(shù)據(jù)，而HDFS的寫(xiě)流程，第一個(gè)副本客戶(hù)端優(yōu)先，此例中flume節(jié)點(diǎn)所在的節(jié)點(diǎn)就是客戶(hù)端。

參考:

1. https://www.cnblogs.com/lemonu/p/13566208.html
2. https://www.saoniuhuo.com/question/detail-1955187.html