大規(guī)模集群故障處理，能抗住這3個靈魂拷問算你贏

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

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

集群的特別之處在哪兒？

集群的特別之處在哪兒？

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

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

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

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

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

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

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

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

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

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

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

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

對于集群的慢性疾病，應(yīng)該從底層收集可用的詳細數(shù)據(jù)，分析報告加以利用，通過長期的治理來有效的保障集群的深層次健康（具體請閱讀《運維老司機都想要掌握的大數(shù)據(jù)平臺監(jiān)控技巧》），并開發(fā)形成能實實在在落地企業(yè)的數(shù)據(jù)資產(chǎn)管理丶數(shù)據(jù)治理產(chǎn)品。

下面將針對上面的9個集群問題或故障逐一解答如何解決。

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

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

業(yè)務(wù)優(yōu)化：從業(yè)務(wù)角度明確來源數(shù)據(jù)，減少加載數(shù)據(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ù)傾斜。

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

根因分析：

解決方案：

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

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

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

ipc.server.handler.queue.size；

dfs.namenode.service.handler.count

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

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

解決手段：

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

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

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

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

配置明細接口機監(jiān)控，優(yōu)化接口機負載。

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

集群的文件對象達到九千多萬。且集群的讀寫IO是寫多讀少。NameNode啟動需要加載大量的塊信息，啟動耗時過長。

解決手段：

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

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

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

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

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

解決辦法：

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

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

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

解決辦法：

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

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

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

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

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

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

解決辦法：

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

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

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

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

切換NameNode驗證所影響Hive表是否可用；

切換NameNode驗證所影響Hive表是否可用；

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

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

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

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

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

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

產(chǎn)線集群提交作業(yè)執(zhí)行報錯,個別Task執(zhí)行耗時超過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.

根因分析：

報錯表象為shuffle階段拉取數(shù)據(jù)操作連接超時。默認超時時間為120s。

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

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

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

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

解決方案：

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

spark.shuffle.manager(sort)，spark.shuffle.consolidateFiles (true)，spark.network.timeout(600s)。報錯解決，運行耗時縮短一小時。

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

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

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

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

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

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

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

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

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

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

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

因為每張表都不可用，所以通過新建表并將原表的 HFile 文件 BulkLoad 入新表的方案基本不可行。

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

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

運行命令 hbae hbck -repair -fixAssignments -fixMeta，報Repair 過程阻塞異常。

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

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

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

1）降低topic副本：

建議如果能降低大部分topic的副本，這個方法是簡單有效的。

降副本之后再把集群的拷貝副本所用的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ù)量遞增時仍會發(fā)生故障。

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

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

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

3）Kafka版本升級及cm納管：

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

4）zk和broker節(jié)點分離：

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

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

怎么加群？：>>>Learn More<<

怎么免費加入知識星球：>>>Free<<<

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

內(nèi)推通道>>>>

本文轉(zhuǎn)載自微信公眾號朱小廝的博客

HBase Hadoop 大數(shù)據(jù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。