級(jí)實(shí)戰(zhàn)：集群搭建、HA與Zookeeper整合排障指南)
我?guī)н^不少新人也幫人排查過不少集群?jiǎn)栴}。有個(gè)現(xiàn)象特別普遍很多人把Hadoop偽分布式搭起來(lái)、跑通一個(gè)WordCount就覺得Hadoop這關(guān)過了。但真到了企業(yè)級(jí)項(xiàng)目里面對(duì)一個(gè)多節(jié)點(diǎn)集群、跟Zookeeper等生態(tài)組件深度整合之后問題根本不是“跑通”兩個(gè)字能覆蓋的。格式化失敗、DataNode注冊(cè)不上、NameNode莫名其妙掛掉、HA自動(dòng)切換不生效隨便一個(gè)故障都能讓人卡住一整天。這篇東西寫給那些已經(jīng)跨過入門、正準(zhǔn)備往進(jìn)階走的人。不管你是要準(zhǔn)備Hadoop面試還是公司里要上一套真正能扛業(yè)務(wù)的集群又或者只是被“ambari部署hadoop集群”“hadoop啟動(dòng)格式化失敗”這種問題折磨到懷疑人生下面的內(nèi)容都應(yīng)該能幫上忙。我會(huì)按企業(yè)級(jí)落地時(shí)最容易出問題的那幾條線來(lái)講部署路線怎么選、HA怎么跟Zookeeper整合、格式化與啟動(dòng)階段有哪些坑、日常故障怎么一步步查以及最后怎么用一套“故障演練”的方式把知識(shí)變成自己的。1. 能跑通Demo和能扛住生產(chǎn)中間隔著什么1.1 偽分布式容易給人“我已經(jīng)會(huì)Hadoop”的錯(cuò)覺很多教程喜歡讓人從偽分布式開始這沒問題但它帶來(lái)的最大副作用是偽分布式跑得太順了順到讓人誤以為Hadoop就是“改幾個(gè)配置文件啟動(dòng)幾個(gè)進(jìn)程”的事兒。偽分布式本質(zhì)上是在一臺(tái)機(jī)器上用多個(gè)Java進(jìn)程模擬分布式。它沒有真實(shí)的網(wǎng)絡(luò)IO沒有跨節(jié)點(diǎn)通信沒有機(jī)架感知也沒有資源競(jìng)爭(zhēng)。你在偽分布式里看到的日志永遠(yuǎn)干干凈凈你在偽分布式里執(zhí)行的格式化永遠(yuǎn)一次成功。但所有這些“順利”都是假象恰恰是進(jìn)階路上最危險(xiǎn)的起點(diǎn)。到了真實(shí)集群環(huán)境你面對(duì)的是完全不同的復(fù)雜度網(wǎng)絡(luò)成為第一道坎。節(jié)點(diǎn)之間要互相解析主機(jī)名防火墻要放行一堆端口機(jī)架感知策略會(huì)影響副本存放。偽分布式里從來(lái)沒有這個(gè)概念。資源是有限的。NameNode的內(nèi)存決定了能支撐多少文件元數(shù)據(jù)DataNode的磁盤決定了能存多少數(shù)據(jù)塊YARN的調(diào)度器決定了任務(wù)能不能擠進(jìn)去。偽分布式不關(guān)心這些因?yàn)樗袞|西都在一臺(tái)機(jī)器上。故障是常態(tài)。一個(gè)節(jié)點(diǎn)掉線、一塊磁盤寫滿、一次Full GC導(dǎo)致心跳超時(shí)都可能導(dǎo)致整個(gè)集群進(jìn)入降級(jí)狀態(tài)。偽分布式里的進(jìn)程掛了你馬上知道生產(chǎn)環(huán)境里一個(gè)節(jié)點(diǎn)無(wú)響應(yīng)你可能要翻半天日志。我見過太多人面試時(shí)把HDFS架構(gòu)背得滾瓜爛熟真到了集群上連“DataNode為什么起不來(lái)”都無(wú)從下手。原因很簡(jiǎn)單他們學(xué)的是“結(jié)構(gòu)”不是“行為”。企業(yè)級(jí)項(xiàng)目實(shí)戰(zhàn)要補(bǔ)的恰恰是后一半。1.2 企業(yè)級(jí)項(xiàng)目的重心其實(shí)在Hadoop之外還有一個(gè)更隱蔽的認(rèn)知偏差很多人以為企業(yè)級(jí)項(xiàng)目 把Hadoop集群搭得更大、更快。真不是這樣。企業(yè)級(jí)項(xiàng)目的難點(diǎn)一大半在Hadoop之外在生態(tài)整合與運(yùn)維體系建設(shè)上。Hadoop只是一個(gè)底座底座之上掛著一堆組件Zookeeper管協(xié)調(diào)、YARN管調(diào)度、Hive管數(shù)倉(cāng)、HBase管在線查詢、Kafka管數(shù)據(jù)接入。這些組件單獨(dú)看都不難難的是它們咬合在一起之后出了問題你很難判斷是哪一環(huán)掉了鏈子。舉個(gè)例子一個(gè)Hive查詢突然變慢可能的根因包括HDFS某個(gè)DataNode磁盤IO異常導(dǎo)致讀取走了慢路徑Y(jié)ARN隊(duì)列資源被別的任務(wù)占滿你的任務(wù)一直在排隊(duì)Zookeeper會(huì)話超時(shí)導(dǎo)致HBase RegionServer在做無(wú)謂的自我恢復(fù)甚至是NameNode在做checkpoint時(shí)搶占了大量IO間接拖慢了整個(gè)HDFS。這種問題只懂Hadoop本身是搞不定的。你必須對(duì)整個(gè)生態(tài)的運(yùn)行機(jī)制有清晰的認(rèn)知知道哪個(gè)組件的數(shù)據(jù)流向哪里、它依賴誰(shuí)、掛了會(huì)有什么表現(xiàn)。這才是“生態(tài)深度整合”這四個(gè)字的真正含義也是這篇文章試圖幫你建立的主干思維。2. 集群搭建的三條路線手動(dòng)、Ambari、容器化怎么選2.1 手動(dòng)搭建值得走一遍但別在生產(chǎn)環(huán)境硬扛我始終建議每個(gè)進(jìn)階者手動(dòng)搭一遍Hadoop集群哪怕只是三個(gè)節(jié)點(diǎn)。原因很簡(jiǎn)單手動(dòng)搭建能逼著你把每個(gè)配置項(xiàng)的含義弄清楚而不是讓工具替你把這些細(xì)節(jié)全部藏起來(lái)。但手動(dòng)搭建只適合學(xué)習(xí)不適合當(dāng)生產(chǎn)環(huán)境的長(zhǎng)期運(yùn)維方案。你手動(dòng)搭起來(lái)的集群沒有統(tǒng)一的配置管理沒有完善的可視化監(jiān)控沒有組件間的健康檢查。一旦規(guī)模超過十個(gè)節(jié)點(diǎn)手動(dòng)運(yùn)維會(huì)變成一場(chǎng)災(zāi)難。版本選型是手動(dòng)搭建的第一步。我這里不想把Apache、CDH、HDP的版本歷史鋪開講就講現(xiàn)狀Cloudera和Hortonworks合并之后CDH成了商業(yè)產(chǎn)品HDP的開源脈絡(luò)則由Cloudera的開源發(fā)行版延續(xù)但整體都偏向商用訂閱如果你想要純開源、不涉及商業(yè)授權(quán)煩惱的路線Apache Hadoop社區(qū)版是唯一穩(wěn)妥的選擇。版本號(hào)上Hadoop 3.x已經(jīng)是絕對(duì)主流3.1.x和3.3.x用得最多。3.3.x修復(fù)了不少3.1.x遺留的問題新項(xiàng)目建議直接上3.3.x。手動(dòng)搭建時(shí)有幾個(gè)配置項(xiàng)是無(wú)論如何都要搞懂的配置文件關(guān)鍵配置項(xiàng)它的作用core-site.xmlfs.defaultFS指定NameNode的RPC地址客戶端和DataNode全靠它找到“老大”hdfs-site.xmldfs.replication數(shù)據(jù)塊副本數(shù)決定了容錯(cuò)能力與存儲(chǔ)成本的平衡hdfs-site.xmldfs.namenode.name.dirNameNode元數(shù)據(jù)存儲(chǔ)路徑必須放在獨(dú)立磁盤上不能跟系統(tǒng)盤混用yarn-site.xmlyarn.nodemanager.resource.memory-mb單個(gè)NodeManager可用的物理內(nèi)存上限直接決定容器能開多大mapred-site.xmlmapreduce.framework.name必須設(shè)為yarn否則MapReduce任務(wù)不會(huì)走YARN調(diào)度另外環(huán)境準(zhǔn)備這一步千萬(wàn)別跳所有節(jié)點(diǎn)之間要配置SSH免密登錄系統(tǒng)時(shí)間必須用NTP同步差一分鐘都可能引發(fā)Kerberos認(rèn)證失敗或心跳異常JDK版本必須完全一致最好連JDK的安裝在哪個(gè)路徑都保持一致。這一步能給你省掉后面80%的玄學(xué)故障。2.2 Ambari部署中大規(guī)模集群的運(yùn)維入口如果公司要搭一套十幾個(gè)節(jié)點(diǎn)以上的集群我建議別掙扎了直接上Ambari這類工具。Ambari的價(jià)值不在于“一鍵安裝”——真正裝過的人都知道它也不是完全一鍵。它的核心價(jià)值是集中化配置管理所有組件的核心配置項(xiàng)都在Web界面上改改完能統(tǒng)一分發(fā)到所有節(jié)點(diǎn)還能選擇是否滾動(dòng)重啟服務(wù)健康檢查每個(gè)組件的存活狀態(tài)、告警規(guī)則、指標(biāo)趨勢(shì)都集中展示省去了逐臺(tái)機(jī)器翻日志的苦力活擴(kuò)縮容友好新增一個(gè)DataNode節(jié)點(diǎn)界面上填上主機(jī)名和SSH憑據(jù)就行了。但Ambari也有幾個(gè)典型的坑我踩過身邊的人也踩過Ambari Server自身的內(nèi)存占用比預(yù)想的高。默認(rèn)的2GB堆內(nèi)存在組件多的時(shí)候會(huì)有明顯壓力我的建議是至少給Ambari Server分配4GB以上。如果你把Ambari和NameNode放在同一臺(tái)機(jī)器上更要提前調(diào)好內(nèi)存分配。Agent注冊(cè)失敗是高頻問題。Ambari Agent向Server注冊(cè)時(shí)要求兩邊主機(jī)名能互相解析。很多人只配了/etc/hosts但沒配好防火墻導(dǎo)致Agent注冊(cè)超時(shí)。處理方式很粗暴也很有效先確認(rèn)hostname一致再確認(rèn)防火墻放行8080和8440/8441端口最后重啟Agent看日志。藍(lán)屏問題。這里的“藍(lán)屏”是Ambari界面上組件狀態(tài)變藍(lán)表示“未安裝”。最常見的原因是你手動(dòng)在某個(gè)節(jié)點(diǎn)上裝了組件之后用Ambari管理時(shí)狀態(tài)就錯(cuò)亂了。記住一條鐵律Ambari管理的集群所有操作都通過Ambari做永遠(yuǎn)不要手動(dòng)去改它管理范圍內(nèi)的配置文件和啟動(dòng)腳本。2.3 Docker鏡像搭建學(xué)習(xí)驗(yàn)證的最優(yōu)解生產(chǎn)的禁區(qū)Docker跑Hadoop這幾年越來(lái)越流行因?yàn)閷?duì)學(xué)習(xí)來(lái)說(shuō)它實(shí)在太方便了。不需要準(zhǔn)備一堆虛擬機(jī)一條命令就能拉起一套集群跑完就刪干凈利落。我自己用Docker方式做過完整的三節(jié)點(diǎn)Hadoop集群體驗(yàn)是用來(lái)驗(yàn)證配置修改、測(cè)試作業(yè)邏輯、準(zhǔn)備面試場(chǎng)景效率無(wú)敵。但要注意幾個(gè)關(guān)鍵細(xì)節(jié)網(wǎng)絡(luò)模式用host或自定義bridge不要用默認(rèn)bridge。默認(rèn)bridge的網(wǎng)絡(luò)隔離會(huì)讓容器間主機(jī)名解析變得很麻煩自定義網(wǎng)絡(luò)加上固定的容器名才能模擬出真實(shí)集群的主機(jī)解析關(guān)系。數(shù)據(jù)目錄務(wù)必用volume掛出來(lái)。否則容器一刪你辛苦搭的環(huán)境數(shù)據(jù)全沒了下次還得從頭再來(lái)。鏡像的Java版本要和Hadoop版本匹配。很多第三方鏡像用的OpenJDK 8對(duì)Hadoop 3.3.x也沒問題但如果你拉了一個(gè)很老的鏡像配了很新的Hadoop格式化階段就可能報(bào)出詭異的NativeIO錯(cuò)誤。容器化跑Hadoop唯一的限制是它模擬不了真實(shí)的資源競(jìng)爭(zhēng)和網(wǎng)絡(luò)故障場(chǎng)景。Docker容器之間雖然是隔離的但底層還是共享同一套內(nèi)核和物理資源。這意味著你用它學(xué)“功能”沒問題學(xué)“性能調(diào)優(yōu)”和“故障演練”則遠(yuǎn)遠(yuǎn)不夠。所以我的結(jié)論是容器化是學(xué)習(xí)環(huán)境的最優(yōu)解盡早上手生產(chǎn)環(huán)境則除非是短期測(cè)試環(huán)境否則別碰。順帶提一句Windows開發(fā)環(huán)境的搭建?，F(xiàn)在很多新手想在自己Windows機(jī)器上折騰Hadoop也就是熱搜里那個(gè)“windows下載hadoop”的需求我的建議是在Windows上直接裝Hadoop很痛苦不只是下載解壓的問題還有一堆原生庫(kù)依賴、路徑分隔符、權(quán)限模型的問題等著你。最省力的做法是裝個(gè)WSL2或直接上Docker Desktop在Linux內(nèi)核環(huán)境里跑Hadoop體驗(yàn)和真實(shí)集群幾乎一致。“hadoop開發(fā)環(huán)境搭建頭歌”這類實(shí)訓(xùn)平臺(tái)我也見過適合當(dāng)入門練習(xí)但如果你想深入理解原理還是要自己搭一套干凈的環(huán)境不要依賴平臺(tái)幫你隱藏細(xì)節(jié)。3. Hadoop與Zookeeper整合實(shí)戰(zhàn)HA集群的心臟3.1 為什么HA不能沒有Zookeeper先回答一個(gè)面試必問、也是實(shí)際運(yùn)維中必須理解透徹的問題為什么NameNode的高可用一定要靠ZookeeperNameNode是HDFS的核心它保存了整個(gè)文件系統(tǒng)的元數(shù)據(jù)。一旦它掛了整個(gè)HDFS都不可用。早期Hadoop的痛點(diǎn)是單點(diǎn)故障NameNode一掛集群就癱瘓只能靠人工恢復(fù)。那有人會(huì)問用Keepalived這類方案給NameNode掛一個(gè)虛擬IP主節(jié)點(diǎn)掛了把IP漂移到備節(jié)點(diǎn)不就行了嗎問題在于HDFS的高可用不只是“IP漂移”這么簡(jiǎn)單。NameNode的元數(shù)據(jù)分兩部分內(nèi)存中的鏡像fsimage和磁盤上的編輯日志edits。主備兩個(gè)NameNode要保證元數(shù)據(jù)完全一致必須持續(xù)同步編輯日志。如果主節(jié)點(diǎn)已經(jīng)寫了一條edits日志但還沒來(lái)得及同步給備節(jié)點(diǎn)就掛了備節(jié)點(diǎn)接管的元數(shù)據(jù)就不完整會(huì)造成數(shù)據(jù)丟失或元數(shù)據(jù)錯(cuò)亂。所以真正的HA方案要解決兩件事元數(shù)據(jù)的實(shí)時(shí)同步——主NameNode把edits日志實(shí)時(shí)寫入一個(gè)共享存儲(chǔ)備NameNode持續(xù)讀取并應(yīng)用這些日志保證內(nèi)存里的元數(shù)據(jù)基本一致。Hadoop采用的是JournalNode集群本質(zhì)上是把edits日志分散寫到多臺(tái)JournalNode上只要半數(shù)以上節(jié)點(diǎn)存活元數(shù)據(jù)就不丟。故障自動(dòng)切換——怎么讓集群里所有節(jié)點(diǎn)認(rèn)同“原來(lái)那個(gè)Active NameNode已經(jīng)死了現(xiàn)在應(yīng)該由Standby接替”這個(gè)決策必須由所有參與者一致認(rèn)可否則就可能出現(xiàn)兩個(gè)NameNode同時(shí)認(rèn)為自己是Active的情況這就是腦裂。這兩個(gè)問題Zookeeper都能解決或者說(shuō)只有Zookeeper這類強(qiáng)一致協(xié)調(diào)組件能優(yōu)雅地解決。ZK在HDFS HA里有三重角色選主仲裁兩個(gè)NameNode啟動(dòng)時(shí)向ZK注冊(cè)臨時(shí)節(jié)點(diǎn)誰(shuí)搶到鎖誰(shuí)就是ActiveZK保證只有一個(gè)贏家狀態(tài)存儲(chǔ)ZK保存當(dāng)前Active節(jié)點(diǎn)的標(biāo)識(shí)以及集群的命名空間信息分布式鎖與腦裂防護(hù)Active節(jié)點(diǎn)必須持續(xù)持有ZK上的一個(gè)分布式鎖一旦鎖丟了就得立即釋放所有資源并退位防止雙Active同時(shí)寫edits日志造成數(shù)據(jù)損壞。理解了這一層你就明白了為什么“hadoop和zookeeper整合實(shí)戰(zhàn)”不是單純的“裝兩個(gè)軟件然后配置上”而是一套完整的分布式一致性協(xié)作機(jī)制。3.2 HA整合配置的落地步驟實(shí)戰(zhàn)部分我用兩個(gè)NameNode、三臺(tái)JournalNode的典型HA拓?fù)鋪?lái)講。先規(guī)劃角色節(jié)點(diǎn)運(yùn)行組件node1NameNode, ZKFC, JournalNode, Zookeeper, DataNodenode2NameNode, ZKFC, JournalNode, Zookeeper, DataNodenode3JournalNode, Zookeeper, DataNode第一步確認(rèn)Zookeeper集群本身正常。每個(gè)Zookeeper節(jié)點(diǎn)上配置myid文件內(nèi)容分別是1、2、3然后在zoo.cfg里配置三個(gè)節(jié)點(diǎn)的地址和端口。啟動(dòng)后執(zhí)行zkServer.sh status看到其中一個(gè)顯示leader、其他兩個(gè)顯示follower說(shuō)明ZK集群健康。第二步配置core-site.xml。關(guān)鍵項(xiàng)是fs.defaultFS它必須指向一個(gè)邏輯名稱而不是某個(gè)具體節(jié)點(diǎn)configuration property namefs.defaultFS/name valuehdfs://mycluster/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configuration這里的mycluster是一個(gè)邏輯名稱兩臺(tái)NameNode的地址會(huì)在下一步的hdfs-site.xml里映射到這個(gè)名稱上。第三步配置hdfs-site.xml。這是整合的絕對(duì)重點(diǎn)configuration !-- 啟用HA -- property namedfs.nameservices/name valuemycluster/value /property !-- 兩個(gè)NameNode的邏輯ID -- property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property !-- 兩個(gè)NameNode的RPC地址 -- property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /property !-- 兩個(gè)NameNode的HTTP地址 -- property namedfs.namenode.http-address.mycluster.nn1/name valuenode1:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenode2:9870/value /property !-- JournalNode地址列表 -- property namedfs.namenode.shared.edits.dir/name valueqjournal://node1:8485;node2:8485;node3:8485/mycluster/value /property !-- 故障自動(dòng)切換實(shí)現(xiàn)類 -- property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property !-- ZKFC參數(shù) -- property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configuration這段配置的核心是qjournal地址。它是HA元數(shù)據(jù)同步的通道。所有edits日志都會(huì)同步寫入三臺(tái)JournalNode只要有兩臺(tái)成功落盤事務(wù)就算成功了。這就是為什么JournalNode必須奇數(shù)臺(tái)且至少三臺(tái)的原因——過半寫成功才能保證一致性和可用性。第四步啟動(dòng)順序與格式化。這里有個(gè)非常關(guān)鍵的細(xì)節(jié)很多人栽在這里。HA集群的格式化順序必須是先啟動(dòng)所有Zookeeper節(jié)點(diǎn)在其中一臺(tái)NameNode上執(zhí)行hdfs zkfc -formatZK在ZK中初始化HA狀態(tài)在一臺(tái)NameNode上執(zhí)行hdfs namenode -format生成初始元數(shù)據(jù)啟動(dòng)這臺(tái)NameNode讓它成為Active在另一臺(tái)NameNode上執(zhí)行hdfs namenode -bootstrapStandby從Active同步元數(shù)據(jù)啟動(dòng)所有JournalNode和DataNode最后啟動(dòng)Standby的ZKFC進(jìn)程。順序錯(cuò)了會(huì)怎樣如果ZK還沒就緒就去格式化NameNode格式化雖然可能成功但ZKFC注冊(cè)時(shí)會(huì)報(bào)錯(cuò)如果沒有先f(wàn)ormatZK就直接啟動(dòng)ZKFCZK里沒有對(duì)應(yīng)的HA狀態(tài)鎖自動(dòng)切換配置不會(huì)生效。這些都是我實(shí)際排障時(shí)見過的高頻問題。第五步驗(yàn)證failover是否真的生效。這一步極重要因?yàn)椤芭渲昧薍A”和“HA真的能切換”是兩回事。驗(yàn)證方法如下# 查看當(dāng)前Active節(jié)點(diǎn) hdfs haadmin -getAllServiceState # 手動(dòng)觸發(fā)一次故障轉(zhuǎn)移 hdfs haadmin -failover nn1 nn2 # 再次查看狀態(tài)應(yīng)該看到nn2變成active hdfs haadmin -getAllServiceState更狠的驗(yàn)證是直接kill掉Active NameNode進(jìn)程觀察ZKFC是否在幾秒內(nèi)自動(dòng)把Standby提升為Active。我在實(shí)際項(xiàng)目里都會(huì)做一次這個(gè)演練因?yàn)樗鼙┞逗芏嗯渲脤用娴碾[蔽問題。比如fencing機(jī)制沒生效時(shí)原來(lái)那個(gè)“假死”的NameNode可能會(huì)在網(wǎng)絡(luò)恢復(fù)后繼續(xù)請(qǐng)求寫edits日志導(dǎo)致數(shù)據(jù)不一致。生產(chǎn)環(huán)境里這種演練很危險(xiǎn)必須在維護(hù)窗口期做。3.3 整合中最容易翻車的細(xì)節(jié)第一個(gè)坑ZKFC進(jìn)程不是NameNode。我發(fā)現(xiàn)很多人SSH到節(jié)點(diǎn)上看HA狀態(tài)時(shí)只關(guān)注NameNode進(jìn)程是否存活忽略了ZKFC。但自動(dòng)切換的決策者是ZKFC不是NameNode本身。如果ZKFC掛了即使NameNode活著故障自動(dòng)切換也不會(huì)生效。所以監(jiān)控里一定要把ZKFC進(jìn)程納進(jìn)來(lái)。第二個(gè)坑quorum過半機(jī)制導(dǎo)致ZK集群自身可用性成為瓶頸。三臺(tái)ZK允許掛一臺(tái)兩臺(tái)掛掉整個(gè)ZK就不可用了。而ZK一旦不可用HDFS雖然還能繼續(xù)讀寫因?yàn)閑dits日志寫的是JournalNode不是ZK但故障自動(dòng)切換會(huì)完全失效。這是個(gè)很讓人迷惑的現(xiàn)象集群跑著跑著突然發(fā)現(xiàn)永遠(yuǎn)無(wú)法切換了查了一圈才發(fā)現(xiàn)是ZK集群只剩一臺(tái)活著的節(jié)點(diǎn)。第三個(gè)坑數(shù)據(jù)目錄權(quán)限問題。JournalNode的數(shù)據(jù)目錄dfs.journalnode.edits.dir和NameNode元數(shù)據(jù)目錄dfs.namenode.name.dir如果權(quán)限不是啟動(dòng)用戶格式化階段就會(huì)直接失敗。這在“數(shù)據(jù)目錄掛載了新磁盤”的場(chǎng)景特別常見——新磁盤掛載點(diǎn)是root用戶格式化時(shí)用hdfs用戶去寫直接Permission denied。4. 格式化、啟動(dòng)與元數(shù)據(jù)第一個(gè)大坑在這里4.1 namenode -format到底做了什么“Hadoop啟動(dòng)格式化失敗”能上熱搜說(shuō)明遇到這個(gè)坑的人不是少數(shù)。要理解格式化為什么會(huì)失敗得先知道它做了什么。hdfs namenode -format做的事情本質(zhì)上是對(duì)NameNode的元數(shù)據(jù)目錄做初始化創(chuàng)建目錄結(jié)構(gòu)在dfs.namenode.name.dir配置的路徑下創(chuàng)建current目錄、edits目錄等生成VERSION文件里面記錄了namespaceID、clusterID、blockPoolID等標(biāo)識(shí)生成初始的fsimage空集群的元數(shù)據(jù)快照。這些標(biāo)識(shí)太重要了。clusterID標(biāo)識(shí)的是整個(gè)HDFS集群namespaceID標(biāo)識(shí)的是命名空間blockPoolID標(biāo)識(shí)的是數(shù)據(jù)塊池。DataNode注冊(cè)到NameNode時(shí)會(huì)帶上自己理解的clusterID。如果DataNode磁盤上保存的clusterID跟NameNode當(dāng)前的不一致DataNode就會(huì)被拒絕注冊(cè)。“格式化失敗”的高頻原因總結(jié)起來(lái)就這幾類我給新手排障會(huì)照著這個(gè)表查失敗現(xiàn)象根因解決方式Permission denied元數(shù)據(jù)目錄屬主不對(duì)chown到啟動(dòng)用戶Directory is not empty之前格式化過殘留舊元數(shù)據(jù)確認(rèn)無(wú)價(jià)值后清空目錄或指定新目錄啟動(dòng)進(jìn)程秒退堆內(nèi)存參數(shù)不合理檢查HADOOP_HEAPSIZE / HADOOP_NAMENODE_OPTSjava.io.IOException: Cannot create directory父目錄不存在手動(dòng)創(chuàng)建目錄并賦權(quán)格式化和上電后DataNode找不到集群clusterID不一致要么備份后統(tǒng)一清空DataNode數(shù)據(jù)目錄要么手動(dòng)同步clusterID補(bǔ)充一個(gè)很容易忽略的細(xì)節(jié)格式化過程會(huì)輸出一行Storage directory ... has been successfully formatted但這只是針對(duì)這臺(tái)NameNode的存儲(chǔ)目錄格式化了。在HA場(chǎng)景下你只格式化了一臺(tái)NameNode的元數(shù)據(jù)存儲(chǔ)另一臺(tái)必須通過-bootstrapStandby來(lái)同步不能直接在第二臺(tái)上再執(zhí)行一次-format。如果你在第二臺(tái)NameNode上重新格式化了兩臺(tái)NameNode會(huì)生成不同的clusterID整個(gè)集群的DataNode都會(huì)因?yàn)閏lusterID對(duì)不上而拒絕注冊(cè)。這是我在生產(chǎn)環(huán)境見過最慘烈的一次事故大家務(wù)必引以為戒。4.2 啟動(dòng)失敗的三類場(chǎng)景與完整排查鏈路啟動(dòng)階段是故障高發(fā)區(qū)。下面這三類場(chǎng)景是我在幫人排查時(shí)遇到最多的。場(chǎng)景ADataNode起不來(lái)日志反復(fù)報(bào)“Incompatible clusterIDs”。DataNode啟動(dòng)時(shí)會(huì)比對(duì)本地存儲(chǔ)的clusterID和NameNode廣播的clusterID。為什么會(huì)不一致因?yàn)槟愀袷交^NameNode多次每次格式化都會(huì)生成新的clusterID而DataNode的數(shù)據(jù)目錄里還保留著上一次的clusterID。排查鏈路# 1. 看DataNode日志 tail -100 /opt/hadoop/logs/hadoop-hdfs-datanode-node.log # 日志里會(huì)出現(xiàn)類似 # Incompatible clusterIDs in /data/hdfs/datanode: # namenode clusterID CID-xxx # datanode clusterID CID-yyy # 2. 確認(rèn)兩個(gè)clusterID確實(shí)不一致 cat /opt/hadoop/logs/../dfs/name/current/VERSION cat /data/hdfs/datanode/current/VERSION # 3. 解決備份數(shù)據(jù)目錄后清空或者手動(dòng)改clusterID # 清空數(shù)據(jù)目錄注意確認(rèn)無(wú)未備份數(shù)據(jù) rm -rf /data/hdfs/datanode/current/*場(chǎng)景BNameNode進(jìn)程起來(lái)沒幾秒就退出日志無(wú)異常。這是最典型的資源問題。NameNode默認(rèn)堆內(nèi)存是1GB元數(shù)據(jù)一多就OOM。老手一般會(huì)在hadoop-env.sh里顯式設(shè)置HADOOP_NAMENODE_OPTS-Xmx8g。但這只是第一層你還要確認(rèn)NameNode所在的機(jī)器物理內(nèi)存夠不夠以及是否被其他進(jìn)程搶占了。我見過一個(gè)案例兩臺(tái)機(jī)器都裝了很多組件NameNode堆內(nèi)存給了8GB但機(jī)器總共只有16GB且JVM除了堆還要用堆外內(nèi)存和元空間實(shí)際占用超過物理內(nèi)存后系統(tǒng)開始瘋狂swapNameNode的響應(yīng)越來(lái)越慢最終被ZKFC判定為假死觸發(fā)切換。反過來(lái)另一臺(tái)機(jī)器也遇到同樣問題兩個(gè)NameNode開始反復(fù)互切整個(gè)HDFS的讀寫都斷了。場(chǎng)景C節(jié)點(diǎn)間通信失敗最隱蔽的是防火墻。Hadoop集群的節(jié)點(diǎn)間通信端口特別多NameNode RPC 8020、DataNode RPC 9866、ZK 2181/2888/3888、JournalNode 8485……有些企業(yè)安全基線會(huì)要求只開放特定端口于是你經(jīng)常遇到這樣一種情況進(jìn)程都活著服務(wù)看起來(lái)正常但就是連不上。排查鏈路很標(biāo)準(zhǔn)# 1. 先測(cè)基礎(chǔ)連通性 ping node1 telnet node1 8020 # 2. 如果通則看端口監(jiān)聽 netstat -anp | grep 8020 # 3. 如果監(jiān)聽正常但外部不通基本就是防火墻 systemctl status firewalld iptables -L -n # 或者云安全組的入站規(guī)則注意很多云廠商的安全組在控制臺(tái)上看起來(lái)放行了端口但節(jié)點(diǎn)內(nèi)部自身的iptables規(guī)則沒同步也會(huì)出現(xiàn)“控制臺(tái)顯示放行但實(shí)際不通”的詭異現(xiàn)象。檢查的時(shí)候兩邊都要看。4.3 元數(shù)據(jù)保護(hù)的經(jīng)驗(yàn)格式化、啟動(dòng)只是元數(shù)據(jù)話題的冰山一角。真正到了生產(chǎn)NameNode元數(shù)據(jù)就是你的命根子。HDFS元數(shù)據(jù)由兩部分組成fsimage是元數(shù)據(jù)的持久化快照edits是每次寫操作的增量日志。NameNode每次啟動(dòng)都會(huì)把fsimage加載進(jìn)內(nèi)存再重放edits里的增量事務(wù)。這里有個(gè)關(guān)鍵概念checkpoint。舊版Hadoop用SecondaryNameNode定期合并fsimage和edits把合并后的新fsimage傳回NameNode。但在HA架構(gòu)里這個(gè)角色已經(jīng)被Standby NameNode替代了。Standby節(jié)點(diǎn)持續(xù)從JournalNode讀取edits日志并應(yīng)用同時(shí)周期性執(zhí)行checkpoint生成新的fsimage。這個(gè)機(jī)制給運(yùn)維的啟示是不要對(duì)Standby NameNode做任何停機(jī)操作它正在承擔(dān)checkpoint職責(zé)。一停fsimage和edits的合并就會(huì)停滯edits會(huì)無(wú)限增長(zhǎng)最終可能把磁盤寫滿fsimage備份必須定期做。最簡(jiǎn)單的方式是把fsimage目錄掛到獨(dú)立的存儲(chǔ)或者用cron定期打包到一個(gè)安全位置數(shù)據(jù)盤和數(shù)據(jù)盤之間要物理隔離。NameNode的元數(shù)據(jù)目錄和DataNode的數(shù)據(jù)目錄放在同一塊磁盤上是災(zāi)難——DataNode磁盤寫滿會(huì)導(dǎo)致整個(gè)文件系統(tǒng)讀寫異常間接把NameNode拖掛。5. 生態(tài)整合完成之后日常運(yùn)維怎么排查問題5.1 先看日志再看監(jiān)控最后才碰配置這是我做運(yùn)維排查奉行的鐵律順序不能亂。很多人一遇到集群異常第一反應(yīng)就是懷疑配置錯(cuò)了開始翻配置文件、改參數(shù)。這個(gè)習(xí)慣很不好——配置在集群運(yùn)行期間被外部惡意改動(dòng)的情況極少更多時(shí)候配置沒變是某個(gè)運(yùn)行條件變了。正確的排查順序是先看日志定位現(xiàn)象再對(duì)照監(jiān)控找規(guī)律最后才去懷疑配置。Hadoop生態(tài)各組件的日志位置和重點(diǎn)我用一張表整理出來(lái)排查的時(shí)候照著看組件日志位置排查時(shí)重點(diǎn)看的日志NameNode$HADOOP_HOME/logs/hadoop-hdfs-namenode-*.log啟動(dòng)異常、元數(shù)據(jù)操作、checkpoint過程DataNode$HADOOP_HOME/logs/hadoop-hdfs-datanode-*.log塊上報(bào)、數(shù)據(jù)復(fù)制、磁盤異常ZKFC$HADOOP_HOME/logs/hadoop-hdfs-zkfc-*.log選主過程、鎖競(jìng)爭(zhēng)、腦裂防護(hù)動(dòng)作Zookeeper$ZK_HOME/logs/zookeeper-*.out會(huì)話超時(shí)、選舉日志YARN ResourceManager$HADOOP_HOME/logs/yarn--resourcemanager-.log調(diào)度日志、容器分配、隊(duì)列狀態(tài)YARN NodeManager$HADOOP_HOME/logs/yarn--nodemanager-.log容器啟動(dòng)失敗、本地磁盤管理拿一個(gè)我給朋友真實(shí)排查過的案例來(lái)講。某次集群突然變卡所有作業(yè)都在排隊(duì)。我第一反應(yīng)沒有去改YARN配置而是按順序查看ResourceManager日志發(fā)現(xiàn)隊(duì)列里全是ACCEPTED狀態(tài)的任務(wù)但CONTAINER一直創(chuàng)建不出來(lái)看NodeManager日志發(fā)現(xiàn)大量“Container killed on request”和“Local dir is full”字樣順藤摸瓜查磁盤使用率發(fā)現(xiàn)NodeManager的本地目錄所在分區(qū)使用率到了99%。根因根本不是配置問題是磁盤滿了。YARN在調(diào)度容器時(shí)發(fā)現(xiàn)本地目錄寫不進(jìn)去只能反復(fù)殺掉容器導(dǎo)致集群看起來(lái)是“卡死”實(shí)際上是“磁盤被寫滿后的自我保護(hù)”。清理掉日志和臨時(shí)文件后集群馬上恢復(fù)了。這個(gè)案例完美說(shuō)明了“日志定位現(xiàn)象”的價(jià)值。如果你一上來(lái)就懷疑隊(duì)列配置不對(duì)把隊(duì)列容量參數(shù)調(diào)來(lái)調(diào)去不僅解決不了問題還可能把原來(lái)正常的調(diào)度策略搞亂。5.2 資源層面的排查內(nèi)存、磁盤、網(wǎng)絡(luò)、連接數(shù)企業(yè)級(jí)運(yùn)維中資源和連接層面的問題占比最高我把高頻問題整理成速查表問題現(xiàn)象直接原因檢查方法作業(yè)提交后一直ACCEPTEDYARN隊(duì)列資源被大任務(wù)占滿ResourceManager Web UI里看隊(duì)列資源容器啟動(dòng)即失敗NodeManager本地目錄無(wú)空間df -h 查看NodeManager日志DataNode進(jìn)程消失文件句柄數(shù)超過系統(tǒng)限制ulimit -n / /etc/security/limits.conf大量連接進(jìn)入TIME_WAIT短連接過多端口耗盡ss -s 查看socket統(tǒng)計(jì)節(jié)點(diǎn)失聯(lián)NameNode報(bào)heartbeat timeout網(wǎng)絡(luò)抖動(dòng)或GC暫停過長(zhǎng)查看NameNode和DataNode日志時(shí)間線HDFS寫入超時(shí)數(shù)據(jù)目錄所在磁盤IO飽和iostat -x 1 觀察await值內(nèi)存這塊再展開一點(diǎn)。很多人只知道YARN有yarn.nodemanager.resource.memory-mb這個(gè)參數(shù)卻不知道它還分physical memory和virtual memory兩層限制。默認(rèn)情況下NM會(huì)檢查容器使用的虛擬內(nèi)存超過配置的yarn.nodemanager.vmem-pmem-ratio倍數(shù)后直接殺掉容器。這個(gè)比例默認(rèn)是2.1如果容器內(nèi)用了大量native內(nèi)存比如Python進(jìn)程、跑JNI的庫(kù)很容易觸發(fā)誤殺。日志里你會(huì)看到一行Container [pidxxx] is running beyond virtual memory limits遇到這種先別急著調(diào)大比例應(yīng)確認(rèn)容器是不是真的內(nèi)存泄漏確認(rèn)沒泄漏后再顯式調(diào)高yarn.nodemanager.vmem-pmem-ratio或關(guān)閉該檢查yarn.nodemanager.vmem-check-enabledfalse不推薦直接關(guān)。5.3 面試題背后的原理就是排查思路的底層邏輯熱搜詞里有個(gè)“hadoop面試題”我多說(shuō)兩句。大家準(zhǔn)備面試時(shí)背的那些題表面上是考概念實(shí)際上是在考你對(duì)系統(tǒng)運(yùn)行機(jī)制的理解。面試題和運(yùn)維排障是同一套底層的認(rèn)知模型。舉個(gè)例子。面試官問“NameNode掛了怎么辦”你會(huì)怎么答背出的答案是“HA自動(dòng)切換Standby接管”。但這背后至少要有幾層更深的認(rèn)知如何判斷NameNode“掛了”是進(jìn)程不存在還是ZKFC判定它心跳丟失如果是網(wǎng)絡(luò)分區(qū)導(dǎo)致的假活fencing機(jī)制怎么防止雙ActiveStandby接管后之前未提交的事務(wù)怎么辦答案在JournalNode的edits日志里客戶端怎么知道該連新的Active靠的是failover proxy provider里配置的邏輯名稱。這些問題每一個(gè)都對(duì)應(yīng)真實(shí)的故障排查場(chǎng)景。我在4.2節(jié)、5.1節(jié)講的案例本質(zhì)上就是在回答這類面試題。所以我不建議你死背面試題如果你能親手復(fù)現(xiàn)一次NameNode failover的全過程很多面試題不用背自然就會(huì)了。6. 從學(xué)習(xí)環(huán)境到企業(yè)環(huán)境的最后一公里6.1 開發(fā)環(huán)境搭建Windows與容器化實(shí)踐細(xì)節(jié)很多人在“windows下載hadoop”這一步栽過跟頭。Windows上裝Hadoop確實(shí)能跑但要改bin目錄下的winutils.exe要處理路徑分隔符、權(quán)限模擬等問題體驗(yàn)很折騰。我個(gè)人的經(jīng)驗(yàn)是Windows環(huán)境我只用來(lái)做三件事——看源碼、跑IDE代碼調(diào)試、連接遠(yuǎn)程集群測(cè)試客戶端代碼。真正的本地集群驗(yàn)證一律用Docker Desktop。在Docker里搭Hadoop時(shí)我常用這樣的參數(shù)組合docker network create --driver bridge hadoop-net # 啟動(dòng)一個(gè)NameNode節(jié)點(diǎn) docker run -d --name namenode \ --network hadoop-net \ -p 9870:9870 \ -v /data/hadoop/namenode:/hadoop/dfs/name \ -e CORE_CONF_fs_defaultFShdfs://namenode:8020 \ -e HDFS_CONF_dfs_namenode_http-addressnamenode:9870 \ -e HDFS_CONF_dfs_replication2 \ hadoop-docker-image # 啟動(dòng)兩個(gè)DataNode節(jié)點(diǎn) docker run -d --name datanode1 \ --network hadoop-net \ -v /data/hadoop/datanode1:/hadoop/dfs/data \ -e CORE_CONF_fs_defaultFShdfs://namenode:8020 \ hadoop-docker-image用環(huán)境變量方式傳配置是容器化部署Hadoop的一個(gè)實(shí)用技巧。Hadoop官方鏡像和社區(qū)鏡像大多會(huì)支持把xxx_yyy格式的環(huán)境變量自動(dòng)轉(zhuǎn)成配置文件里的屬性不用手動(dòng)進(jìn)容器改XML。這樣疊加Docker Compose一套三節(jié)點(diǎn)集群的啟動(dòng)腳本就非常清爽了。如果是“hadoop開發(fā)環(huán)境搭建頭歌”這類在線實(shí)驗(yàn)平臺(tái)我的建議是拿來(lái)練練手可以但別依賴。在線平臺(tái)幫你把環(huán)境都準(zhǔn)備好了你反而缺失了從裸機(jī)搭建、遇到問題再解決的過程。而這個(gè)過程才是進(jìn)階的關(guān)鍵。真正區(qū)分“會(huì)用”和“懂”的永遠(yuǎn)是你能不能從零到一搭出一套跑得起來(lái)的、你自己完全理解每一行配置的系統(tǒng)。6.2 用一次完整的故障演練檢驗(yàn)?zāi)闶欠裾娴倪M(jìn)階了最后分享一個(gè)我特別推薦的學(xué)習(xí)方法主動(dòng)制造一次故障然后嘗試自己修復(fù)。具體做法很簡(jiǎn)單。挑一個(gè)維護(hù)窗口在測(cè)試集群上按照下面這個(gè)清單一步一步來(lái)手動(dòng)kill掉Active NameNode進(jìn)程觀察集群行為看ZKFC能否在預(yù)期時(shí)間內(nèi)完成切換再kill掉一個(gè)DataNode進(jìn)程觀察HDFS的副本復(fù)制機(jī)制如何工作看剩余節(jié)點(diǎn)能否正常提供讀寫停掉全部ZK節(jié)點(diǎn)觀察HDFS的反應(yīng)——它不會(huì)立刻掛但你會(huì)發(fā)現(xiàn)failover功能失效了在YARN上提交一個(gè)超內(nèi)存作業(yè)觀察容器被殺的過程理解資源隔離的作用故意寫錯(cuò)一處配置比如把DataNode的目錄指向不存在路徑觀察啟動(dòng)失敗日志練習(xí)定位問題。這個(gè)演練的價(jià)值在于它逼著你在“沒有教程指引”的情況下面對(duì)真實(shí)故障逼著你親手翻開日志、比對(duì)狀態(tài)、修改配置。你會(huì)經(jīng)歷第一次恐慌然后學(xué)會(huì)冷靜最后建立一套屬于自己的排查直覺。我在帶人時(shí)發(fā)現(xiàn)一個(gè)規(guī)律愿意做這種演練的人面試時(shí)談吐和對(duì)系統(tǒng)的理解能力跟只刷教程的人完全不在一個(gè)量級(jí)。原因很簡(jiǎn)單——你對(duì)系統(tǒng)的信任感不會(huì)來(lái)自看了多少篇文檔而是來(lái)自你親手搞壞過它、再親手把它修好的次數(shù)。Hadoop這條路從入門到熟練中間沒有捷徑但也沒有想象中那么艱難。裝一套環(huán)境拆一個(gè)組件讀一段日志修一個(gè)故障每一步都算數(shù)。希望這篇沉淀下來(lái)的實(shí)戰(zhàn)經(jīng)驗(yàn)?zāi)茏屇闵俨葞讉€(gè)我已經(jīng)替你踩過的坑。 Hadoop企業(yè)級(jí)實(shí)戰(zhàn)：集群搭建、HA與Zookeeper整合排障指南
我?guī)н^不少新人也幫人排查過不少集群?jiǎn)栴}。有個(gè)現(xiàn)象特別普遍很多人把Hadoop偽分布式搭起來(lái)、跑通一個(gè)WordCount就覺得Hadoop這關(guān)過了。但真到了企業(yè)級(jí)項(xiàng)目里面對(duì)一個(gè)多節(jié)點(diǎn)集群、跟Zookeeper等生態(tài)組件深度整合之后問題根本不是“跑通”兩個(gè)字能覆蓋的。格式化失敗、DataNode注冊(cè)不上、NameNode莫名其妙掛掉、HA自動(dòng)切換不生效隨便一個(gè)故障都能讓人卡住一整天。這篇東西寫給那些已經(jīng)跨過入門、正準(zhǔn)備往進(jìn)階走的人。不管你是要準(zhǔn)備Hadoop面試還是公司里要上一套真正能扛業(yè)務(wù)的集群又或者只是被“ambari部署hadoop集群”“hadoop啟動(dòng)格式化失敗”這種問題折磨到懷疑人生下面的內(nèi)容都應(yīng)該能幫上忙。我會(huì)按企業(yè)級(jí)落地時(shí)最容易出問題的那幾條線來(lái)講部署路線怎么選、HA怎么跟Zookeeper整合、格式化與啟動(dòng)階段有哪些坑、日常故障怎么一步步查以及最后怎么用一套“故障演練”的方式把知識(shí)變成自己的。1. 能跑通Demo和能扛住生產(chǎn)中間隔著什么1.1 偽分布式容易給人“我已經(jīng)會(huì)Hadoop”的錯(cuò)覺很多教程喜歡讓人從偽分布式開始這沒問題但它帶來(lái)的最大副作用是偽分布式跑得太順了順到讓人誤以為Hadoop就是“改幾個(gè)配置文件啟動(dòng)幾個(gè)進(jìn)程”的事兒。偽分布式本質(zhì)上是在一臺(tái)機(jī)器上用多個(gè)Java進(jìn)程模擬分布式。它沒有真實(shí)的網(wǎng)絡(luò)IO沒有跨節(jié)點(diǎn)通信沒有機(jī)架感知也沒有資源競(jìng)爭(zhēng)。你在偽分布式里看到的日志永遠(yuǎn)干干凈凈你在偽分布式里執(zhí)行的格式化永遠(yuǎn)一次成功。但所有這些“順利”都是假象恰恰是進(jìn)階路上最危險(xiǎn)的起點(diǎn)。到了真實(shí)集群環(huán)境你面對(duì)的是完全不同的復(fù)雜度網(wǎng)絡(luò)成為第一道坎。節(jié)點(diǎn)之間要互相解析主機(jī)名防火墻要放行一堆端口機(jī)架感知策略會(huì)影響副本存放。偽分布式里從來(lái)沒有這個(gè)概念。資源是有限的。NameNode的內(nèi)存決定了能支撐多少文件元數(shù)據(jù)DataNode的磁盤決定了能存多少數(shù)據(jù)塊YARN的調(diào)度器決定了任務(wù)能不能擠進(jìn)去。偽分布式不關(guān)心這些因?yàn)樗袞|西都在一臺(tái)機(jī)器上。故障是常態(tài)。一個(gè)節(jié)點(diǎn)掉線、一塊磁盤寫滿、一次Full GC導(dǎo)致心跳超時(shí)都可能導(dǎo)致整個(gè)集群進(jìn)入降級(jí)狀態(tài)。偽分布式里的進(jìn)程掛了你馬上知道生產(chǎn)環(huán)境里一個(gè)節(jié)點(diǎn)無(wú)響應(yīng)你可能要翻半天日志。我見過太多人面試時(shí)把HDFS架構(gòu)背得滾瓜爛熟真到了集群上連“DataNode為什么起不來(lái)”都無(wú)從下手。原因很簡(jiǎn)單他們學(xué)的是“結(jié)構(gòu)”不是“行為”。企業(yè)級(jí)項(xiàng)目實(shí)戰(zhàn)要補(bǔ)的恰恰是后一半。1.2 企業(yè)級(jí)項(xiàng)目的重心其實(shí)在Hadoop之外還有一個(gè)更隱蔽的認(rèn)知偏差很多人以為企業(yè)級(jí)項(xiàng)目 把Hadoop集群搭得更大、更快。真不是這樣。企業(yè)級(jí)項(xiàng)目的難點(diǎn)一大半在Hadoop之外在生態(tài)整合與運(yùn)維體系建設(shè)上。Hadoop只是一個(gè)底座底座之上掛著一堆組件Zookeeper管協(xié)調(diào)、YARN管調(diào)度、Hive管數(shù)倉(cāng)、HBase管在線查詢、Kafka管數(shù)據(jù)接入。這些組件單獨(dú)看都不難難的是它們咬合在一起之后出了問題你很難判斷是哪一環(huán)掉了鏈子。舉個(gè)例子一個(gè)Hive查詢突然變慢可能的根因包括HDFS某個(gè)DataNode磁盤IO異常導(dǎo)致讀取走了慢路徑Y(jié)ARN隊(duì)列資源被別的任務(wù)占滿你的任務(wù)一直在排隊(duì)Zookeeper會(huì)話超時(shí)導(dǎo)致HBase RegionServer在做無(wú)謂的自我恢復(fù)甚至是NameNode在做checkpoint時(shí)搶占了大量IO間接拖慢了整個(gè)HDFS。這種問題只懂Hadoop本身是搞不定的。你必須對(duì)整個(gè)生態(tài)的運(yùn)行機(jī)制有清晰的認(rèn)知知道哪個(gè)組件的數(shù)據(jù)流向哪里、它依賴誰(shuí)、掛了會(huì)有什么表現(xiàn)。這才是“生態(tài)深度整合”這四個(gè)字的真正含義也是這篇文章試圖幫你建立的主干思維。2. 集群搭建的三條路線手動(dòng)、Ambari、容器化怎么選2.1 手動(dòng)搭建值得走一遍但別在生產(chǎn)環(huán)境硬扛我始終建議每個(gè)進(jìn)階者手動(dòng)搭一遍Hadoop集群哪怕只是三個(gè)節(jié)點(diǎn)。原因很簡(jiǎn)單手動(dòng)搭建能逼著你把每個(gè)配置項(xiàng)的含義弄清楚而不是讓工具替你把這些細(xì)節(jié)全部藏起來(lái)。但手動(dòng)搭建只適合學(xué)習(xí)不適合當(dāng)生產(chǎn)環(huán)境的長(zhǎng)期運(yùn)維方案。你手動(dòng)搭起來(lái)的集群沒有統(tǒng)一的配置管理沒有完善的可視化監(jiān)控沒有組件間的健康檢查。一旦規(guī)模超過十個(gè)節(jié)點(diǎn)手動(dòng)運(yùn)維會(huì)變成一場(chǎng)災(zāi)難。版本選型是手動(dòng)搭建的第一步。我這里不想把Apache、CDH、HDP的版本歷史鋪開講就講現(xiàn)狀Cloudera和Hortonworks合并之后CDH成了商業(yè)產(chǎn)品HDP的開源脈絡(luò)則由Cloudera的開源發(fā)行版延續(xù)但整體都偏向商用訂閱如果你想要純開源、不涉及商業(yè)授權(quán)煩惱的路線Apache Hadoop社區(qū)版是唯一穩(wěn)妥的選擇。版本號(hào)上Hadoop 3.x已經(jīng)是絕對(duì)主流3.1.x和3.3.x用得最多。3.3.x修復(fù)了不少3.1.x遺留的問題新項(xiàng)目建議直接上3.3.x。手動(dòng)搭建時(shí)有幾個(gè)配置項(xiàng)是無(wú)論如何都要搞懂的配置文件關(guān)鍵配置項(xiàng)它的作用core-site.xmlfs.defaultFS指定NameNode的RPC地址客戶端和DataNode全靠它找到“老大”hdfs-site.xmldfs.replication數(shù)據(jù)塊副本數(shù)決定了容錯(cuò)能力與存儲(chǔ)成本的平衡hdfs-site.xmldfs.namenode.name.dirNameNode元數(shù)據(jù)存儲(chǔ)路徑必須放在獨(dú)立磁盤上不能跟系統(tǒng)盤混用yarn-site.xmlyarn.nodemanager.resource.memory-mb單個(gè)NodeManager可用的物理內(nèi)存上限直接決定容器能開多大mapred-site.xmlmapreduce.framework.name必須設(shè)為yarn否則MapReduce任務(wù)不會(huì)走YARN調(diào)度另外環(huán)境準(zhǔn)備這一步千萬(wàn)別跳所有節(jié)點(diǎn)之間要配置SSH免密登錄系統(tǒng)時(shí)間必須用NTP同步差一分鐘都可能引發(fā)Kerberos認(rèn)證失敗或心跳異常JDK版本必須完全一致最好連JDK的安裝在哪個(gè)路徑都保持一致。這一步能給你省掉后面80%的玄學(xué)故障。2.2 Ambari部署中大規(guī)模集群的運(yùn)維入口如果公司要搭一套十幾個(gè)節(jié)點(diǎn)以上的集群我建議別掙扎了直接上Ambari這類工具。Ambari的價(jià)值不在于“一鍵安裝”——真正裝過的人都知道它也不是完全一鍵。它的核心價(jià)值是集中化配置管理所有組件的核心配置項(xiàng)都在Web界面上改改完能統(tǒng)一分發(fā)到所有節(jié)點(diǎn)還能選擇是否滾動(dòng)重啟服務(wù)健康檢查每個(gè)組件的存活狀態(tài)、告警規(guī)則、指標(biāo)趨勢(shì)都集中展示省去了逐臺(tái)機(jī)器翻日志的苦力活擴(kuò)縮容友好新增一個(gè)DataNode節(jié)點(diǎn)界面上填上主機(jī)名和SSH憑據(jù)就行了。但Ambari也有幾個(gè)典型的坑我踩過身邊的人也踩過Ambari Server自身的內(nèi)存占用比預(yù)想的高。默認(rèn)的2GB堆內(nèi)存在組件多的時(shí)候會(huì)有明顯壓力我的建議是至少給Ambari Server分配4GB以上。如果你把Ambari和NameNode放在同一臺(tái)機(jī)器上更要提前調(diào)好內(nèi)存分配。Agent注冊(cè)失敗是高頻問題。Ambari Agent向Server注冊(cè)時(shí)要求兩邊主機(jī)名能互相解析。很多人只配了/etc/hosts但沒配好防火墻導(dǎo)致Agent注冊(cè)超時(shí)。處理方式很粗暴也很有效先確認(rèn)hostname一致再確認(rèn)防火墻放行8080和8440/8441端口最后重啟Agent看日志。藍(lán)屏問題。這里的“藍(lán)屏”是Ambari界面上組件狀態(tài)變藍(lán)表示“未安裝”。最常見的原因是你手動(dòng)在某個(gè)節(jié)點(diǎn)上裝了組件之后用Ambari管理時(shí)狀態(tài)就錯(cuò)亂了。記住一條鐵律Ambari管理的集群所有操作都通過Ambari做永遠(yuǎn)不要手動(dòng)去改它管理范圍內(nèi)的配置文件和啟動(dòng)腳本。2.3 Docker鏡像搭建學(xué)習(xí)驗(yàn)證的最優(yōu)解生產(chǎn)的禁區(qū)Docker跑Hadoop這幾年越來(lái)越流行因?yàn)閷?duì)學(xué)習(xí)來(lái)說(shuō)它實(shí)在太方便了。不需要準(zhǔn)備一堆虛擬機(jī)一條命令就能拉起一套集群跑完就刪干凈利落。我自己用Docker方式做過完整的三節(jié)點(diǎn)Hadoop集群體驗(yàn)是用來(lái)驗(yàn)證配置修改、測(cè)試作業(yè)邏輯、準(zhǔn)備面試場(chǎng)景效率無(wú)敵。但要注意幾個(gè)關(guān)鍵細(xì)節(jié)網(wǎng)絡(luò)模式用host或自定義bridge不要用默認(rèn)bridge。默認(rèn)bridge的網(wǎng)絡(luò)隔離會(huì)讓容器間主機(jī)名解析變得很麻煩自定義網(wǎng)絡(luò)加上固定的容器名才能模擬出真實(shí)集群的主機(jī)解析關(guān)系。數(shù)據(jù)目錄務(wù)必用volume掛出來(lái)。否則容器一刪你辛苦搭的環(huán)境數(shù)據(jù)全沒了下次還得從頭再來(lái)。鏡像的Java版本要和Hadoop版本匹配。很多第三方鏡像用的OpenJDK 8對(duì)Hadoop 3.3.x也沒問題但如果你拉了一個(gè)很老的鏡像配了很新的Hadoop格式化階段就可能報(bào)出詭異的NativeIO錯(cuò)誤。容器化跑Hadoop唯一的限制是它模擬不了真實(shí)的資源競(jìng)爭(zhēng)和網(wǎng)絡(luò)故障場(chǎng)景。Docker容器之間雖然是隔離的但底層還是共享同一套內(nèi)核和物理資源。這意味著你用它學(xué)“功能”沒問題學(xué)“性能調(diào)優(yōu)”和“故障演練”則遠(yuǎn)遠(yuǎn)不夠。所以我的結(jié)論是容器化是學(xué)習(xí)環(huán)境的最優(yōu)解盡早上手生產(chǎn)環(huán)境則除非是短期測(cè)試環(huán)境否則別碰。順帶提一句Windows開發(fā)環(huán)境的搭建?，F(xiàn)在很多新手想在自己Windows機(jī)器上折騰Hadoop也就是熱搜里那個(gè)“windows下載hadoop”的需求我的建議是在Windows上直接裝Hadoop很痛苦不只是下載解壓的問題還有一堆原生庫(kù)依賴、路徑分隔符、權(quán)限模型的問題等著你。最省力的做法是裝個(gè)WSL2或直接上Docker Desktop在Linux內(nèi)核環(huán)境里跑Hadoop體驗(yàn)和真實(shí)集群幾乎一致。“hadoop開發(fā)環(huán)境搭建頭歌”這類實(shí)訓(xùn)平臺(tái)我也見過適合當(dāng)入門練習(xí)但如果你想深入理解原理還是要自己搭一套干凈的環(huán)境不要依賴平臺(tái)幫你隱藏細(xì)節(jié)。3. Hadoop與Zookeeper整合實(shí)戰(zhàn)HA集群的心臟3.1 為什么HA不能沒有Zookeeper先回答一個(gè)面試必問、也是實(shí)際運(yùn)維中必須理解透徹的問題為什么NameNode的高可用一定要靠ZookeeperNameNode是HDFS的核心它保存了整個(gè)文件系統(tǒng)的元數(shù)據(jù)。一旦它掛了整個(gè)HDFS都不可用。早期Hadoop的痛點(diǎn)是單點(diǎn)故障NameNode一掛集群就癱瘓只能靠人工恢復(fù)。那有人會(huì)問用Keepalived這類方案給NameNode掛一個(gè)虛擬IP主節(jié)點(diǎn)掛了把IP漂移到備節(jié)點(diǎn)不就行了嗎問題在于HDFS的高可用不只是“IP漂移”這么簡(jiǎn)單。NameNode的元數(shù)據(jù)分兩部分內(nèi)存中的鏡像fsimage和磁盤上的編輯日志edits。主備兩個(gè)NameNode要保證元數(shù)據(jù)完全一致必須持續(xù)同步編輯日志。如果主節(jié)點(diǎn)已經(jīng)寫了一條edits日志但還沒來(lái)得及同步給備節(jié)點(diǎn)就掛了備節(jié)點(diǎn)接管的元數(shù)據(jù)就不完整會(huì)造成數(shù)據(jù)丟失或元數(shù)據(jù)錯(cuò)亂。所以真正的HA方案要解決兩件事元數(shù)據(jù)的實(shí)時(shí)同步——主NameNode把edits日志實(shí)時(shí)寫入一個(gè)共享存儲(chǔ)備NameNode持續(xù)讀取并應(yīng)用這些日志保證內(nèi)存里的元數(shù)據(jù)基本一致。Hadoop采用的是JournalNode集群本質(zhì)上是把edits日志分散寫到多臺(tái)JournalNode上只要半數(shù)以上節(jié)點(diǎn)存活元數(shù)據(jù)就不丟。故障自動(dòng)切換——怎么讓集群里所有節(jié)點(diǎn)認(rèn)同“原來(lái)那個(gè)Active NameNode已經(jīng)死了現(xiàn)在應(yīng)該由Standby接替”這個(gè)決策必須由所有參與者一致認(rèn)可否則就可能出現(xiàn)兩個(gè)NameNode同時(shí)認(rèn)為自己是Active的情況這就是腦裂。這兩個(gè)問題Zookeeper都能解決或者說(shuō)只有Zookeeper這類強(qiáng)一致協(xié)調(diào)組件能優(yōu)雅地解決。ZK在HDFS HA里有三重角色選主仲裁兩個(gè)NameNode啟動(dòng)時(shí)向ZK注冊(cè)臨時(shí)節(jié)點(diǎn)誰(shuí)搶到鎖誰(shuí)就是ActiveZK保證只有一個(gè)贏家狀態(tài)存儲(chǔ)ZK保存當(dāng)前Active節(jié)點(diǎn)的標(biāo)識(shí)以及集群的命名空間信息分布式鎖與腦裂防護(hù)Active節(jié)點(diǎn)必須持續(xù)持有ZK上的一個(gè)分布式鎖一旦鎖丟了就得立即釋放所有資源并退位防止雙Active同時(shí)寫edits日志造成數(shù)據(jù)損壞。理解了這一層你就明白了為什么“hadoop和zookeeper整合實(shí)戰(zhàn)”不是單純的“裝兩個(gè)軟件然后配置上”而是一套完整的分布式一致性協(xié)作機(jī)制。3.2 HA整合配置的落地步驟實(shí)戰(zhàn)部分我用兩個(gè)NameNode、三臺(tái)JournalNode的典型HA拓?fù)鋪?lái)講。先規(guī)劃角色節(jié)點(diǎn)運(yùn)行組件node1NameNode, ZKFC, JournalNode, Zookeeper, DataNodenode2NameNode, ZKFC, JournalNode, Zookeeper, DataNodenode3JournalNode, Zookeeper, DataNode第一步確認(rèn)Zookeeper集群本身正常。每個(gè)Zookeeper節(jié)點(diǎn)上配置myid文件內(nèi)容分別是1、2、3然后在zoo.cfg里配置三個(gè)節(jié)點(diǎn)的地址和端口。啟動(dòng)后執(zhí)行zkServer.sh status看到其中一個(gè)顯示leader、其他兩個(gè)顯示follower說(shuō)明ZK集群健康。第二步配置core-site.xml。關(guān)鍵項(xiàng)是fs.defaultFS它必須指向一個(gè)邏輯名稱而不是某個(gè)具體節(jié)點(diǎn)configuration property namefs.defaultFS/name valuehdfs://mycluster/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configuration這里的mycluster是一個(gè)邏輯名稱兩臺(tái)NameNode的地址會(huì)在下一步的hdfs-site.xml里映射到這個(gè)名稱上。第三步配置hdfs-site.xml。這是整合的絕對(duì)重點(diǎn)configuration !-- 啟用HA -- property namedfs.nameservices/name valuemycluster/value /property !-- 兩個(gè)NameNode的邏輯ID -- property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property !-- 兩個(gè)NameNode的RPC地址 -- property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /property !-- 兩個(gè)NameNode的HTTP地址 -- property namedfs.namenode.http-address.mycluster.nn1/name valuenode1:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenode2:9870/value /property !-- JournalNode地址列表 -- property namedfs.namenode.shared.edits.dir/name valueqjournal://node1:8485;node2:8485;node3:8485/mycluster/value /property !-- 故障自動(dòng)切換實(shí)現(xiàn)類 -- property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property !-- ZKFC參數(shù) -- property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configuration這段配置的核心是qjournal地址。它是HA元數(shù)據(jù)同步的通道。所有edits日志都會(huì)同步寫入三臺(tái)JournalNode只要有兩臺(tái)成功落盤事務(wù)就算成功了。這就是為什么JournalNode必須奇數(shù)臺(tái)且至少三臺(tái)的原因——過半寫成功才能保證一致性和可用性。第四步啟動(dòng)順序與格式化。這里有個(gè)非常關(guān)鍵的細(xì)節(jié)很多人栽在這里。HA集群的格式化順序必須是先啟動(dòng)所有Zookeeper節(jié)點(diǎn)在其中一臺(tái)NameNode上執(zhí)行hdfs zkfc -formatZK在ZK中初始化HA狀態(tài)在一臺(tái)NameNode上執(zhí)行hdfs namenode -format生成初始元數(shù)據(jù)啟動(dòng)這臺(tái)NameNode讓它成為Active在另一臺(tái)NameNode上執(zhí)行hdfs namenode -bootstrapStandby從Active同步元數(shù)據(jù)啟動(dòng)所有JournalNode和DataNode最后啟動(dòng)Standby的ZKFC進(jìn)程。順序錯(cuò)了會(huì)怎樣如果ZK還沒就緒就去格式化NameNode格式化雖然可能成功但ZKFC注冊(cè)時(shí)會(huì)報(bào)錯(cuò)如果沒有先f(wàn)ormatZK就直接啟動(dòng)ZKFCZK里沒有對(duì)應(yīng)的HA狀態(tài)鎖自動(dòng)切換配置不會(huì)生效。這些都是我實(shí)際排障時(shí)見過的高頻問題。第五步驗(yàn)證failover是否真的生效。這一步極重要因?yàn)椤芭渲昧薍A”和“HA真的能切換”是兩回事。驗(yàn)證方法如下# 查看當(dāng)前Active節(jié)點(diǎn) hdfs haadmin -getAllServiceState # 手動(dòng)觸發(fā)一次故障轉(zhuǎn)移 hdfs haadmin -failover nn1 nn2 # 再次查看狀態(tài)應(yīng)該看到nn2變成active hdfs haadmin -getAllServiceState更狠的驗(yàn)證是直接kill掉Active NameNode進(jìn)程觀察ZKFC是否在幾秒內(nèi)自動(dòng)把Standby提升為Active。我在實(shí)際項(xiàng)目里都會(huì)做一次這個(gè)演練因?yàn)樗鼙┞逗芏嗯渲脤用娴碾[蔽問題。比如fencing機(jī)制沒生效時(shí)原來(lái)那個(gè)“假死”的NameNode可能會(huì)在網(wǎng)絡(luò)恢復(fù)后繼續(xù)請(qǐng)求寫edits日志導(dǎo)致數(shù)據(jù)不一致。生產(chǎn)環(huán)境里這種演練很危險(xiǎn)必須在維護(hù)窗口期做。3.3 整合中最容易翻車的細(xì)節(jié)第一個(gè)坑ZKFC進(jìn)程不是NameNode。我發(fā)現(xiàn)很多人SSH到節(jié)點(diǎn)上看HA狀態(tài)時(shí)只關(guān)注NameNode進(jìn)程是否存活忽略了ZKFC。但自動(dòng)切換的決策者是ZKFC不是NameNode本身。如果ZKFC掛了即使NameNode活著故障自動(dòng)切換也不會(huì)生效。所以監(jiān)控里一定要把ZKFC進(jìn)程納進(jìn)來(lái)。第二個(gè)坑quorum過半機(jī)制導(dǎo)致ZK集群自身可用性成為瓶頸。三臺(tái)ZK允許掛一臺(tái)兩臺(tái)掛掉整個(gè)ZK就不可用了。而ZK一旦不可用HDFS雖然還能繼續(xù)讀寫因?yàn)閑dits日志寫的是JournalNode不是ZK但故障自動(dòng)切換會(huì)完全失效。這是個(gè)很讓人迷惑的現(xiàn)象集群跑著跑著突然發(fā)現(xiàn)永遠(yuǎn)無(wú)法切換了查了一圈才發(fā)現(xiàn)是ZK集群只剩一臺(tái)活著的節(jié)點(diǎn)。第三個(gè)坑數(shù)據(jù)目錄權(quán)限問題。JournalNode的數(shù)據(jù)目錄dfs.journalnode.edits.dir和NameNode元數(shù)據(jù)目錄dfs.namenode.name.dir如果權(quán)限不是啟動(dòng)用戶格式化階段就會(huì)直接失敗。這在“數(shù)據(jù)目錄掛載了新磁盤”的場(chǎng)景特別常見——新磁盤掛載點(diǎn)是root用戶格式化時(shí)用hdfs用戶去寫直接Permission denied。4. 格式化、啟動(dòng)與元數(shù)據(jù)第一個(gè)大坑在這里4.1 namenode -format到底做了什么“Hadoop啟動(dòng)格式化失敗”能上熱搜說(shuō)明遇到這個(gè)坑的人不是少數(shù)。要理解格式化為什么會(huì)失敗得先知道它做了什么。hdfs namenode -format做的事情本質(zhì)上是對(duì)NameNode的元數(shù)據(jù)目錄做初始化創(chuàng)建目錄結(jié)構(gòu)在dfs.namenode.name.dir配置的路徑下創(chuàng)建current目錄、edits目錄等生成VERSION文件里面記錄了namespaceID、clusterID、blockPoolID等標(biāo)識(shí)生成初始的fsimage空集群的元數(shù)據(jù)快照。這些標(biāo)識(shí)太重要了。clusterID標(biāo)識(shí)的是整個(gè)HDFS集群namespaceID標(biāo)識(shí)的是命名空間blockPoolID標(biāo)識(shí)的是數(shù)據(jù)塊池。DataNode注冊(cè)到NameNode時(shí)會(huì)帶上自己理解的clusterID。如果DataNode磁盤上保存的clusterID跟NameNode當(dāng)前的不一致DataNode就會(huì)被拒絕注冊(cè)。“格式化失敗”的高頻原因總結(jié)起來(lái)就這幾類我給新手排障會(huì)照著這個(gè)表查失敗現(xiàn)象根因解決方式Permission denied元數(shù)據(jù)目錄屬主不對(duì)chown到啟動(dòng)用戶Directory is not empty之前格式化過殘留舊元數(shù)據(jù)確認(rèn)無(wú)價(jià)值后清空目錄或指定新目錄啟動(dòng)進(jìn)程秒退堆內(nèi)存參數(shù)不合理檢查HADOOP_HEAPSIZE / HADOOP_NAMENODE_OPTSjava.io.IOException: Cannot create directory父目錄不存在手動(dòng)創(chuàng)建目錄并賦權(quán)格式化和上電后DataNode找不到集群clusterID不一致要么備份后統(tǒng)一清空DataNode數(shù)據(jù)目錄要么手動(dòng)同步clusterID補(bǔ)充一個(gè)很容易忽略的細(xì)節(jié)格式化過程會(huì)輸出一行Storage directory ... has been successfully formatted但這只是針對(duì)這臺(tái)NameNode的存儲(chǔ)目錄格式化了。在HA場(chǎng)景下你只格式化了一臺(tái)NameNode的元數(shù)據(jù)存儲(chǔ)另一臺(tái)必須通過-bootstrapStandby來(lái)同步不能直接在第二臺(tái)上再執(zhí)行一次-format。如果你在第二臺(tái)NameNode上重新格式化了兩臺(tái)NameNode會(huì)生成不同的clusterID整個(gè)集群的DataNode都會(huì)因?yàn)閏lusterID對(duì)不上而拒絕注冊(cè)。這是我在生產(chǎn)環(huán)境見過最慘烈的一次事故大家務(wù)必引以為戒。4.2 啟動(dòng)失敗的三類場(chǎng)景與完整排查鏈路啟動(dòng)階段是故障高發(fā)區(qū)。下面這三類場(chǎng)景是我在幫人排查時(shí)遇到最多的。場(chǎng)景ADataNode起不來(lái)日志反復(fù)報(bào)“Incompatible clusterIDs”。DataNode啟動(dòng)時(shí)會(huì)比對(duì)本地存儲(chǔ)的clusterID和NameNode廣播的clusterID。為什么會(huì)不一致因?yàn)槟愀袷交^NameNode多次每次格式化都會(huì)生成新的clusterID而DataNode的數(shù)據(jù)目錄里還保留著上一次的clusterID。排查鏈路# 1. 看DataNode日志 tail -100 /opt/hadoop/logs/hadoop-hdfs-datanode-node.log # 日志里會(huì)出現(xiàn)類似 # Incompatible clusterIDs in /data/hdfs/datanode: # namenode clusterID CID-xxx # datanode clusterID CID-yyy # 2. 確認(rèn)兩個(gè)clusterID確實(shí)不一致 cat /opt/hadoop/logs/../dfs/name/current/VERSION cat /data/hdfs/datanode/current/VERSION # 3. 解決備份數(shù)據(jù)目錄后清空或者手動(dòng)改clusterID # 清空數(shù)據(jù)目錄注意確認(rèn)無(wú)未備份數(shù)據(jù) rm -rf /data/hdfs/datanode/current/*場(chǎng)景BNameNode進(jìn)程起來(lái)沒幾秒就退出日志無(wú)異常。這是最典型的資源問題。NameNode默認(rèn)堆內(nèi)存是1GB元數(shù)據(jù)一多就OOM。老手一般會(huì)在hadoop-env.sh里顯式設(shè)置HADOOP_NAMENODE_OPTS-Xmx8g。但這只是第一層你還要確認(rèn)NameNode所在的機(jī)器物理內(nèi)存夠不夠以及是否被其他進(jìn)程搶占了。我見過一個(gè)案例兩臺(tái)機(jī)器都裝了很多組件NameNode堆內(nèi)存給了8GB但機(jī)器總共只有16GB且JVM除了堆還要用堆外內(nèi)存和元空間實(shí)際占用超過物理內(nèi)存后系統(tǒng)開始瘋狂swapNameNode的響應(yīng)越來(lái)越慢最終被ZKFC判定為假死觸發(fā)切換。反過來(lái)另一臺(tái)機(jī)器也遇到同樣問題兩個(gè)NameNode開始反復(fù)互切整個(gè)HDFS的讀寫都斷了。場(chǎng)景C節(jié)點(diǎn)間通信失敗最隱蔽的是防火墻。Hadoop集群的節(jié)點(diǎn)間通信端口特別多NameNode RPC 8020、DataNode RPC 9866、ZK 2181/2888/3888、JournalNode 8485……有些企業(yè)安全基線會(huì)要求只開放特定端口于是你經(jīng)常遇到這樣一種情況進(jìn)程都活著服務(wù)看起來(lái)正常但就是連不上。排查鏈路很標(biāo)準(zhǔn)# 1. 先測(cè)基礎(chǔ)連通性 ping node1 telnet node1 8020 # 2. 如果通則看端口監(jiān)聽 netstat -anp | grep 8020 # 3. 如果監(jiān)聽正常但外部不通基本就是防火墻 systemctl status firewalld iptables -L -n # 或者云安全組的入站規(guī)則注意很多云廠商的安全組在控制臺(tái)上看起來(lái)放行了端口但節(jié)點(diǎn)內(nèi)部自身的iptables規(guī)則沒同步也會(huì)出現(xiàn)“控制臺(tái)顯示放行但實(shí)際不通”的詭異現(xiàn)象。檢查的時(shí)候兩邊都要看。4.3 元數(shù)據(jù)保護(hù)的經(jīng)驗(yàn)格式化、啟動(dòng)只是元數(shù)據(jù)話題的冰山一角。真正到了生產(chǎn)NameNode元數(shù)據(jù)就是你的命根子。HDFS元數(shù)據(jù)由兩部分組成fsimage是元數(shù)據(jù)的持久化快照edits是每次寫操作的增量日志。NameNode每次啟動(dòng)都會(huì)把fsimage加載進(jìn)內(nèi)存再重放edits里的增量事務(wù)。這里有個(gè)關(guān)鍵概念checkpoint。舊版Hadoop用SecondaryNameNode定期合并fsimage和edits把合并后的新fsimage傳回NameNode。但在HA架構(gòu)里這個(gè)角色已經(jīng)被Standby NameNode替代了。Standby節(jié)點(diǎn)持續(xù)從JournalNode讀取edits日志并應(yīng)用同時(shí)周期性執(zhí)行checkpoint生成新的fsimage。這個(gè)機(jī)制給運(yùn)維的啟示是不要對(duì)Standby NameNode做任何停機(jī)操作它正在承擔(dān)checkpoint職責(zé)。一停fsimage和edits的合并就會(huì)停滯edits會(huì)無(wú)限增長(zhǎng)最終可能把磁盤寫滿fsimage備份必須定期做。最簡(jiǎn)單的方式是把fsimage目錄掛到獨(dú)立的存儲(chǔ)或者用cron定期打包到一個(gè)安全位置數(shù)據(jù)盤和數(shù)據(jù)盤之間要物理隔離。NameNode的元數(shù)據(jù)目錄和DataNode的數(shù)據(jù)目錄放在同一塊磁盤上是災(zāi)難——DataNode磁盤寫滿會(huì)導(dǎo)致整個(gè)文件系統(tǒng)讀寫異常間接把NameNode拖掛。5. 生態(tài)整合完成之后日常運(yùn)維怎么排查問題5.1 先看日志再看監(jiān)控最后才碰配置這是我做運(yùn)維排查奉行的鐵律順序不能亂。很多人一遇到集群異常第一反應(yīng)就是懷疑配置錯(cuò)了開始翻配置文件、改參數(shù)。這個(gè)習(xí)慣很不好——配置在集群運(yùn)行期間被外部惡意改動(dòng)的情況極少更多時(shí)候配置沒變是某個(gè)運(yùn)行條件變了。正確的排查順序是先看日志定位現(xiàn)象再對(duì)照監(jiān)控找規(guī)律最后才去懷疑配置。Hadoop生態(tài)各組件的日志位置和重點(diǎn)我用一張表整理出來(lái)排查的時(shí)候照著看組件日志位置排查時(shí)重點(diǎn)看的日志NameNode$HADOOP_HOME/logs/hadoop-hdfs-namenode-*.log啟動(dòng)異常、元數(shù)據(jù)操作、checkpoint過程DataNode$HADOOP_HOME/logs/hadoop-hdfs-datanode-*.log塊上報(bào)、數(shù)據(jù)復(fù)制、磁盤異常ZKFC$HADOOP_HOME/logs/hadoop-hdfs-zkfc-*.log選主過程、鎖競(jìng)爭(zhēng)、腦裂防護(hù)動(dòng)作Zookeeper$ZK_HOME/logs/zookeeper-*.out會(huì)話超時(shí)、選舉日志YARN ResourceManager$HADOOP_HOME/logs/yarn--resourcemanager-.log調(diào)度日志、容器分配、隊(duì)列狀態(tài)YARN NodeManager$HADOOP_HOME/logs/yarn--nodemanager-.log容器啟動(dòng)失敗、本地磁盤管理拿一個(gè)我給朋友真實(shí)排查過的案例來(lái)講。某次集群突然變卡所有作業(yè)都在排隊(duì)。我第一反應(yīng)沒有去改YARN配置而是按順序查看ResourceManager日志發(fā)現(xiàn)隊(duì)列里全是ACCEPTED狀態(tài)的任務(wù)但CONTAINER一直創(chuàng)建不出來(lái)看NodeManager日志發(fā)現(xiàn)大量“Container killed on request”和“Local dir is full”字樣順藤摸瓜查磁盤使用率發(fā)現(xiàn)NodeManager的本地目錄所在分區(qū)使用率到了99%。根因根本不是配置問題是磁盤滿了。YARN在調(diào)度容器時(shí)發(fā)現(xiàn)本地目錄寫不進(jìn)去只能反復(fù)殺掉容器導(dǎo)致集群看起來(lái)是“卡死”實(shí)際上是“磁盤被寫滿后的自我保護(hù)”。清理掉日志和臨時(shí)文件后集群馬上恢復(fù)了。這個(gè)案例完美說(shuō)明了“日志定位現(xiàn)象”的價(jià)值。如果你一上來(lái)就懷疑隊(duì)列配置不對(duì)把隊(duì)列容量參數(shù)調(diào)來(lái)調(diào)去不僅解決不了問題還可能把原來(lái)正常的調(diào)度策略搞亂。5.2 資源層面的排查內(nèi)存、磁盤、網(wǎng)絡(luò)、連接數(shù)企業(yè)級(jí)運(yùn)維中資源和連接層面的問題占比最高我把高頻問題整理成速查表問題現(xiàn)象直接原因檢查方法作業(yè)提交后一直ACCEPTEDYARN隊(duì)列資源被大任務(wù)占滿ResourceManager Web UI里看隊(duì)列資源容器啟動(dòng)即失敗NodeManager本地目錄無(wú)空間df -h 查看NodeManager日志DataNode進(jìn)程消失文件句柄數(shù)超過系統(tǒng)限制ulimit -n / /etc/security/limits.conf大量連接進(jìn)入TIME_WAIT短連接過多端口耗盡ss -s 查看socket統(tǒng)計(jì)節(jié)點(diǎn)失聯(lián)NameNode報(bào)heartbeat timeout網(wǎng)絡(luò)抖動(dòng)或GC暫停過長(zhǎng)查看NameNode和DataNode日志時(shí)間線HDFS寫入超時(shí)數(shù)據(jù)目錄所在磁盤IO飽和iostat -x 1 觀察await值內(nèi)存這塊再展開一點(diǎn)。很多人只知道YARN有yarn.nodemanager.resource.memory-mb這個(gè)參數(shù)卻不知道它還分physical memory和virtual memory兩層限制。默認(rèn)情況下NM會(huì)檢查容器使用的虛擬內(nèi)存超過配置的yarn.nodemanager.vmem-pmem-ratio倍數(shù)后直接殺掉容器。這個(gè)比例默認(rèn)是2.1如果容器內(nèi)用了大量native內(nèi)存比如Python進(jìn)程、跑JNI的庫(kù)很容易觸發(fā)誤殺。日志里你會(huì)看到一行Container [pidxxx] is running beyond virtual memory limits遇到這種先別急著調(diào)大比例應(yīng)確認(rèn)容器是不是真的內(nèi)存泄漏確認(rèn)沒泄漏后再顯式調(diào)高yarn.nodemanager.vmem-pmem-ratio或關(guān)閉該檢查yarn.nodemanager.vmem-check-enabledfalse不推薦直接關(guān)。5.3 面試題背后的原理就是排查思路的底層邏輯熱搜詞里有個(gè)“hadoop面試題”我多說(shuō)兩句。大家準(zhǔn)備面試時(shí)背的那些題表面上是考概念實(shí)際上是在考你對(duì)系統(tǒng)運(yùn)行機(jī)制的理解。面試題和運(yùn)維排障是同一套底層的認(rèn)知模型。舉個(gè)例子。面試官問“NameNode掛了怎么辦”你會(huì)怎么答背出的答案是“HA自動(dòng)切換Standby接管”。但這背后至少要有幾層更深的認(rèn)知如何判斷NameNode“掛了”是進(jìn)程不存在還是ZKFC判定它心跳丟失如果是網(wǎng)絡(luò)分區(qū)導(dǎo)致的假活fencing機(jī)制怎么防止雙ActiveStandby接管后之前未提交的事務(wù)怎么辦答案在JournalNode的edits日志里客戶端怎么知道該連新的Active靠的是failover proxy provider里配置的邏輯名稱。這些問題每一個(gè)都對(duì)應(yīng)真實(shí)的故障排查場(chǎng)景。我在4.2節(jié)、5.1節(jié)講的案例本質(zhì)上就是在回答這類面試題。所以我不建議你死背面試題如果你能親手復(fù)現(xiàn)一次NameNode failover的全過程很多面試題不用背自然就會(huì)了。6. 從學(xué)習(xí)環(huán)境到企業(yè)環(huán)境的最后一公里6.1 開發(fā)環(huán)境搭建Windows與容器化實(shí)踐細(xì)節(jié)很多人在“windows下載hadoop”這一步栽過跟頭。Windows上裝Hadoop確實(shí)能跑但要改bin目錄下的winutils.exe要處理路徑分隔符、權(quán)限模擬等問題體驗(yàn)很折騰。我個(gè)人的經(jīng)驗(yàn)是Windows環(huán)境我只用來(lái)做三件事——看源碼、跑IDE代碼調(diào)試、連接遠(yuǎn)程集群測(cè)試客戶端代碼。真正的本地集群驗(yàn)證一律用Docker Desktop。在Docker里搭Hadoop時(shí)我常用這樣的參數(shù)組合docker network create --driver bridge hadoop-net # 啟動(dòng)一個(gè)NameNode節(jié)點(diǎn) docker run -d --name namenode \ --network hadoop-net \ -p 9870:9870 \ -v /data/hadoop/namenode:/hadoop/dfs/name \ -e CORE_CONF_fs_defaultFShdfs://namenode:8020 \ -e HDFS_CONF_dfs_namenode_http-addressnamenode:9870 \ -e HDFS_CONF_dfs_replication2 \ hadoop-docker-image # 啟動(dòng)兩個(gè)DataNode節(jié)點(diǎn) docker run -d --name datanode1 \ --network hadoop-net \ -v /data/hadoop/datanode1:/hadoop/dfs/data \ -e CORE_CONF_fs_defaultFShdfs://namenode:8020 \ hadoop-docker-image用環(huán)境變量方式傳配置是容器化部署Hadoop的一個(gè)實(shí)用技巧。Hadoop官方鏡像和社區(qū)鏡像大多會(huì)支持把xxx_yyy格式的環(huán)境變量自動(dòng)轉(zhuǎn)成配置文件里的屬性不用手動(dòng)進(jìn)容器改XML。這樣疊加Docker Compose一套三節(jié)點(diǎn)集群的啟動(dòng)腳本就非常清爽了。如果是“hadoop開發(fā)環(huán)境搭建頭歌”這類在線實(shí)驗(yàn)平臺(tái)我的建議是拿來(lái)練練手可以但別依賴。在線平臺(tái)幫你把環(huán)境都準(zhǔn)備好了你反而缺失了從裸機(jī)搭建、遇到問題再解決的過程。而這個(gè)過程才是進(jìn)階的關(guān)鍵。真正區(qū)分“會(huì)用”和“懂”的永遠(yuǎn)是你能不能從零到一搭出一套跑得起來(lái)的、你自己完全理解每一行配置的系統(tǒng)。6.2 用一次完整的故障演練檢驗(yàn)?zāi)闶欠裾娴倪M(jìn)階了最后分享一個(gè)我特別推薦的學(xué)習(xí)方法主動(dòng)制造一次故障然后嘗試自己修復(fù)。具體做法很簡(jiǎn)單。挑一個(gè)維護(hù)窗口在測(cè)試集群上按照下面這個(gè)清單一步一步來(lái)手動(dòng)kill掉Active NameNode進(jìn)程觀察集群行為看ZKFC能否在預(yù)期時(shí)間內(nèi)完成切換再kill掉一個(gè)DataNode進(jìn)程觀察HDFS的副本復(fù)制機(jī)制如何工作看剩余節(jié)點(diǎn)能否正常提供讀寫停掉全部ZK節(jié)點(diǎn)觀察HDFS的反應(yīng)——它不會(huì)立刻掛但你會(huì)發(fā)現(xiàn)failover功能失效了在YARN上提交一個(gè)超內(nèi)存作業(yè)觀察容器被殺的過程理解資源隔離的作用故意寫錯(cuò)一處配置比如把DataNode的目錄指向不存在路徑觀察啟動(dòng)失敗日志練習(xí)定位問題。這個(gè)演練的價(jià)值在于它逼著你在“沒有教程指引”的情況下面對(duì)真實(shí)故障逼著你親手翻開日志、比對(duì)狀態(tài)、修改配置。你會(huì)經(jīng)歷第一次恐慌然后學(xué)會(huì)冷靜最后建立一套屬于自己的排查直覺。我在帶人時(shí)發(fā)現(xiàn)一個(gè)規(guī)律愿意做這種演練的人面試時(shí)談吐和對(duì)系統(tǒng)的理解能力跟只刷教程的人完全不在一個(gè)量級(jí)。原因很簡(jiǎn)單——你對(duì)系統(tǒng)的信任感不會(huì)來(lái)自看了多少篇文檔而是來(lái)自你親手搞壞過它、再親手把它修好的次數(shù)。Hadoop這條路從入門到熟練中間沒有捷徑但也沒有想象中那么艱難。裝一套環(huán)境拆一個(gè)組件讀一段日志修一個(gè)故障每一步都算數(shù)。希望這篇沉淀下來(lái)的實(shí)戰(zhàn)經(jīng)驗(yàn)?zāi)茏屇闵俨葞讉€(gè)我已經(jīng)替你踩過的坑。