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