大規(guī)模集群故障處理，能抗住這3個(gè)靈魂拷問(wèn)算你贏
我相信每一個(gè)集群管理員，在長(zhǎng)期管理多個(gè)不同體量及應(yīng)用場(chǎng)景的集群后，都會(huì)多少產(chǎn)生情緒。其實(shí)這在我看來(lái)，是一個(gè)很微妙的事，即大家也已經(jīng)開(kāi)始人性化的看待每一個(gè)集群了。
既然是人性化的管理集群，我總是會(huì)思考幾個(gè)方向的問(wèn)題：
- 集群的特別之處在哪兒?
- 集群經(jīng)常生什么病?
- 對(duì)于集群產(chǎn)生的突發(fā)疾病如何精準(zhǔn)地做到靶向定位?
- 應(yīng)急處理故障之后如何避免舊除新添?
在長(zhǎng)期大規(guī)模集群治理實(shí)踐過(guò)程中，也針對(duì)各個(gè)集群的各種疑難雜癥形成了自己的西藥(trouble shooting)丶中藥(Returning for analysis)丶健身預(yù)防(On a regular basis to optimize)的手段及產(chǎn)品。
下面通過(guò)自我的三個(gè)靈魂拷問(wèn)來(lái)分享一下自己對(duì)于大規(guī)模集群治理的經(jīng)驗(yàn)及總結(jié)。
靈魂拷問(wèn)1
集群量大，到底有啥特點(diǎn)?
集群數(shù)量多，規(guī)模大：管理著大小將近20個(gè)集群，最大的xxx集群和xx集群達(dá)到1000+節(jié)點(diǎn)的規(guī)模。
靈魂拷問(wèn)2
平時(shí)集群容易生什么病，都有哪些隱患呢?
集群在整體功能性，穩(wěn)定性，資源的使用等大的方面都會(huì)有一些痛點(diǎn)問(wèn)題。
常見(jiàn)的文件數(shù)過(guò)多丶小文件過(guò)多丶RPC隊(duì)列深度過(guò)高，到各個(gè)組件的版本bug，使用組件時(shí)發(fā)生嚴(yán)重生產(chǎn)故障，以及資源浪費(fèi)等都是集群治理的常見(jiàn)問(wèn)題。
靈魂拷問(wèn)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)告加以利用，通過(guò)長(zhǎng)期的治理來(lái)有效的保障集群的深層次健康，并開(kāi)發(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讀寫壓力。
解決手段：通過(guò)監(jiān)控“拎大頭”，找出消耗資源巨大的任務(wù)，通過(guò)業(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故障問(wèn)題。
現(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ù)載過(guò)高的接口機(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)存消耗過(guò)大的進(jìn)程多維度監(jiān)控，及時(shí)的合理調(diào)整優(yōu)化接口機(jī)的調(diào)度任務(wù)，降低接口機(jī)負(fù)載。
4、xxx集群由于文件數(shù)過(guò)多，導(dǎo)致集群運(yùn)行緩慢，NameNode進(jìn)程掉線。
集群的文件對(duì)象達(dá)到九千多萬(wàn)。且集群的讀寫IO是寫多讀少。NameNode啟動(dòng)需要加載大量的塊信息，啟動(dòng)耗時(shí)過(guò)長(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)限沒(méi)有及時(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ù)載過(guò)高影響了其他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使用率過(guò)高。
查看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)過(guò)排查發(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 ;
- hive> set mapreduce.map.memory.mb=4096;
- hive> set mapreduce.map.java.opts=-Xmx3686m;
- 切換NameNode驗(yàn)證所影響Hive表是否可用;
- 業(yè)務(wù)全方面驗(yàn)證 ;
- 變更影響范圍：本次變更可以在線進(jìn)行實(shí)施，避開(kāi)業(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í)超過(guò)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)存上限。該過(guò)程并不是做全量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中間過(guò)程目錄。
這樣會(huì)導(dǎo)致一些數(shù)據(jù)量過(guò)大的task成為漏網(wǎng)之魚，正常來(lái)說(shuō)，數(shù)據(jù)量過(guò)大，如果被校驗(yàn)器采樣到，會(huì)直接報(bào)OOM，實(shí)際情況是大數(shù)據(jù)量task沒(méi)有被檢測(cè)到，超出buffer過(guò)多，導(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ù)問(wèn)題處理。
集群情況介紹：HDFS總存儲(chǔ) 20+PB，已使用 75+%，共 600+ 個(gè) DN 節(jié)點(diǎn)，大部分?jǐn)?shù)據(jù)為 2 副本(該集群經(jīng)歷過(guò) 多次擴(kuò)容，擴(kuò)容前由于存儲(chǔ)緊張被迫降副本為 2)，數(shù)據(jù)分布基本均衡。集群上只承載了HBase數(shù)據(jù)庫(kù)。
故障描述：因集群部分 DN 節(jié)點(diǎn)存儲(chǔ)使用率非常高(超過(guò) 95%)，所以采取了下線主機(jī)然后再恢復(fù) 集群中這種辦法來(lái)減輕某些 DN 存儲(chǔ)壓力。
且集群大部分?jǐn)?shù)據(jù)為 2 副本，所以在這個(gè)過(guò)程 中出現(xiàn)了丟塊現(xiàn)象。通過(guò) fsck 看到已經(jīng)徹底 miss，副本數(shù)為 0。
因此，在重啟 HBase 過(guò)程中，部分 region 因 為 block 的丟失而無(wú)法打開(kāi)，形成了 RIT。
對(duì)此問(wèn)題，我們通過(guò) hadoop fsck –delete 命令清除了 miss 的 block。然后逐庫(kù)通過(guò) hbase hbck –repair 命令來(lái)修復(fù) hbase 在修復(fù)某個(gè)庫(kù)的時(shí)候在嘗試連接 ZK 環(huán)節(jié)長(zhǎng)時(shí)間卡死(10 分鐘沒(méi)有任何輸出)，被迫只能 中斷命令。
然后發(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è)。
問(wèn)題處理：后續(xù)檢查發(fā)現(xiàn)在整個(gè)集群的每張 HBase 表都有 region un-assignment 及 rowkey 存在 hole 問(wèn)題(不是單張表存在問(wèn)題)。
運(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)槊繌埍矶疾豢捎茫酝ㄟ^(guò)新建表并將原表的 HFile 文件 BulkLoad 入新表的方案基本不可行。
第一、這種方案耗時(shí)太長(zhǎng);第二、做過(guò)一個(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 過(guò)程阻塞異常。
查 HMaster 后臺(tái)日志，發(fā)現(xiàn)是某個(gè) RegionServer(DSJ-signal-4T-147/10.162.0.175)的連接數(shù)超多造成連接超時(shí)。重啟該 RegionServer 后再次運(yùn)行 hbck -repair -fixAssignments -fixMeta 順序結(jié)束，并成功修復(fù)了所有表的 region un-assignment、hole 及 HBase:meta 問(wèn)題。
應(yīng)用層測(cè)試整個(gè)集群入庫(kù)正常，問(wèn)題處理完成。
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配置記錄過(guò)期等問(wèn)題。
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ì)問(wèn)題分區(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)維管理及開(kāi)發(fā)優(yōu)化經(jīng)驗(yàn)。管理過(guò)多個(gè)上千節(jié)點(diǎn)集群，擅長(zhǎng)對(duì)外多租戶平臺(tái)的維護(hù)開(kāi)發(fā)。信科院大數(shù)據(jù)性能測(cè)試、功能測(cè)試主力，大廠PK獲得雙項(xiàng)第一。
