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

[[278545]]

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

• 集群的特別之處在哪兒?
• 集群經(jīng)常生什么病?
• 對于集群產(chǎn)生的突發(fā)疾病如何精準(zhǔn)地做到靶向定位?
• 應(yīng)急處理故障之后如何避免舊除新添?

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

下面通過自我的三個(gè)靈魂拷問來分享一下自己對于大規(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)定性，資源的使用等大的方面都會有一些痛點(diǎn)問題。

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

靈魂拷問3

對于集群的突發(fā)疾病如何精準(zhǔn)地解決故障?

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

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

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

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

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

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

業(yè)務(wù)優(yōu)化：從業(yè)務(wù)角度明確來源數(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新增文件>>>入庫HBase; 遍歷列表文件周期為5s。

根因分析：

解決方案：

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

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

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

ipc.server.handler.queue.size； 
        dfs.namenode.service.handler.count 

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

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

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

解決手段：

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

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

 

配置多版本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)程掉線。

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

解決手段：

計(jì)算引擎優(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ù)表，空文件，廢文件。

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

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

解決辦法：

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

數(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ù)對應(yīng)的進(jìn)程。

 

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

 

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

 

推薦下次執(zhí)行任務(wù)時(shí)設(shè)置如下參數(shù)大?。?/p>

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

7、NameNode切換后部分Hive表無法查詢。

小集群NameNode發(fā)生切換，并出現(xiàn)Hive某庫下的表和其有關(guān)聯(lián)的表無法使用的情況報(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ù)庫 # mysqldump -uRoot -pPassword hive > hivedump.sql;
• 進(jìn)入Hive所在的MySQL數(shù)據(jù)庫執(zhí)行，修改Hive庫下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í)施，避開業(yè)務(wù)繁忙段，對業(yè)務(wù)無影響;
• 回退方案：從備份的mysqldump文件中恢復(fù)mysql hive元數(shù)據(jù)庫 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階段會有read 和 write操作。

首先根據(jù)shuffle可使用內(nèi)存對每一個(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都會獲取 task data 遍歷器進(jìn)行數(shù)據(jù)遍歷load本地，即HDFS Spark中間過程目錄。

這樣會導(dǎo)致一些數(shù)據(jù)量過大的task成為漏網(wǎng)之魚，正常來說，數(shù)據(jù)量過大，如果被校驗(yàn)器采樣到，會直接報(bào)OOM，實(shí)際情況是大數(shù)據(jù)量task沒有被檢測到，超出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集群無法PUT入庫問題處理。

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

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

且集群大部分?jǐn)?shù)據(jù)為 2 副本，所以在這個(gè)過程 中出現(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ù)某個(gè)庫的時(shí)候在嘗試連接 ZK 環(huán)節(jié)長時(shí)間卡死(10 分鐘沒有任何輸出)，被迫只能 中斷命令。

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

目前在 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)槊繌埍矶疾豢捎茫酝ㄟ^新建表并將原表的 HFile 文件 BulkLoad 入新表的方案基本不可行。

第一、這種方案耗時(shí)太長;第二、做過一個(gè)基本測試，如果按照原表預(yù) 分區(qū)的方式新建表，在 BulkLoad 操作后，無法在新表上查詢數(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 后臺日志，發(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 問題。

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

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

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

1)降低topic副本：

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

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

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

如果降低副本收效甚微，考慮到目前集群瓶頸主要在個(gè)別磁盤讀寫IO達(dá)到峰值，是因磁盤的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ù)倍)，先做到磁盤存儲的均衡，再挑出來個(gè)別讀寫IO到達(dá)瓶頸的磁盤，根據(jù)監(jiān)控找出讀寫異常大分區(qū)。

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

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

將手工集群遷移至cm納管，并在線升級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ù)拷貝帶來的集群負(fù)荷，建議創(chuàng)建測試topic，由客戶端適當(dāng)增加批大小和減少提交頻率進(jìn)行測試，使集群性能達(dá)到最優(yōu)。

作者介紹

小火牛，項(xiàng)目管理高級工程師，具有多年大數(shù)據(jù)平臺運(yùn)維管理及開發(fā)優(yōu)化經(jīng)驗(yàn)。管理過多個(gè)上千節(jié)點(diǎn)集群，擅長對外多租戶平臺的維護(hù)開發(fā)。信科院大數(shù)據(jù)性能測試、功能測試主力，大廠PK獲得雙項(xiàng)第一。