點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺(tái)回復(fù)”加群“加入公眾號(hào)專屬技術(shù)群

我相信每一個(gè)集群管理員，在長(zhǎng)期管理多個(gè)不同體量及應(yīng)用場(chǎng)景的集群后，都會(huì)多少產(chǎn)生情緒。其實(shí)這在我看來(lái)，是一個(gè)很微妙的事，即大家也已經(jīng)開始人性化的看待每一個(gè)集群了。

既然是人性化的管理集群，我總是會(huì)思考幾個(gè)方向的問題：

• 集群的特別之處在哪兒？

• 集群經(jīng)常生什么病？

• 對(duì)于集群產(chǎn)生的突發(fā)疾病如何精準(zhǔn)地做到靶向定位？

• 應(yīng)急處理故障之后如何避免舊除新添？

在長(zhǎng)期大規(guī)模集群治理實(shí)踐過程中，也針對(duì)各個(gè)集群的各種疑難雜癥形成了自己的西藥（trouble shooting）丶中藥（Returning for analysis）丶健身預(yù)防（On a regular basis to optimize）的手段及產(chǎn)品。

下面通過自我的三個(gè)靈魂拷問來(lái)分享一下自己對(duì)于大規(guī)模集群治理的經(jīng)驗(yàn)及總結(jié)。

靈魂拷問1集群量大，到底有啥特點(diǎn)？

集群數(shù)量多，規(guī)模大：管理著大小將近20個(gè)集群，最大的xxx集群和xx集群達(dá)到1000+節(jié)點(diǎn)的規(guī)模。

靈魂拷問2平時(shí)集群容易生什么病，都有哪些隱患呢？

集群在整體功能性，穩(wěn)定性，資源的使用等大的方面都會(huì)有一些痛點(diǎn)問題。

常見的文件數(shù)過多丶小文件過多丶RPC隊(duì)列深度過高，到各個(gè)組件的版本bug，使用組件時(shí)發(fā)生嚴(yán)重生產(chǎn)故障，以及資源浪費(fèi)等都是集群治理的常見問題。

靈魂拷問3對(duì)于集群的突發(fā)疾病如何精準(zhǔn)地解決故障？

對(duì)于集群突發(fā)的故障，平臺(tái)應(yīng)具備全面及時(shí)的監(jiān)控告警，做到分鐘級(jí)發(fā)現(xiàn)告警故障，推送告警通知，這是快速解決故障的前提保障。

對(duì)于集群的慢性疾病，應(yīng)該從底層收集可用的詳細(xì)數(shù)據(jù)，分析報(bào)告加以利用，通過長(zhǎng)期的治理來(lái)有效的保障集群的深層次健康（具體請(qǐng)閱讀），并開發(fā)形成能實(shí)實(shí)在在落地企業(yè)的數(shù)據(jù)資產(chǎn)管理丶數(shù)據(jù)治理產(chǎn)品。

下面將針對(duì)上面的9個(gè)集群?jiǎn)栴}或故障逐一解答如何解決。

1、底層計(jì)算引擎老舊，業(yè)務(wù)加工占用大量資源且異常緩慢。

集群底層使用MR計(jì)算引擎，大量任務(wù)未進(jìn)合理優(yōu)化，大多數(shù)任務(wù)占用上千core，上百TB內(nèi)存，且對(duì)集群造成了大量的IO讀寫壓力。

解決手段：通過監(jiān)控“拎大頭”，找出消耗資源巨大的任務(wù)，通過業(yè)務(wù)，計(jì)算引擎，參數(shù)調(diào)優(yōu)來(lái)優(yōu)化集群資源使用，提高集群算力。

業(yè)務(wù)優(yōu)化：從業(yè)務(wù)角度明確來(lái)源數(shù)據(jù)，減少加載數(shù)據(jù)量。

計(jì)算引擎優(yōu)化 ：MR轉(zhuǎn)Spark。

參數(shù)調(diào)優(yōu)：小文件合并優(yōu)化，內(nèi)存內(nèi)核調(diào)優(yōu)，并發(fā)量調(diào)優(yōu)，防止數(shù)據(jù)傾斜。

2、xx集群RPC故障問題。

現(xiàn)象概述：XX產(chǎn)線集群提交作業(yè)執(zhí)行慢; 業(yè)務(wù)數(shù)據(jù)加工邏輯為讀取HDFS新增文件>>>入庫(kù)HBase; 遍歷列表文件周期為5s。

根因分析：

解決方案：

閱讀RPC源碼：動(dòng)態(tài)代理機(jī)制+NIO通信模型。

調(diào)整NN RPC關(guān)鍵參數(shù)，做對(duì)比實(shí)驗(yàn)。

1）優(yōu)化系統(tǒng)參數(shù)配置：

ipc.server.handler.queue.size；

? ? ? ? dfs.namenode.service.handler.count

2）將HDFS千萬(wàn)級(jí)目錄掃描周期從5s調(diào)整為5分鐘?

3）增加集群RPC請(qǐng)求分時(shí)段分業(yè)務(wù)模型深度監(jiān)控

3、xx集群由于承載對(duì)外多租戶，面對(duì)各個(gè)租戶提出的集群生產(chǎn)環(huán)境的需求都不一致，造成集群環(huán)境復(fù)雜化，yarn資源打滿，并且容易出現(xiàn)負(fù)載過高的接口機(jī)，加重運(yùn)維成本。

解決手段：

集群環(huán)境多版本及異構(gòu)管理：

配置多版本Python環(huán)境，并搭建私有第三方庫(kù)。

配置多版本Spark，Kafka環(huán)境。

實(shí)時(shí)監(jiān)控yarn隊(duì)列資源使用，監(jiān)控yarn應(yīng)用任務(wù)，重點(diǎn)優(yōu)化。

配置明細(xì)接口機(jī)監(jiān)控，優(yōu)化接口機(jī)負(fù)載。

接口機(jī)從基礎(chǔ)指標(biāo)，top分析，CPU內(nèi)存消耗過大的進(jìn)程多維度監(jiān)控，及時(shí)的合理調(diào)整優(yōu)化接口機(jī)的調(diào)度任務(wù)，降低接口機(jī)負(fù)載。

4、xxx集群由于文件數(shù)過多，導(dǎo)致集群運(yùn)行緩慢，NameNode進(jìn)程掉線。

集群的文件對(duì)象達(dá)到九千多萬(wàn)。且集群的讀寫IO是寫多讀少。NameNode啟動(dòng)需要加載大量的塊信息，啟動(dòng)耗時(shí)過長(zhǎng)。

解決手段：

計(jì)算引擎優(yōu)化 ：盡量使用Spark，有效率使用內(nèi)存資源，減少磁盤IO讀寫。

周期性清理：根據(jù)HDFS業(yè)務(wù)目錄存儲(chǔ)增量，定期協(xié)調(diào)業(yè)務(wù)人員清理相關(guān)無(wú)用業(yè)務(wù)數(shù)據(jù)。

塊大小管理：小文件做合并，增加block大小為1GB，減少小文件塊數(shù)量。

深度清理：采集監(jiān)控auit日志做HDFS文件系統(tǒng)的多維畫像。深入清理無(wú)用數(shù)據(jù)表，空文件，廢文件。

5、HDFS數(shù)據(jù)目錄權(quán)限管理混亂，經(jīng)常造成數(shù)據(jù)誤刪或丟失。

由于下放的權(quán)限沒有及時(shí)回收，或者一些誤操作造成了數(shù)據(jù)的誤刪和丟失。

解決辦法：

業(yè)務(wù)劃分：明確梳理各個(gè)業(yè)務(wù)對(duì)應(yīng)權(quán)限用戶，整改當(dāng)前HDFS數(shù)據(jù)目錄結(jié)構(gòu)，生產(chǎn)測(cè)試庫(kù)分離控制。

數(shù)據(jù)生命周期管理：

6、yarnJOB造成節(jié)點(diǎn)負(fù)載過高影響了其他job運(yùn)行。

某些節(jié)點(diǎn)CPU負(fù)載很高影響了job任務(wù)的運(yùn)行，發(fā)現(xiàn)有些節(jié)點(diǎn)的負(fù)載從9:30到現(xiàn)在一直很高，導(dǎo)致job任務(wù)執(zhí)行了大概7個(gè)小時(shí)。

解決辦法：

找到耗時(shí)task執(zhí)行的節(jié)點(diǎn)，確實(shí)發(fā)現(xiàn)負(fù)載很高，并找到了此任務(wù)對(duì)應(yīng)的進(jìn)程。

查看此進(jìn)程的堆棧信息，發(fā)現(xiàn)Full GC次數(shù)很多，時(shí)長(zhǎng)很長(zhǎng)大概6個(gè)小時(shí)，頻繁的Full GC會(huì)使CPU使用率過高。

查看job進(jìn)程詳情發(fā)現(xiàn)，java heap內(nèi)存只有820M，task處理的記錄數(shù)為7400多萬(wàn)，造成堆內(nèi)存不足頻繁出發(fā)Full GC。

推薦下次執(zhí)行任務(wù)時(shí)設(shè)置如下參數(shù)大小：

hive> set mapreduce.map.memory.mb=4096;

hive> set mapreduce.map.java.opts=-Xmx3686m;

7、NameNode切換后部分Hive表無(wú)法查詢。

小集群NameNode發(fā)生切換，并出現(xiàn)Hive某庫(kù)下的表和其有關(guān)聯(lián)的表無(wú)法使用的情況報(bào)錯(cuò)如下：

截圖報(bào)錯(cuò)，表明當(dāng)前NameNode節(jié)點(diǎn)為stanby節(jié)點(diǎn)。經(jīng)過排查發(fā)現(xiàn)，Hive的Metadata中有些partition列的屬性還保留之前配置的NameNode location。

解決辦法：

• 備份Hive所在的MySQL元數(shù)據(jù)庫(kù) # mysqldump -uRoot -pPassword hive > hivedump.sql；

• ?進(jìn)入Hive所在的MySQL數(shù)據(jù)庫(kù)執(zhí)行，修改Hive庫(kù)下SDS表下的location信息，涉及條數(shù)9739行。把指定IP的location替換成nameservice ；

  UPDATE SDS SET LOCATION = REPLACE(LOCATION, 'hdfs://ip:8020', 'hdfs://nameservice1') where LOCATION like 'hdfs://ip%';?

• 切換NameNode驗(yàn)證所影響Hive表是否可用；

• 業(yè)務(wù)全方面驗(yàn)證 ；

• 變更影響范圍：本次變更可以在線進(jìn)行實(shí)施，避開業(yè)務(wù)繁忙段，對(duì)業(yè)務(wù)無(wú)影響；

• 回退方案：從備份的mysqldump文件中恢復(fù)mysql hive元數(shù)據(jù)庫(kù) mysql -uUsername -pPassword hive < hivedump.sq。

8、Spark任務(wù)運(yùn)行緩慢，且經(jīng)常執(zhí)行報(bào)錯(cuò)。

產(chǎn)線集群提交作業(yè)執(zhí)行報(bào)錯(cuò),個(gè)別Task執(zhí)行耗時(shí)超過2h: ERROR server.TransportChannelHandler: Connection to ip:4376 has been quiet for 120000 ms while there are outstanding requests. Assuming connection is dead; please adjust spark.network.timeout if this is wrong.

根因分析：

報(bào)錯(cuò)表象為shuffle階段拉取數(shù)據(jù)操作連接超時(shí)。默認(rèn)超時(shí)時(shí)間為120s。

深入了解Spark源碼：在shuffle階段會(huì)有read 和 write操作。

首先根據(jù)shuffle可使用內(nèi)存對(duì)每一個(gè)task進(jìn)行chcksum，校驗(yàn)task處理數(shù)據(jù)量是否超出shuffle buffer 內(nèi)存上限。該過程并不是做全量chcksum，而是采用抽樣的方式進(jìn)行校驗(yàn)。

其原理是抽取task TID ，與shuffle內(nèi)存校驗(yàn)，小于shuffle內(nèi)存上限，則該區(qū)間的task都會(huì)獲取 task data 遍歷器進(jìn)行數(shù)據(jù)遍歷load本地，即HDFS Spark中間過程目錄。?

這樣會(huì)導(dǎo)致一些數(shù)據(jù)量過大的task成為漏網(wǎng)之魚，正常來(lái)說，數(shù)據(jù)量過大，如果被校驗(yàn)器采樣到，會(huì)直接報(bào)OOM，實(shí)際情況是大數(shù)據(jù)量task沒有被檢測(cè)到，超出buffer過多，導(dǎo)致load時(shí)，一部分?jǐn)?shù)據(jù)在內(nèi)存中獲取不到，進(jìn)而導(dǎo)致連接超時(shí)的報(bào)錯(cuò)假象。

解決方案：

1）調(diào)優(yōu)參數(shù)配置：

spark.shuffle.manager(sort)，spark.shuffle.consolidateFiles (true)，spark.network.timeout(600s)。報(bào)錯(cuò)解決，運(yùn)行耗時(shí)縮短一小時(shí)。

2）excutor分配內(nèi)存從16g降為6g。內(nèi)存占用節(jié)省三分之二，運(yùn)行耗時(shí)增加一小時(shí)。

9、某HBase集群無(wú)法PUT入庫(kù)問題處理。

集群情況介紹：HDFS總存儲(chǔ) 20+PB，已使用 75+%，共 600+ 個(gè) DN 節(jié)點(diǎn)，大部分?jǐn)?shù)據(jù)為 2 副本（該集群經(jīng)歷過 多次擴(kuò)容，擴(kuò)容前由于存儲(chǔ)緊張被迫降副本為 2），數(shù)據(jù)分布基本均衡。集群上只承載了HBase數(shù)據(jù)庫(kù)。

故障描述：因集群部分 DN 節(jié)點(diǎn)存儲(chǔ)使用率非常高（超過 95%），所以采取了下線主機(jī)然后再恢復(fù) 集群中這種辦法來(lái)減輕某些 DN 存儲(chǔ)壓力。

且集群大部分?jǐn)?shù)據(jù)為 2 副本，所以在這個(gè)過程 中出現(xiàn)了丟塊現(xiàn)象。通過 fsck 看到已經(jīng)徹底 miss，副本數(shù)為 0。

因此，在重啟 HBase 過程中，部分 region 因 為 block 的丟失而無(wú)法打開，形成了 RIT。?

對(duì)此問題，我們通過 hadoop fsck –delete 命令清除了 miss 的 block。然后逐庫(kù)通過 hbase hbck –repair 命令來(lái)修復(fù) hbase 在修復(fù)某個(gè)庫(kù)的時(shí)候在嘗試連接 ZK 環(huán)節(jié)長(zhǎng)時(shí)間卡死（10 分鐘沒有任何輸出），被迫只能 中斷命令。

然后發(fā)現(xiàn)故障表只有 999 個(gè) region，并且出現(xiàn) RIT，手動(dòng) assign 無(wú)效后，嘗試了重啟庫(kù)及再次 repair 修 復(fù)，均無(wú)效。

目前在 HDFS 上查看該表 region 目錄總數(shù)為 1002 個(gè)，而 Hbase UI 上是 999 個(gè)，正常值為 1000 個(gè)。

問題處理：后續(xù)檢查發(fā)現(xiàn)在整個(gè)集群的每張 HBase 表都有 region un-assignment 及 rowkey 存在 hole 問題（不是單張表存在問題）。

運(yùn)行 hbase hbck -details -checkCorruptHFiles 做集群狀態(tài)檢查，檢查結(jié)果如下：

?… ERROR: Region { meta => index_natip201712,#\xA0,1512009553152.00d96f6b2de55b56453e7060328b7930., hdfs => hdfs://ns1/hbase_ipsource3/data/default/index_natip201712/00d96f6b2de55b56453e7060328b7930, deployed => } not deployed on any region server. ERROR: Region { meta => index_natip201711,Y`,1509436894266.00e2784a250af945c66fb70370344f2f., hdfs => hdfs://ns1/hbase_ipsource3/data/default/index_natip201711/00e2784a250af945c66fb70370344f2f, deployed => } not deployed on any region server. … ERROR: There is a hole in the region chain between \x02 and \x02@. You need to create a new .regioninfo and region dir in hdfs to plug the hole. ERROR: There is a hole in the region chain between \x04 and \x04@. You need to create a new .regioninfo and region dir in hdfs to plug the hole.

每張表可用（online）的 region 數(shù)都少于 1000，共存在 391 個(gè) inconsistency，整個(gè)集群基本不可用。

因?yàn)槊繌埍矶疾豢捎?#xff0c;所以通過新建表并將原表的 HFile 文件 BulkLoad 入新表的方案基本不可行。

第一、這種方案耗時(shí)太長(zhǎng)；第二、做過一個(gè)基本測(cè)試，如果按照原表預(yù) 分區(qū)的方式新建表，在 BulkLoad 操作后，無(wú)法在新表上查詢數(shù)據(jù)（get 及 scan 操作均 阻塞，原因未知，初步估計(jì)和預(yù)分區(qū)方式有關(guān)）。

基于以上分析，決定采用 hbck 直接修復(fù)原表的方案進(jìn)行，不再采用 BulkLoad 方案。

運(yùn)行命令 hbae hbck -repair -fixAssignments -fixMeta，報(bào)Repair 過程阻塞異常。

查 HMaster 后臺(tái)日志，發(fā)現(xiàn)是某個(gè) RegionServer（DSJ-XXXXXX-XX-XXX/xx.xxx.x.xxx）的連接數(shù)超多造成連接超時(shí)。重啟該 RegionServer 后再次運(yùn)行 hbck -repair -fixAssignments -fixMeta 順序結(jié)束，并成功修復(fù)了所有表的 region un-assignment、hole 及 HBase:meta 問題。

應(yīng)用層測(cè)試整個(gè)集群入庫(kù)正常，問題處理完成。

10、Kafka集群頻頻到達(dá)性能瓶頸，造成上下游數(shù)據(jù)傳輸積壓。

Kafka集群節(jié)點(diǎn)數(shù)50+，集群使用普通SATA盤，存儲(chǔ)能力2000TB，千億級(jí)日流量，經(jīng)常會(huì)出現(xiàn)個(gè)別磁盤IO打滿，導(dǎo)致生產(chǎn)斷傳，消費(fèi)延遲，繼而引發(fā)消費(fèi)offset越界，單個(gè)節(jié)點(diǎn)topic配置記錄過期等問題。

1）降低topic副本：

建議如果能降低大部分topic的副本，這個(gè)方法是簡(jiǎn)單有效的。

降副本之后再把集群的拷貝副本所用的cpu核數(shù)降低，可以由num.replica.fetchers=6降低為num.replica.fetchers=3。磁盤IO使用的num.io.threads=14升為num.io.threads=16。num.network.threads=8升為num.network.threads=9。此參數(shù)只是暫時(shí)壓榨機(jī)器性能，當(dāng)數(shù)據(jù)量遞增時(shí)仍會(huì)發(fā)生故障。

2）設(shè)定topic創(chuàng)建規(guī)則，針對(duì)磁盤性能瓶頸做分區(qū)指定磁盤遷移：

如果降低副本收效甚微，考慮到目前集群瓶頸主要在個(gè)別磁盤讀寫IO達(dá)到峰值，是因磁盤的topic分區(qū)分配不合理導(dǎo)致，建議首先做好針對(duì)topic分區(qū)級(jí)別IO速率的監(jiān)控，然后形成規(guī)范合理的topic創(chuàng)建分區(qū)規(guī)則（數(shù)據(jù)量，流量大的topic先創(chuàng)建；分區(qū)數(shù)*副本數(shù)是磁盤總數(shù)的整數(shù)倍），先做到磁盤存儲(chǔ)的均衡，再挑出來(lái)個(gè)別讀寫IO到達(dá)瓶頸的磁盤，根據(jù)監(jiān)控找出讀寫異常大分區(qū)。

找出分區(qū)后再次進(jìn)行針對(duì)topic的分區(qū)擴(kuò)容或者針對(duì)問題分區(qū)進(jìn)行指定磁盤的遷移。這樣集群的整體利用率和穩(wěn)定性能得到一定的提升，能節(jié)省集群資源。

3）Kafka版本升級(jí)及cm納管：

將手工集群遷移至cm納管，并在線升級(jí)Kafka版本。

?4）zk和broker節(jié)點(diǎn)分離：

進(jìn)行zk和broker節(jié)點(diǎn)的分離工作，建議進(jìn)行zk節(jié)點(diǎn)變化而不是broker節(jié)點(diǎn)變化，以此避免數(shù)據(jù)拷貝帶來(lái)的集群負(fù)荷，建議創(chuàng)建測(cè)試topic，由客戶端適當(dāng)增加批大小和減少提交頻率進(jìn)行測(cè)試，使集群性能達(dá)到最優(yōu)。

作者：小火牛，項(xiàng)目管理高級(jí)工程師，具有多年大數(shù)據(jù)平臺(tái)運(yùn)維管理及開發(fā)優(yōu)化經(jīng)驗(yàn)。來(lái)源：DBAplus社群。

想知道更多？掃描下面的二維碼關(guān)注我

---

怎么加群？：

怎么免費(fèi)加入知識(shí)星球：

免費(fèi)資料入口：后臺(tái)回復(fù)“666”

掘金小冊(cè)支付通道開啟，有需要購(gòu)買電子版的《深入理解Kafka》的同學(xué)可以在公眾號(hào)后臺(tái)回復(fù)：【電子版】 或者 【Kafka】獲取海報(bào)購(gòu)買。

朕已閱?

總結(jié)

以上是生活随笔為你收集整理的大规模集群故障处理，能抗住这3个灵魂拷问算你赢的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。