移)
凌晨兩點監(jiān)控大屏的告警把我從睡夢里拽起來HDFS的NameNode進程沒了。當時那套Hadoop集群沒有任何HA高可用機制只配了一個SecondaryNameNode——很多剛接觸Hadoop的人以為它是熱備其實它隔很久才做一次checkpoint根本不能自動接管。等我把元數(shù)據(jù)手動恢復(fù)回來凌晨批次的離線任務(wù)已經(jīng)垮了一大片。那次之后我不光把集群補成了正規(guī)的Hadoop HA高可用集群還把整套過程整理成了一篇可以照著做的搭建手冊。今天分享出來適合所有正在維護Hadoop集群、或者準備把測試集群推向生產(chǎn)的工程師。市面上講Hadoop HA的文檔很多但大多只貼配置不解釋原理要么就是直接甩一個安裝腳本。真到了自己動手搭的時候你會發(fā)現(xiàn)最花時間的不是敲命令而是理解為什么要這樣設(shè)計。這篇我會把組件分工、節(jié)點規(guī)劃、配置文件每個參數(shù)的含義、首次啟動的嚴格順序、故障切換演練和經(jīng)典事故全部串起來講盡量做到你看完不僅能搭起來還能自己排查問題。1. 為什么說SecondaryNameNode不是熱備HA組件分工與防腦裂思路1.1 NameNode單點故障到底有多痛先回顧一下HDFS的基本結(jié)構(gòu)NameNode負責管理整個文件系統(tǒng)的元數(shù)據(jù)所有目錄、文件名、塊信息、副本位置都在它腦子里。DataNode只負責存儲實際的數(shù)據(jù)塊每隔一段時間向NameNode匯報狀態(tài)。只要NameNode掛了客戶端就不知道文件在哪里、目錄結(jié)構(gòu)長什么樣整個集群對外就是不可用的狀態(tài)。很多人剛?cè)腴T時有個錯覺DataNode還在跑數(shù)據(jù)塊還在磁盤上NameNode掛了不應(yīng)該影響讀取啊實際情況是客戶端讀取文件時首先要問NameNode要文件的塊映射這個映射關(guān)系斷了DataNode手里有數(shù)據(jù)也不知道該把哪些塊交給誰。所以NameNode的可用性直接決定整個HDFS的可用性。我在第一批生產(chǎn)集群上吃的虧就是只配了SecondaryNameNode。它的工作其實是定期把NameNode內(nèi)存里的FsImage和磁盤上的EditLog合并生成一個新的檢查點順便幫助NameNode減小EditLog的體積。它做的這個動作在Hadoop 1.x時代很流行但它始終是一個輔助性角色既沒有NameNode的完整元數(shù)據(jù)也不能在NameNode故障時自動接管服務(wù)。等你手動把它恢復(fù)出來業(yè)務(wù)早就斷了。1.2 HA方案里真正的角色分工Hadoop HA高可用集群的底座思路很直白用兩個NameNode組成主備一個Active對外提供服務(wù)一個Standby在旁邊實時熱備。Active掛了Standby馬上頂上去。聽起來很簡單但有兩個核心問題必須解決第一兩個NameNode的元數(shù)據(jù)如何保持一致元數(shù)據(jù)由兩部分組成FsImage是某個時間點的完整快照EditLog是后續(xù)的增量修改記錄。HA方案的做法是引入一組JournalNodeActive NameNode每做一次修改操作先把EditLog寫入這一組JournalNodeStandby NameNode從這組JournalNode拉取EditLog并應(yīng)用到自己的內(nèi)存里讓自己的元數(shù)據(jù)始終追上Active。這樣無論哪臺機器宕機另一臺的元數(shù)據(jù)都不會落后太多。第二誰來決定什么時候切換、切換給誰這里引入了ZooKeeper和ZKFCZooKeeper Failover Controller。每個NameNode旁邊都有一個ZKFC守護進程它的工作有兩塊一是定時探測本機NameNode的存活狀態(tài)和健康狀態(tài)二是和ZooKeeper中的一個臨時節(jié)點競爭鎖。Active的ZKFC成功持有鎖Standby的ZKFC在等待。一旦Active側(cè)的ZKFC探測到NameNode掛了它會主動釋放鎖Standby側(cè)的ZKFC發(fā)現(xiàn)鎖被釋放就競爭上鎖并把自己這邊的NameNode提升為Active。1.3 腦裂問題與fencing機制雙主設(shè)計最怕的不是一臺掛了而是兩臺都認為自己是Active同時對外提供服務(wù)。一旦出現(xiàn)這種局面兩個NameNode會同時往JournalNode寫EditLog元數(shù)據(jù)就徹底分叉了整個集群的元數(shù)據(jù)變成一鍋粥。這就是腦裂split-brain。為了防止腦裂HA方案強制要求在切換之前一定要把舊的Active NameNode隔離掉。這個隔離動作叫fencing柵欄。在Hadoop里最常用的是sshfence新的Active發(fā)出切換請求時通過SSH登錄到舊Active所在節(jié)點直接執(zhí)行命令把舊NameNode的進程殺掉。這個機制聽起來粗暴但在分布式系統(tǒng)里粗暴往往是最可靠的。這里有個被我反復(fù)強調(diào)的細節(jié)fencing動作依賴SSH免密而且必須是從新Active所在節(jié)點能免密登錄到舊Active所在節(jié)點。很多人搭建時配了單向免密結(jié)果切換的時候fencing執(zhí)行失敗整個自動切換流程卡住最后只能人肉介入。后面踩坑部分我會細講。1.4 用記賬本的類比理解JournalNode為了讓不熟悉分布式原理的朋友更容易理解我習慣把整個HA機制比作兩個會計共用一個賬本。Active會計負責記賬每次發(fā)生一筆新業(yè)務(wù)他不會只寫在自己的小本子上而是把記錄同步抄送到三個獨立的賬單房間JournalNode只有超過半數(shù)房間確認收到了這筆賬才算記成功。Standby會計不從Active那里直接拿數(shù)據(jù)而是自己去這三個房間把記錄取回來更新手里那本復(fù)制的賬本。這里為什么要超過半數(shù)確認因為就算其中一個房間著火了剩下兩個房間仍然能湊出多數(shù)保證賬目完整。如果只有兩個房間其中一個掛了剩下一個即使完好也無法滿足超過半數(shù)的條件整個賬本就沒人敢認定是完整的。這就是JournalNode必須配置奇數(shù)個、且最少三個的根本原因。一下把核心原理講透后面配置參數(shù)時你自然就明白為什么要填三個地址了。2. 三節(jié)點還是五節(jié)點主機規(guī)劃、版本選擇和易被忽略的預(yù)環(huán)境2.1 生產(chǎn)環(huán)境推薦的最小拓撲搭建HA集群之前第一件事是確定機器數(shù)量。我的建議是真正用于生產(chǎn)環(huán)境的Hadoop HA集群至少準備三臺機器。這三臺機器上要混部JournalNode、ZooKeeper、NameNode、ZKFC和DataNode角色分配大概是這樣的節(jié)點NameNodeZKFCJournalNodeZooKeeperDataNodenode1nn1初始Active有有有有node2nn2初始Standby有有有有node3無無有有有三臺機器里NameNode一定放在前兩臺兩臺的配置要盡量一樣內(nèi)存和CPU都不能差太多否則切換后性能差異會直接影響業(yè)務(wù)。JournalNode和ZooKeeper要落在三臺上湊出奇數(shù)個。如果你的機器更富余可以拆成五臺甚至更多NameNode和ZKFC仍然必須在同一臺JournalNode至少三臺ZooKeeper也至少三臺。為什么ZKFC必須和NameNode同機部署因為ZKFC要探測NameNode的進程狀態(tài)如果分開部署它只能通過RPC端口探測一旦網(wǎng)絡(luò)分區(qū)ZKFC可能誤判NameNode已死導(dǎo)致無謂的切換。放在同一臺機器上可以直接檢查本機進程判斷準確得多。2.2 版本與JDK的兼容性選擇版本選型是很多新手忽略的坑。我建議不要用太老的Hadoop 2.x除非你維護的是歷史存量集群。新搭建的集群直接用Hadoop 3.x系列比如3.2.4、3.3.6這些穩(wěn)定版本配套的ZooKeeper選3.6以上的版本。JDK方面Hadoop 3.x官方支持JDK 8和JDK 11。我自己在多個環(huán)境里測試下來JDK 8的兼容性最穩(wěn)如果你公司有強制安全要求必須用更高版本也要先做一輪功能性驗證再上生產(chǎn)。另外ZooKeeper本身也是跑在JVM上的所有節(jié)點的JDK版本保持一致不要一臺是8另一臺是11否則跨節(jié)點通信時可能出現(xiàn)序列化相關(guān)的問題。版本選擇的另一個隱藏要求是所有節(jié)點的Hadoop發(fā)行版版本必須一模一樣。有的團隊圖省事node1和node2用同一個版本node3卻用了稍老一點的版本JournalNode之間的通信協(xié)議有差異輕則日志刷WARN重則EditLog同步異常。2.3 用戶、目錄、SSH免密、時鐘同步正式搭之前有幾個環(huán)境項必須提前處理好任何一個出問題都會在啟動階段變成莫名其妙的報錯。第一統(tǒng)一使用普通用戶不要用root跑Hadoop。我習慣創(chuàng)建hadoop用戶然后用這個用戶解壓安裝包、創(chuàng)建數(shù)據(jù)目錄。原因是Hadoop的很多腳本對目錄權(quán)限有隱式要求用root運行容易在啟動時產(chǎn)生Permission denied或者目錄所有者的奇怪問題不好排查。第二規(guī)劃好數(shù)據(jù)目錄。NameNode元數(shù)據(jù)目錄和JournalNode數(shù)據(jù)目錄不要放在系統(tǒng)根分區(qū)更不要放在/tmp下面。我見過不止一次有人把hadoop.tmp.dir默認配置放到/tmp服務(wù)器重啟后/tmp被清理NameNode的FsImage和EditLog全沒了集群直接報廢。建議統(tǒng)一用/data/hadoop/tmp和/data/hadoop/jn這樣的獨立目錄并且預(yù)留足夠磁盤空間。第三SSH免密。搭建時我建議把三臺節(jié)點之間全部配成雙向免密不要只配NameNode到DataNode的單向。因為不僅啟動腳本要用SSH拉起遠端進程ZKFC的sshfence還要從新Active登錄到舊Active去殺進程。另外如果你的環(huán)境中有人改了SSH端口或者禁用了密碼登錄一定要提前確認免密鏈路全部通暢。第四時鐘同步。ZooKeeper的會話機制對時間偏差很敏感節(jié)點之間的系統(tǒng)時間如果差太多ZK會誤判會話超時進而觸發(fā)毫無意義的NameNode切換。生產(chǎn)環(huán)境用chronyd或者ntpd統(tǒng)一對時搭建前先用date命令人工確認三臺機器的時間基本一致。2.4 部署目錄結(jié)構(gòu)示例我習慣把軟件和數(shù)據(jù)目錄分開每個節(jié)點統(tǒng)一按下面這個結(jié)構(gòu)準備/opt/hadoopHadoop安裝目錄/opt/zookeeperZooKeeper安裝目錄/data/hadoop/tmpNameNode元數(shù)據(jù)目錄包含F(xiàn)sImage和EditLog/data/hadoop/jnJournalNode數(shù)據(jù)目錄/data/hadoop/logs各進程日志目錄日志一定要單獨放方便排查目錄準備好之后記得把/data目錄的屬主改成hadoop用戶并確認磁盤空間足夠。JournalNode的EditLog會持續(xù)增長建議單獨給/data/hadoop/jn掛一塊獨立磁盤避免和其他日志、臨時文件搶空間。3. 配置文件逐項拆解每個參數(shù)背后的防呆邏輯3.1 core-site.xml默認文件系統(tǒng)與ZK地址核心配置都在core-site.xml和hdfs-site.xml兩個文件里所有節(jié)點都要保持一致的配置。先看core-site.xml里必配的三個參數(shù)configuration property namefs.defaultFS/name valuehdfs://mycluster/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configurationfs.defaultFS這里填的不是某個單點主機名而是一個邏輯名稱mycluster這個名稱必須和下文中hdfs-site.xml里配置的nameservice完全一致。它決定了所有客戶端進程知道這套集群對外叫mycluster具體該連哪臺NameNode由后面的failover provider來決定。ha.zookeeper.quorum里填的是三臺ZooKeeper的地址逗號分隔一行寫完。這個參數(shù)會被ZKFC用來連接ZooKeeper集群也會被客戶端在解析集群狀態(tài)時使用。端口默認是2181如果你改了ZooKeeper端口這里必須同步改。hadoop.tmp.dir之所以要單獨強調(diào)是因為很多衍生目錄默認都在它下面。比如NameNode的元數(shù)據(jù)目錄默認是${hadoop.tmp.dir}/dfs/name如果你不把它指到獨立磁盤后面擴容和排障都會被系統(tǒng)盤空間卡脖子。3.2 hdfs-site.xmlnameservice、雙NN與JournalNodehdfs-site.xml是HA配置的核心參數(shù)最多也最容易填錯。我把關(guān)鍵的幾個拆開講property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /propertydfs.nameservices定義一個邏輯集群的名字dfs.ha.namenodes.mycluster定義了這個邏輯集群里有哪些NameNode這里用nn1和nn2作為兩個邏輯ID。注意nn1、nn2并不是機器名只是邏輯代號后面所有配置里都要用這兩個ID來區(qū)分兩臺NameNode。property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /property property namedfs.namenode.http-address.mycluster.nn1/name valuenode1:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenode2:9870/value /property這段是給兩個NameNode綁定實際的RPC地址和HTTP管理界面地址。RPC端口是客戶端訪問用的我習慣統(tǒng)一用8020HTTP端口是Web管理頁面Hadoop 3.x默認是9870。這些地址寫錯或者端口被占用啟動時NameNode會直接報BindException排查時優(yōu)先看端口和hosts解析。接下來是JournalNode的共享存儲配置這是HA的數(shù)據(jù)同步命脈property namedfs.namenode.shared.edits.dir/name valueqjournal://node1:8485;node2:8485;node3:8485/mycluster/value /property property namedfs.journalnode.edits.dir/name value/data/hadoop/jn/value /propertydfs.namenode.shared.edits.dir告訴兩個NameNode你們的EditLog要寫到這臺機器上的JournalNode多個地址用分號分隔路徑最后是/mycluster。這個/mycluster可以理解成JournalNode上命名空間的一個標識和前面的nameservice是兩回事很多人會混淆。dfs.journalnode.edits.dir是每臺機器上JournalNode進程本地存儲EditLog的目錄寫在hdfs-site.xml里各節(jié)點保持一致即可。3.3 自動故障轉(zhuǎn)移和隔離方法參數(shù)下面幾個參數(shù)直接決定能不能自動切換和切換時怎么防腦裂property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.connect-timeout/name value30000/value /property property namedfs.ha.fencing.ssh.private-key-files/name value/home/hadoop/.ssh/id_rsa/value /propertyautomatic-failover.enabled不設(shè)成true你搭起來的HA就只是個半成品NameNode掛了只能靠haadmin命令手動切換不會自動頂上去。很多教程沒強調(diào)這一點導(dǎo)致讀者搭完后發(fā)現(xiàn)完全不自動。ConfiguredFailoverProxyProvider是客戶端側(cè)的故障轉(zhuǎn)移代理。它的作用是讓客戶端在訪問NameNode失敗時自動嘗試另一臺NameNode而不是報錯。這個類名必須完整填寫不小心中間漏個字母就會在客戶端初始化時拋出ClassNotFoundException。sshfence是隔離方法結(jié)合前面的fencing原理這部分要重點檢查。connect-timeout是SSH連接超時時間單位毫秒我建議設(shè)成30000。太短在機器負載高時會誤判fencing失敗太長又會讓整個切換過程拖到一分鐘以上。private-key-files指定sshfence要用哪個私鑰認證必須配置成hadoop用戶的私鑰路徑并且對應(yīng)公鑰要已經(jīng)寫入所有目標節(jié)點的authorized_keys。3.4 完整配置樣例與參數(shù)速查表兩套配置我貼一份能直接用的完整版本你可以按自己的主機名和目錄調(diào)整core-site.xmlconfiguration property namefs.defaultFS/name valuehdfs://mycluster/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configurationhdfs-site.xmlconfiguration property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /property property namedfs.namenode.http-address.mycluster.nn1/name valuenode1:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenode2:9870/value /property property namedfs.namenode.shared.edits.dir/name valueqjournal://node1:8485;node2:8485;node3:8485/mycluster/value /property property namedfs.journalnode.edits.dir/name value/data/hadoop/jn/value /property property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.connect-timeout/name value30000/value /property property namedfs.ha.fencing.ssh.private-key-files/name value/home/hadoop/.ssh/id_rsa/value /property property namedfs.replication/name value2/value /property /configuration最后列一個參數(shù)速查表方便你配置后逐項核對參數(shù)含義常見錯誤fs.defaultFS客戶端默認訪問的HDFS集群地址寫成單機hdfs://node1:8020dfs.nameservicesHDFS邏輯集群名與fs.defaultFS不一致dfs.ha.namenodes.mycluster邏輯集群內(nèi)的NN列表把機器名當NN IDdfs.namenode.shared.edits.dirJournalNode共享編輯日志地址漏掉QJM協(xié)議前綴qjournaldfs.ha.automatic-failover.enabled是否開啟自動故障轉(zhuǎn)移只配了HA但沒開啟自動dfs.ha.fencing.methods隔離舊Active的方式?jīng)]配sshfence導(dǎo)致腦裂風險4. 首次啟動的嚴格順序從格式化到bootstrapStandby的完整命令鏈4.1 為什么JournalNode必須先于NameNode啟動我見過的很多第一次搭建失敗案例問題都出在啟動順序上。NameNode進程啟動時會去連接配置里指定的JournalNode讀取EditLog如果JournalNode還沒起來NameNode會一直重試連接直到超時報錯。所以首要原則是先啟動ZooKeeper再啟動所有JournalNode最后才啟動NameNode相關(guān)進程。JournalNode的啟動命令在Hadoop 3.x里是hdfs --daemon start journalnode三臺機器都要執(zhí)行。啟動后用jps可以確認看到JournalNode進程。這時候如果配置里的目錄權(quán)限不對JournalNode會立刻報錯退出所以啟動后最好看一眼日志或者用jps確認進程還活著。4.2 格式化只能做一次再談bootstrapStandby第一次搭建時必須對其中一個NameNode執(zhí)行元數(shù)據(jù)格式化生成初始的FsImage和ClusterIDhdfs namenode -format這里我要把話說得非常重只格式化nn1不要在nn2上再執(zhí)行同樣的format。如果兩臺NameNode分別格式化它們會生成不同的ClusterIDStandby節(jié)點啟動后根本無法與Active節(jié)點共享同一份元數(shù)據(jù)后面怎么同步都追不上。正確的做法是在nn2上執(zhí)行hdfs namenode -bootstrapStandbybootstrapStandby會自動從nn1Active所在節(jié)點的本地元數(shù)據(jù)目錄把FsImage和相關(guān)的VERSION等文件拷貝過來并構(gòu)建出Standby節(jié)點的初始元數(shù)據(jù)。它是HA集群搭建時的標準動作比手動scp再改配置穩(wěn)妥得多。4.3 格式化ZKFC狀態(tài)zkfc -formatZK還有一個只做一次的動作就是初始化ZooKeeper中的HA狀態(tài)hdfs zkfc -formatZK這個命令在任意一個NameNode節(jié)點上執(zhí)行一次即可。它的作用是在ZooKeeper里創(chuàng)建/hadoop-ha/mycluster節(jié)點ZKFC后續(xù)就是在這個節(jié)點上搶鎖。如果跳過這一步后面啟動ZKFC時它會報錯找不到父節(jié)點自動切換根本沒法工作。4.4 無一遺漏的首次啟動命令鏈我把完整命令鏈按順序列出來你在三臺機器上依次操作即可在三臺節(jié)點上分別啟動ZooKeeperzkServer.sh start在三臺節(jié)點上分別啟動JournalNodehdfs --daemon start journalnode在nn1所在節(jié)點執(zhí)行格式化hdfs namenode -format在nn2所在節(jié)點執(zhí)行bootstrapStandbyhdfs namenode -bootstrapStandby在nn1所在節(jié)點執(zhí)行ZKFC狀態(tài)初始化hdfs zkfc -formatZK分別在nn1、nn2上啟動NameNodehdfs --daemon start namenode分別在nn1、nn2上啟動ZKFChdfs --daemon start zkfc在任意一臺DataNode節(jié)點上啟動DataNodehdfs --daemon start datanode如果你配置了完整的slaves/workers文件列表也可以用start-dfs.sh統(tǒng)一啟動DataNode。但首次搭建我不推薦用腳本一把梭原因是你需要觀察每一步的日志輸出確認沒有隱藏錯誤。啟動完成后在第一臺NameNode節(jié)點上執(zhí)行hdfs haadmin -getAllServiceState正常情況下輸出應(yīng)該是nn1顯示activenn2顯示standby。如果看到的都是standby說明ZKFC搶鎖沒生效優(yōu)先檢查zkfc -formatZK是否執(zhí)行過、ZooKeeper地址是否可連通。4.5 日常重啟與首次搭建的命令區(qū)別集群搭好之后日常維護的啟動流程和首次搭建完全不同不用再格式化也不用再bootstrapStandby。正常流程是stop-dfs.sh # 然后在三臺機器上啟停ZooKeeper zkServer.sh start # 最后 start-dfs.shstart-dfs.sh在檢測到HA配置后會自動按順序拉起JournalNode、NameNode、ZKFC和DataNode你只需要確保ZooKeeper已經(jīng)提前啟動即可。日常重啟時如果某臺節(jié)點因為之前的異常退出還殘留PID文件腳本可能提示already running as process xxx這時候去/tmp/hadoop-xxx目錄下把對應(yīng).pid文件清掉再重啟。5. 故障切換實戰(zhàn)演練主動kill掉Active NameNode后集群發(fā)生了什么5.1 切換前準備測試文件與集群狀態(tài)基線集群搭建完成不代表萬事大吉我強烈建議每次交付前都做一輪故障切換演練。先把集群狀態(tài)確認一遍hdfs haadmin -getAllServiceState hdfs dfsadmin -report再往HDFS里放一個測試文件hdfs dfs -mkdir -p /test/ha echo hello hadoop ha | hdfs dfs -put - /test/ha/hello.txt hdfs dfs -cat /test/ha/hello.txt確保次文件能正常寫入和讀取這樣演練時心里有底。5.2 硬故障演練kill -9之后觀察切換硬故障演練的目標是模擬NameNode進程意外崩潰。先確定當前Active是nn1然后登錄nn1所在節(jié)點執(zhí)行jps # 找到NameNode的進程PID然后 kill -9 PIDkill -9之后的幾秒內(nèi)ZKFC會檢測到NameNode心跳消失主動釋放ZooKeeper鎖并觸發(fā)fencing流程。站在nn2節(jié)點上觀察日志tail -f /data/hadoop/logs/hadoop-hadoop-namenode-node2.log你會看到類似下面這樣的關(guān)鍵內(nèi)容檢測到Active NameNode失聯(lián)開始競選鎖執(zhí)行sshfence成功成為Active。整個過程快的話5到10秒就完成。切換完成后重新驗證服務(wù)hdfs haadmin -getAllServiceState hdfs dfs -cat /test/ha/hello.txt命令能正常返回說明客戶端請求已經(jīng)自動走了新的Active節(jié)點集群對外幾乎沒有中斷。這里要補充一點讀取操作完全無感但正在執(zhí)行的寫作業(yè)可能因為連接中斷而報錯需要客戶端重試。這是分布式系統(tǒng)的正常行為不是HA沒生效。5.3 優(yōu)雅切換演練手動置standby再置active除了硬故障日常運維中更多是主動運維切換比如要升級NameNode節(jié)點的內(nèi)核、換硬件。這時建議走優(yōu)雅切換流程讓故障轉(zhuǎn)移時間更短、對業(yè)務(wù)影響更小。先執(zhí)行hdfs haadmin -transitionToStandby nn1把nn1從Active降為Standby此時nn2會自動升為Active。如果自動故障轉(zhuǎn)移已經(jīng)開啟你甚至可以直接在nn2上執(zhí)行hdfs haadmin -transitionToActive nn2這里有個小原則要牢記手動切換時永遠先把當前Active降為Standby再把另一臺升為Active。如果反過來兩邊同時處于Active狀態(tài)即便有fencing機制也會觸發(fā)不必要的殺進程動作給自己找麻煩。5.4 切換耗時分析和腦裂防護效果驗證切換耗時主要受兩個因素影響一個是ZooKeeper的會話超時時間另一個是ZKFC對NameNode健康檢查的間隔。ZooKeeper默認sessionTimeout是30秒左右但ZKFC內(nèi)部還有更細粒度的健康探測所以實際切換很少真的等到30秒。在我自己的測試環(huán)境里硬故障切換在5到8秒之間優(yōu)雅切換在3秒左右。腦裂防護的驗證方式是在Simulate網(wǎng)絡(luò)分區(qū)時觀察是否只有一臺NN在寫EditLog。具體做法是人為把Active節(jié)點的ZKFC停掉但不殺NameNode這時候新Active可能會嘗試sshfence去殺舊Active的進程。如果配置正確舊NameNode進程會被殺掉系統(tǒng)里始終只有一個真正的Active。這個演練比較激進建議在測試環(huán)境先驗證明白了再在生產(chǎn)上操作。6. 搭建過程中的經(jīng)典事故排查思路與修復(fù)記錄6.1 事故一重復(fù)format導(dǎo)致clusterID分叉有一次我接手別人搭了一半的集群發(fā)現(xiàn)Node2的NameNode狀態(tài)一直顯示standby但它的日志里不斷出現(xiàn)同步EditLog失敗。我第一反應(yīng)是JournalNode之間的網(wǎng)絡(luò)問題抓了一圈包沒發(fā)現(xiàn)問題。后來直接把兩臺NameNode元數(shù)據(jù)目錄里的VERSION文件拉出來對比發(fā)現(xiàn)clusterID完全不一樣。根因很清晰當初搭建的人分別在兩臺NameNode上執(zhí)行了格式化導(dǎo)致兩個節(jié)點的元數(shù)據(jù)各自為政。修復(fù)方法也談不上優(yōu)雅只能把整個元數(shù)據(jù)存續(xù)狀態(tài)清掉重新來關(guān)閉所有進程刪掉/data/hadoop/tmp/dfs/name目錄內(nèi)容、/data/hadoop/jn目錄內(nèi)容、以及ZooKeeper里/hadoop-ha節(jié)點然后再嚴格按首次搭建的命令鏈走一遍。這個教訓告訴我們格式化這個動作在HA集群里是有排他性的做一次就夠了。6.2 事故二sshfence超時自動切換卡住第二次踩坑是在一次演練中我故意kill掉Active NameNode后等了半分鐘Standby還沒提升。查看日志發(fā)現(xiàn)fencing環(huán)節(jié)一直卡住報錯信息大致是ssh connection timed out。逐項排查后問題出在兩臺節(jié)點之間的SSH免密只配了一個方向從nn2到nn1可以免密但從nn1到nn2配漏了。切換發(fā)生時nn2作為新Active要登錄nn1去殺進程這條鏈路恰好沒打通。這個坑的隱蔽性在于平時啟動完全正常因為start-dfs.sh做的是遠端拉起那是另一條SSH鏈路而sshfence走的是完全相反的登錄方向。修復(fù)方法很簡單把雙向SSH免密徹底配好再確認dfs.ha.fencing.ssh.private-key-files指向的私鑰就是hadoop用戶持有的那一個。配好之后重新演練切換就順了。6.3 事故三時鐘漂移引發(fā)ZKFC反復(fù)抖動有一個環(huán)境在運行兩周后監(jiān)控突然報警NameNode狀態(tài)在active和standby之間來回切換業(yè)務(wù)側(cè)雖然沒中斷但每次切換都會產(chǎn)生大量告警和連接重試。翻ZKFC日志發(fā)現(xiàn)它不斷在連接ZooKeeper和會話過期之間循環(huán)。進一步檢查各節(jié)點系統(tǒng)時間發(fā)現(xiàn)其中一臺機器的時鐘比另外兩臺快了將近三分鐘。ZooKeeper的會話機制對超時非常敏感時鐘偏差一大服務(wù)端就認為客戶端會話已經(jīng)過期鎖被釋放另一邊又開始搶鎖兩邊就進入抖動狀態(tài)。修復(fù)手段不是只有調(diào)整時間而是裝上chronyd并配置好統(tǒng)一對時源讓所有節(jié)點的時間偏差保持在100毫秒以內(nèi)。從那以后我對所有集群節(jié)點都強制加了時間同步檢查搭建清單里也固定有這個步驟。6.4 事故四tmp目錄被系統(tǒng)清理導(dǎo)致元數(shù)據(jù)全丟早年間我見過一個更慘的案例。某套測試集群一直跑得好好的直到有一次服務(wù)器重啟整個HDFS的NameNode起不來了。排查時發(fā)現(xiàn)元數(shù)據(jù)目錄是空的原因是配置文件里的hadoop.tmp.dir指向了系統(tǒng)默認的/tmp目錄而很多操作系統(tǒng)的tmpfiles機制會在重啟后清理/tmp下的內(nèi)容。這個案例直接改變了我的目錄規(guī)劃原則Hadoop相關(guān)的所有持久化目錄必須放在獨立的數(shù)據(jù)盤上并且盡早在部署清單中免疫這種問題。FsImage是HDFS元數(shù)據(jù)安全的最后底線靠系統(tǒng)臨時目錄來保存是不可接受的。6.5 事故五JN單點部署HA形同虛設(shè)有一種情況最具有迷惑性節(jié)點上把雙NameNode配好了自動轉(zhuǎn)移也能工作但JournalNode也只有一個而且就跑在某個NameNode同一臺機器上。結(jié)果這臺機器整機宕機時元數(shù)據(jù)無法寫入JournalNode新Active也無法讀取到完整EditLog整個HA機制形同虛設(shè)。JournalNode的作用是共享EditLog它自身必須是多副本并且滿足多數(shù)派可用。生產(chǎn)環(huán)境JN最少三臺有條件的分散到不同機架或不同交換機下。每次審查集群架構(gòu)時我都會把JN的分布單獨拉出來看一遍寧可多花機器成本也不能讓HA變成假高可用。7. 日常維護與監(jiān)控建議搭建手冊寫完最后再補充幾條日常維護經(jīng)驗。第一監(jiān)控上一定要盯四類指標NameNode狀態(tài)是否有一臺active、ZKFC進程是否存活、JournalNode目錄磁盤使用率、ZooKeeper會話數(shù)是否穩(wěn)定。這四個指標能覆蓋大多數(shù)HA故障場景。第二建議每季度做一次主動切換演練不要等到事故來了才驗證HA鏈路。演練前選好業(yè)務(wù)低峰期把切換流程寫成checklist讓所有運維成員都實際操作一遍避免關(guān)鍵時刻只有個別人會處理。第三即使有了HAFsImage的異地備份也不能停。HA解決的是單點故障下的可用性問題它不能防范磁盤物理損壞或者元數(shù)據(jù)目錄被誤刪。定期把Active NameNode的FsImage文件同步到獨立存儲是cost很低但回報極高的事。最后再分享我的一個習慣每次搭建完集群我都會用hdfs haadmin -getAllServiceState確認狀態(tài)然后立刻做一次kill -9演練。這個過程雖然會短暫地制造一次故障但它能暴露幾乎所有配置層面的問題比我后來遇到事故再去救火要劃算得多。把HA集群當成一個需要反復(fù)驗證的系統(tǒng)而不是搭完就撒手的靜態(tài)配置這才是高可用真正落地的開始。 Hadoop HA高可用集群搭建全指南：從NameNode單點故障到自動故障轉(zhuǎn)移
凌晨兩點監(jiān)控大屏的告警把我從睡夢里拽起來HDFS的NameNode進程沒了。當時那套Hadoop集群沒有任何HA高可用機制只配了一個SecondaryNameNode——很多剛接觸Hadoop的人以為它是熱備其實它隔很久才做一次checkpoint根本不能自動接管。等我把元數(shù)據(jù)手動恢復(fù)回來凌晨批次的離線任務(wù)已經(jīng)垮了一大片。那次之后我不光把集群補成了正規(guī)的Hadoop HA高可用集群還把整套過程整理成了一篇可以照著做的搭建手冊。今天分享出來適合所有正在維護Hadoop集群、或者準備把測試集群推向生產(chǎn)的工程師。市面上講Hadoop HA的文檔很多但大多只貼配置不解釋原理要么就是直接甩一個安裝腳本。真到了自己動手搭的時候你會發(fā)現(xiàn)最花時間的不是敲命令而是理解為什么要這樣設(shè)計。這篇我會把組件分工、節(jié)點規(guī)劃、配置文件每個參數(shù)的含義、首次啟動的嚴格順序、故障切換演練和經(jīng)典事故全部串起來講盡量做到你看完不僅能搭起來還能自己排查問題。1. 為什么說SecondaryNameNode不是熱備HA組件分工與防腦裂思路1.1 NameNode單點故障到底有多痛先回顧一下HDFS的基本結(jié)構(gòu)NameNode負責管理整個文件系統(tǒng)的元數(shù)據(jù)所有目錄、文件名、塊信息、副本位置都在它腦子里。DataNode只負責存儲實際的數(shù)據(jù)塊每隔一段時間向NameNode匯報狀態(tài)。只要NameNode掛了客戶端就不知道文件在哪里、目錄結(jié)構(gòu)長什么樣整個集群對外就是不可用的狀態(tài)。很多人剛?cè)腴T時有個錯覺DataNode還在跑數(shù)據(jù)塊還在磁盤上NameNode掛了不應(yīng)該影響讀取啊實際情況是客戶端讀取文件時首先要問NameNode要文件的塊映射這個映射關(guān)系斷了DataNode手里有數(shù)據(jù)也不知道該把哪些塊交給誰。所以NameNode的可用性直接決定整個HDFS的可用性。我在第一批生產(chǎn)集群上吃的虧就是只配了SecondaryNameNode。它的工作其實是定期把NameNode內(nèi)存里的FsImage和磁盤上的EditLog合并生成一個新的檢查點順便幫助NameNode減小EditLog的體積。它做的這個動作在Hadoop 1.x時代很流行但它始終是一個輔助性角色既沒有NameNode的完整元數(shù)據(jù)也不能在NameNode故障時自動接管服務(wù)。等你手動把它恢復(fù)出來業(yè)務(wù)早就斷了。1.2 HA方案里真正的角色分工Hadoop HA高可用集群的底座思路很直白用兩個NameNode組成主備一個Active對外提供服務(wù)一個Standby在旁邊實時熱備。Active掛了Standby馬上頂上去。聽起來很簡單但有兩個核心問題必須解決第一兩個NameNode的元數(shù)據(jù)如何保持一致元數(shù)據(jù)由兩部分組成FsImage是某個時間點的完整快照EditLog是后續(xù)的增量修改記錄。HA方案的做法是引入一組JournalNodeActive NameNode每做一次修改操作先把EditLog寫入這一組JournalNodeStandby NameNode從這組JournalNode拉取EditLog并應(yīng)用到自己的內(nèi)存里讓自己的元數(shù)據(jù)始終追上Active。這樣無論哪臺機器宕機另一臺的元數(shù)據(jù)都不會落后太多。第二誰來決定什么時候切換、切換給誰這里引入了ZooKeeper和ZKFCZooKeeper Failover Controller。每個NameNode旁邊都有一個ZKFC守護進程它的工作有兩塊一是定時探測本機NameNode的存活狀態(tài)和健康狀態(tài)二是和ZooKeeper中的一個臨時節(jié)點競爭鎖。Active的ZKFC成功持有鎖Standby的ZKFC在等待。一旦Active側(cè)的ZKFC探測到NameNode掛了它會主動釋放鎖Standby側(cè)的ZKFC發(fā)現(xiàn)鎖被釋放就競爭上鎖并把自己這邊的NameNode提升為Active。1.3 腦裂問題與fencing機制雙主設(shè)計最怕的不是一臺掛了而是兩臺都認為自己是Active同時對外提供服務(wù)。一旦出現(xiàn)這種局面兩個NameNode會同時往JournalNode寫EditLog元數(shù)據(jù)就徹底分叉了整個集群的元數(shù)據(jù)變成一鍋粥。這就是腦裂split-brain。為了防止腦裂HA方案強制要求在切換之前一定要把舊的Active NameNode隔離掉。這個隔離動作叫fencing柵欄。在Hadoop里最常用的是sshfence新的Active發(fā)出切換請求時通過SSH登錄到舊Active所在節(jié)點直接執(zhí)行命令把舊NameNode的進程殺掉。這個機制聽起來粗暴但在分布式系統(tǒng)里粗暴往往是最可靠的。這里有個被我反復(fù)強調(diào)的細節(jié)fencing動作依賴SSH免密而且必須是從新Active所在節(jié)點能免密登錄到舊Active所在節(jié)點。很多人搭建時配了單向免密結(jié)果切換的時候fencing執(zhí)行失敗整個自動切換流程卡住最后只能人肉介入。后面踩坑部分我會細講。1.4 用記賬本的類比理解JournalNode為了讓不熟悉分布式原理的朋友更容易理解我習慣把整個HA機制比作兩個會計共用一個賬本。Active會計負責記賬每次發(fā)生一筆新業(yè)務(wù)他不會只寫在自己的小本子上而是把記錄同步抄送到三個獨立的賬單房間JournalNode只有超過半數(shù)房間確認收到了這筆賬才算記成功。Standby會計不從Active那里直接拿數(shù)據(jù)而是自己去這三個房間把記錄取回來更新手里那本復(fù)制的賬本。這里為什么要超過半數(shù)確認因為就算其中一個房間著火了剩下兩個房間仍然能湊出多數(shù)保證賬目完整。如果只有兩個房間其中一個掛了剩下一個即使完好也無法滿足超過半數(shù)的條件整個賬本就沒人敢認定是完整的。這就是JournalNode必須配置奇數(shù)個、且最少三個的根本原因。一下把核心原理講透后面配置參數(shù)時你自然就明白為什么要填三個地址了。2. 三節(jié)點還是五節(jié)點主機規(guī)劃、版本選擇和易被忽略的預(yù)環(huán)境2.1 生產(chǎn)環(huán)境推薦的最小拓撲搭建HA集群之前第一件事是確定機器數(shù)量。我的建議是真正用于生產(chǎn)環(huán)境的Hadoop HA集群至少準備三臺機器。這三臺機器上要混部JournalNode、ZooKeeper、NameNode、ZKFC和DataNode角色分配大概是這樣的節(jié)點NameNodeZKFCJournalNodeZooKeeperDataNodenode1nn1初始Active有有有有node2nn2初始Standby有有有有node3無無有有有三臺機器里NameNode一定放在前兩臺兩臺的配置要盡量一樣內(nèi)存和CPU都不能差太多否則切換后性能差異會直接影響業(yè)務(wù)。JournalNode和ZooKeeper要落在三臺上湊出奇數(shù)個。如果你的機器更富余可以拆成五臺甚至更多NameNode和ZKFC仍然必須在同一臺JournalNode至少三臺ZooKeeper也至少三臺。為什么ZKFC必須和NameNode同機部署因為ZKFC要探測NameNode的進程狀態(tài)如果分開部署它只能通過RPC端口探測一旦網(wǎng)絡(luò)分區(qū)ZKFC可能誤判NameNode已死導(dǎo)致無謂的切換。放在同一臺機器上可以直接檢查本機進程判斷準確得多。2.2 版本與JDK的兼容性選擇版本選型是很多新手忽略的坑。我建議不要用太老的Hadoop 2.x除非你維護的是歷史存量集群。新搭建的集群直接用Hadoop 3.x系列比如3.2.4、3.3.6這些穩(wěn)定版本配套的ZooKeeper選3.6以上的版本。JDK方面Hadoop 3.x官方支持JDK 8和JDK 11。我自己在多個環(huán)境里測試下來JDK 8的兼容性最穩(wěn)如果你公司有強制安全要求必須用更高版本也要先做一輪功能性驗證再上生產(chǎn)。另外ZooKeeper本身也是跑在JVM上的所有節(jié)點的JDK版本保持一致不要一臺是8另一臺是11否則跨節(jié)點通信時可能出現(xiàn)序列化相關(guān)的問題。版本選擇的另一個隱藏要求是所有節(jié)點的Hadoop發(fā)行版版本必須一模一樣。有的團隊圖省事node1和node2用同一個版本node3卻用了稍老一點的版本JournalNode之間的通信協(xié)議有差異輕則日志刷WARN重則EditLog同步異常。2.3 用戶、目錄、SSH免密、時鐘同步正式搭之前有幾個環(huán)境項必須提前處理好任何一個出問題都會在啟動階段變成莫名其妙的報錯。第一統(tǒng)一使用普通用戶不要用root跑Hadoop。我習慣創(chuàng)建hadoop用戶然后用這個用戶解壓安裝包、創(chuàng)建數(shù)據(jù)目錄。原因是Hadoop的很多腳本對目錄權(quán)限有隱式要求用root運行容易在啟動時產(chǎn)生Permission denied或者目錄所有者的奇怪問題不好排查。第二規(guī)劃好數(shù)據(jù)目錄。NameNode元數(shù)據(jù)目錄和JournalNode數(shù)據(jù)目錄不要放在系統(tǒng)根分區(qū)更不要放在/tmp下面。我見過不止一次有人把hadoop.tmp.dir默認配置放到/tmp服務(wù)器重啟后/tmp被清理NameNode的FsImage和EditLog全沒了集群直接報廢。建議統(tǒng)一用/data/hadoop/tmp和/data/hadoop/jn這樣的獨立目錄并且預(yù)留足夠磁盤空間。第三SSH免密。搭建時我建議把三臺節(jié)點之間全部配成雙向免密不要只配NameNode到DataNode的單向。因為不僅啟動腳本要用SSH拉起遠端進程ZKFC的sshfence還要從新Active登錄到舊Active去殺進程。另外如果你的環(huán)境中有人改了SSH端口或者禁用了密碼登錄一定要提前確認免密鏈路全部通暢。第四時鐘同步。ZooKeeper的會話機制對時間偏差很敏感節(jié)點之間的系統(tǒng)時間如果差太多ZK會誤判會話超時進而觸發(fā)毫無意義的NameNode切換。生產(chǎn)環(huán)境用chronyd或者ntpd統(tǒng)一對時搭建前先用date命令人工確認三臺機器的時間基本一致。2.4 部署目錄結(jié)構(gòu)示例我習慣把軟件和數(shù)據(jù)目錄分開每個節(jié)點統(tǒng)一按下面這個結(jié)構(gòu)準備/opt/hadoopHadoop安裝目錄/opt/zookeeperZooKeeper安裝目錄/data/hadoop/tmpNameNode元數(shù)據(jù)目錄包含F(xiàn)sImage和EditLog/data/hadoop/jnJournalNode數(shù)據(jù)目錄/data/hadoop/logs各進程日志目錄日志一定要單獨放方便排查目錄準備好之后記得把/data目錄的屬主改成hadoop用戶并確認磁盤空間足夠。JournalNode的EditLog會持續(xù)增長建議單獨給/data/hadoop/jn掛一塊獨立磁盤避免和其他日志、臨時文件搶空間。3. 配置文件逐項拆解每個參數(shù)背后的防呆邏輯3.1 core-site.xml默認文件系統(tǒng)與ZK地址核心配置都在core-site.xml和hdfs-site.xml兩個文件里所有節(jié)點都要保持一致的配置。先看core-site.xml里必配的三個參數(shù)configuration property namefs.defaultFS/name valuehdfs://mycluster/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configurationfs.defaultFS這里填的不是某個單點主機名而是一個邏輯名稱mycluster這個名稱必須和下文中hdfs-site.xml里配置的nameservice完全一致。它決定了所有客戶端進程知道這套集群對外叫mycluster具體該連哪臺NameNode由后面的failover provider來決定。ha.zookeeper.quorum里填的是三臺ZooKeeper的地址逗號分隔一行寫完。這個參數(shù)會被ZKFC用來連接ZooKeeper集群也會被客戶端在解析集群狀態(tài)時使用。端口默認是2181如果你改了ZooKeeper端口這里必須同步改。hadoop.tmp.dir之所以要單獨強調(diào)是因為很多衍生目錄默認都在它下面。比如NameNode的元數(shù)據(jù)目錄默認是${hadoop.tmp.dir}/dfs/name如果你不把它指到獨立磁盤后面擴容和排障都會被系統(tǒng)盤空間卡脖子。3.2 hdfs-site.xmlnameservice、雙NN與JournalNodehdfs-site.xml是HA配置的核心參數(shù)最多也最容易填錯。我把關(guān)鍵的幾個拆開講property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /propertydfs.nameservices定義一個邏輯集群的名字dfs.ha.namenodes.mycluster定義了這個邏輯集群里有哪些NameNode這里用nn1和nn2作為兩個邏輯ID。注意nn1、nn2并不是機器名只是邏輯代號后面所有配置里都要用這兩個ID來區(qū)分兩臺NameNode。property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /property property namedfs.namenode.http-address.mycluster.nn1/name valuenode1:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenode2:9870/value /property這段是給兩個NameNode綁定實際的RPC地址和HTTP管理界面地址。RPC端口是客戶端訪問用的我習慣統(tǒng)一用8020HTTP端口是Web管理頁面Hadoop 3.x默認是9870。這些地址寫錯或者端口被占用啟動時NameNode會直接報BindException排查時優(yōu)先看端口和hosts解析。接下來是JournalNode的共享存儲配置這是HA的數(shù)據(jù)同步命脈property namedfs.namenode.shared.edits.dir/name valueqjournal://node1:8485;node2:8485;node3:8485/mycluster/value /property property namedfs.journalnode.edits.dir/name value/data/hadoop/jn/value /propertydfs.namenode.shared.edits.dir告訴兩個NameNode你們的EditLog要寫到這臺機器上的JournalNode多個地址用分號分隔路徑最后是/mycluster。這個/mycluster可以理解成JournalNode上命名空間的一個標識和前面的nameservice是兩回事很多人會混淆。dfs.journalnode.edits.dir是每臺機器上JournalNode進程本地存儲EditLog的目錄寫在hdfs-site.xml里各節(jié)點保持一致即可。3.3 自動故障轉(zhuǎn)移和隔離方法參數(shù)下面幾個參數(shù)直接決定能不能自動切換和切換時怎么防腦裂property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.connect-timeout/name value30000/value /property property namedfs.ha.fencing.ssh.private-key-files/name value/home/hadoop/.ssh/id_rsa/value /propertyautomatic-failover.enabled不設(shè)成true你搭起來的HA就只是個半成品NameNode掛了只能靠haadmin命令手動切換不會自動頂上去。很多教程沒強調(diào)這一點導(dǎo)致讀者搭完后發(fā)現(xiàn)完全不自動。ConfiguredFailoverProxyProvider是客戶端側(cè)的故障轉(zhuǎn)移代理。它的作用是讓客戶端在訪問NameNode失敗時自動嘗試另一臺NameNode而不是報錯。這個類名必須完整填寫不小心中間漏個字母就會在客戶端初始化時拋出ClassNotFoundException。sshfence是隔離方法結(jié)合前面的fencing原理這部分要重點檢查。connect-timeout是SSH連接超時時間單位毫秒我建議設(shè)成30000。太短在機器負載高時會誤判fencing失敗太長又會讓整個切換過程拖到一分鐘以上。private-key-files指定sshfence要用哪個私鑰認證必須配置成hadoop用戶的私鑰路徑并且對應(yīng)公鑰要已經(jīng)寫入所有目標節(jié)點的authorized_keys。3.4 完整配置樣例與參數(shù)速查表兩套配置我貼一份能直接用的完整版本你可以按自己的主機名和目錄調(diào)整core-site.xmlconfiguration property namefs.defaultFS/name valuehdfs://mycluster/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configurationhdfs-site.xmlconfiguration property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /property property namedfs.namenode.http-address.mycluster.nn1/name valuenode1:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenode2:9870/value /property property namedfs.namenode.shared.edits.dir/name valueqjournal://node1:8485;node2:8485;node3:8485/mycluster/value /property property namedfs.journalnode.edits.dir/name value/data/hadoop/jn/value /property property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.connect-timeout/name value30000/value /property property namedfs.ha.fencing.ssh.private-key-files/name value/home/hadoop/.ssh/id_rsa/value /property property namedfs.replication/name value2/value /property /configuration最后列一個參數(shù)速查表方便你配置后逐項核對參數(shù)含義常見錯誤fs.defaultFS客戶端默認訪問的HDFS集群地址寫成單機hdfs://node1:8020dfs.nameservicesHDFS邏輯集群名與fs.defaultFS不一致dfs.ha.namenodes.mycluster邏輯集群內(nèi)的NN列表把機器名當NN IDdfs.namenode.shared.edits.dirJournalNode共享編輯日志地址漏掉QJM協(xié)議前綴qjournaldfs.ha.automatic-failover.enabled是否開啟自動故障轉(zhuǎn)移只配了HA但沒開啟自動dfs.ha.fencing.methods隔離舊Active的方式?jīng)]配sshfence導(dǎo)致腦裂風險4. 首次啟動的嚴格順序從格式化到bootstrapStandby的完整命令鏈4.1 為什么JournalNode必須先于NameNode啟動我見過的很多第一次搭建失敗案例問題都出在啟動順序上。NameNode進程啟動時會去連接配置里指定的JournalNode讀取EditLog如果JournalNode還沒起來NameNode會一直重試連接直到超時報錯。所以首要原則是先啟動ZooKeeper再啟動所有JournalNode最后才啟動NameNode相關(guān)進程。JournalNode的啟動命令在Hadoop 3.x里是hdfs --daemon start journalnode三臺機器都要執(zhí)行。啟動后用jps可以確認看到JournalNode進程。這時候如果配置里的目錄權(quán)限不對JournalNode會立刻報錯退出所以啟動后最好看一眼日志或者用jps確認進程還活著。4.2 格式化只能做一次再談bootstrapStandby第一次搭建時必須對其中一個NameNode執(zhí)行元數(shù)據(jù)格式化生成初始的FsImage和ClusterIDhdfs namenode -format這里我要把話說得非常重只格式化nn1不要在nn2上再執(zhí)行同樣的format。如果兩臺NameNode分別格式化它們會生成不同的ClusterIDStandby節(jié)點啟動后根本無法與Active節(jié)點共享同一份元數(shù)據(jù)后面怎么同步都追不上。正確的做法是在nn2上執(zhí)行hdfs namenode -bootstrapStandbybootstrapStandby會自動從nn1Active所在節(jié)點的本地元數(shù)據(jù)目錄把FsImage和相關(guān)的VERSION等文件拷貝過來并構(gòu)建出Standby節(jié)點的初始元數(shù)據(jù)。它是HA集群搭建時的標準動作比手動scp再改配置穩(wěn)妥得多。4.3 格式化ZKFC狀態(tài)zkfc -formatZK還有一個只做一次的動作就是初始化ZooKeeper中的HA狀態(tài)hdfs zkfc -formatZK這個命令在任意一個NameNode節(jié)點上執(zhí)行一次即可。它的作用是在ZooKeeper里創(chuàng)建/hadoop-ha/mycluster節(jié)點ZKFC后續(xù)就是在這個節(jié)點上搶鎖。如果跳過這一步后面啟動ZKFC時它會報錯找不到父節(jié)點自動切換根本沒法工作。4.4 無一遺漏的首次啟動命令鏈我把完整命令鏈按順序列出來你在三臺機器上依次操作即可在三臺節(jié)點上分別啟動ZooKeeperzkServer.sh start在三臺節(jié)點上分別啟動JournalNodehdfs --daemon start journalnode在nn1所在節(jié)點執(zhí)行格式化hdfs namenode -format在nn2所在節(jié)點執(zhí)行bootstrapStandbyhdfs namenode -bootstrapStandby在nn1所在節(jié)點執(zhí)行ZKFC狀態(tài)初始化hdfs zkfc -formatZK分別在nn1、nn2上啟動NameNodehdfs --daemon start namenode分別在nn1、nn2上啟動ZKFChdfs --daemon start zkfc在任意一臺DataNode節(jié)點上啟動DataNodehdfs --daemon start datanode如果你配置了完整的slaves/workers文件列表也可以用start-dfs.sh統(tǒng)一啟動DataNode。但首次搭建我不推薦用腳本一把梭原因是你需要觀察每一步的日志輸出確認沒有隱藏錯誤。啟動完成后在第一臺NameNode節(jié)點上執(zhí)行hdfs haadmin -getAllServiceState正常情況下輸出應(yīng)該是nn1顯示activenn2顯示standby。如果看到的都是standby說明ZKFC搶鎖沒生效優(yōu)先檢查zkfc -formatZK是否執(zhí)行過、ZooKeeper地址是否可連通。4.5 日常重啟與首次搭建的命令區(qū)別集群搭好之后日常維護的啟動流程和首次搭建完全不同不用再格式化也不用再bootstrapStandby。正常流程是stop-dfs.sh # 然后在三臺機器上啟停ZooKeeper zkServer.sh start # 最后 start-dfs.shstart-dfs.sh在檢測到HA配置后會自動按順序拉起JournalNode、NameNode、ZKFC和DataNode你只需要確保ZooKeeper已經(jīng)提前啟動即可。日常重啟時如果某臺節(jié)點因為之前的異常退出還殘留PID文件腳本可能提示already running as process xxx這時候去/tmp/hadoop-xxx目錄下把對應(yīng).pid文件清掉再重啟。5. 故障切換實戰(zhàn)演練主動kill掉Active NameNode后集群發(fā)生了什么5.1 切換前準備測試文件與集群狀態(tài)基線集群搭建完成不代表萬事大吉我強烈建議每次交付前都做一輪故障切換演練。先把集群狀態(tài)確認一遍hdfs haadmin -getAllServiceState hdfs dfsadmin -report再往HDFS里放一個測試文件hdfs dfs -mkdir -p /test/ha echo hello hadoop ha | hdfs dfs -put - /test/ha/hello.txt hdfs dfs -cat /test/ha/hello.txt確保次文件能正常寫入和讀取這樣演練時心里有底。5.2 硬故障演練kill -9之后觀察切換硬故障演練的目標是模擬NameNode進程意外崩潰。先確定當前Active是nn1然后登錄nn1所在節(jié)點執(zhí)行jps # 找到NameNode的進程PID然后 kill -9 PIDkill -9之后的幾秒內(nèi)ZKFC會檢測到NameNode心跳消失主動釋放ZooKeeper鎖并觸發(fā)fencing流程。站在nn2節(jié)點上觀察日志tail -f /data/hadoop/logs/hadoop-hadoop-namenode-node2.log你會看到類似下面這樣的關(guān)鍵內(nèi)容檢測到Active NameNode失聯(lián)開始競選鎖執(zhí)行sshfence成功成為Active。整個過程快的話5到10秒就完成。切換完成后重新驗證服務(wù)hdfs haadmin -getAllServiceState hdfs dfs -cat /test/ha/hello.txt命令能正常返回說明客戶端請求已經(jīng)自動走了新的Active節(jié)點集群對外幾乎沒有中斷。這里要補充一點讀取操作完全無感但正在執(zhí)行的寫作業(yè)可能因為連接中斷而報錯需要客戶端重試。這是分布式系統(tǒng)的正常行為不是HA沒生效。5.3 優(yōu)雅切換演練手動置standby再置active除了硬故障日常運維中更多是主動運維切換比如要升級NameNode節(jié)點的內(nèi)核、換硬件。這時建議走優(yōu)雅切換流程讓故障轉(zhuǎn)移時間更短、對業(yè)務(wù)影響更小。先執(zhí)行hdfs haadmin -transitionToStandby nn1把nn1從Active降為Standby此時nn2會自動升為Active。如果自動故障轉(zhuǎn)移已經(jīng)開啟你甚至可以直接在nn2上執(zhí)行hdfs haadmin -transitionToActive nn2這里有個小原則要牢記手動切換時永遠先把當前Active降為Standby再把另一臺升為Active。如果反過來兩邊同時處于Active狀態(tài)即便有fencing機制也會觸發(fā)不必要的殺進程動作給自己找麻煩。5.4 切換耗時分析和腦裂防護效果驗證切換耗時主要受兩個因素影響一個是ZooKeeper的會話超時時間另一個是ZKFC對NameNode健康檢查的間隔。ZooKeeper默認sessionTimeout是30秒左右但ZKFC內(nèi)部還有更細粒度的健康探測所以實際切換很少真的等到30秒。在我自己的測試環(huán)境里硬故障切換在5到8秒之間優(yōu)雅切換在3秒左右。腦裂防護的驗證方式是在Simulate網(wǎng)絡(luò)分區(qū)時觀察是否只有一臺NN在寫EditLog。具體做法是人為把Active節(jié)點的ZKFC停掉但不殺NameNode這時候新Active可能會嘗試sshfence去殺舊Active的進程。如果配置正確舊NameNode進程會被殺掉系統(tǒng)里始終只有一個真正的Active。這個演練比較激進建議在測試環(huán)境先驗證明白了再在生產(chǎn)上操作。6. 搭建過程中的經(jīng)典事故排查思路與修復(fù)記錄6.1 事故一重復(fù)format導(dǎo)致clusterID分叉有一次我接手別人搭了一半的集群發(fā)現(xiàn)Node2的NameNode狀態(tài)一直顯示standby但它的日志里不斷出現(xiàn)同步EditLog失敗。我第一反應(yīng)是JournalNode之間的網(wǎng)絡(luò)問題抓了一圈包沒發(fā)現(xiàn)問題。后來直接把兩臺NameNode元數(shù)據(jù)目錄里的VERSION文件拉出來對比發(fā)現(xiàn)clusterID完全不一樣。根因很清晰當初搭建的人分別在兩臺NameNode上執(zhí)行了格式化導(dǎo)致兩個節(jié)點的元數(shù)據(jù)各自為政。修復(fù)方法也談不上優(yōu)雅只能把整個元數(shù)據(jù)存續(xù)狀態(tài)清掉重新來關(guān)閉所有進程刪掉/data/hadoop/tmp/dfs/name目錄內(nèi)容、/data/hadoop/jn目錄內(nèi)容、以及ZooKeeper里/hadoop-ha節(jié)點然后再嚴格按首次搭建的命令鏈走一遍。這個教訓告訴我們格式化這個動作在HA集群里是有排他性的做一次就夠了。6.2 事故二sshfence超時自動切換卡住第二次踩坑是在一次演練中我故意kill掉Active NameNode后等了半分鐘Standby還沒提升。查看日志發(fā)現(xiàn)fencing環(huán)節(jié)一直卡住報錯信息大致是ssh connection timed out。逐項排查后問題出在兩臺節(jié)點之間的SSH免密只配了一個方向從nn2到nn1可以免密但從nn1到nn2配漏了。切換發(fā)生時nn2作為新Active要登錄nn1去殺進程這條鏈路恰好沒打通。這個坑的隱蔽性在于平時啟動完全正常因為start-dfs.sh做的是遠端拉起那是另一條SSH鏈路而sshfence走的是完全相反的登錄方向。修復(fù)方法很簡單把雙向SSH免密徹底配好再確認dfs.ha.fencing.ssh.private-key-files指向的私鑰就是hadoop用戶持有的那一個。配好之后重新演練切換就順了。6.3 事故三時鐘漂移引發(fā)ZKFC反復(fù)抖動有一個環(huán)境在運行兩周后監(jiān)控突然報警NameNode狀態(tài)在active和standby之間來回切換業(yè)務(wù)側(cè)雖然沒中斷但每次切換都會產(chǎn)生大量告警和連接重試。翻ZKFC日志發(fā)現(xiàn)它不斷在連接ZooKeeper和會話過期之間循環(huán)。進一步檢查各節(jié)點系統(tǒng)時間發(fā)現(xiàn)其中一臺機器的時鐘比另外兩臺快了將近三分鐘。ZooKeeper的會話機制對超時非常敏感時鐘偏差一大服務(wù)端就認為客戶端會話已經(jīng)過期鎖被釋放另一邊又開始搶鎖兩邊就進入抖動狀態(tài)。修復(fù)手段不是只有調(diào)整時間而是裝上chronyd并配置好統(tǒng)一對時源讓所有節(jié)點的時間偏差保持在100毫秒以內(nèi)。從那以后我對所有集群節(jié)點都強制加了時間同步檢查搭建清單里也固定有這個步驟。6.4 事故四tmp目錄被系統(tǒng)清理導(dǎo)致元數(shù)據(jù)全丟早年間我見過一個更慘的案例。某套測試集群一直跑得好好的直到有一次服務(wù)器重啟整個HDFS的NameNode起不來了。排查時發(fā)現(xiàn)元數(shù)據(jù)目錄是空的原因是配置文件里的hadoop.tmp.dir指向了系統(tǒng)默認的/tmp目錄而很多操作系統(tǒng)的tmpfiles機制會在重啟后清理/tmp下的內(nèi)容。這個案例直接改變了我的目錄規(guī)劃原則Hadoop相關(guān)的所有持久化目錄必須放在獨立的數(shù)據(jù)盤上并且盡早在部署清單中免疫這種問題。FsImage是HDFS元數(shù)據(jù)安全的最后底線靠系統(tǒng)臨時目錄來保存是不可接受的。6.5 事故五JN單點部署HA形同虛設(shè)有一種情況最具有迷惑性節(jié)點上把雙NameNode配好了自動轉(zhuǎn)移也能工作但JournalNode也只有一個而且就跑在某個NameNode同一臺機器上。結(jié)果這臺機器整機宕機時元數(shù)據(jù)無法寫入JournalNode新Active也無法讀取到完整EditLog整個HA機制形同虛設(shè)。JournalNode的作用是共享EditLog它自身必須是多副本并且滿足多數(shù)派可用。生產(chǎn)環(huán)境JN最少三臺有條件的分散到不同機架或不同交換機下。每次審查集群架構(gòu)時我都會把JN的分布單獨拉出來看一遍寧可多花機器成本也不能讓HA變成假高可用。7. 日常維護與監(jiān)控建議搭建手冊寫完最后再補充幾條日常維護經(jīng)驗。第一監(jiān)控上一定要盯四類指標NameNode狀態(tài)是否有一臺active、ZKFC進程是否存活、JournalNode目錄磁盤使用率、ZooKeeper會話數(shù)是否穩(wěn)定。這四個指標能覆蓋大多數(shù)HA故障場景。第二建議每季度做一次主動切換演練不要等到事故來了才驗證HA鏈路。演練前選好業(yè)務(wù)低峰期把切換流程寫成checklist讓所有運維成員都實際操作一遍避免關(guān)鍵時刻只有個別人會處理。第三即使有了HAFsImage的異地備份也不能停。HA解決的是單點故障下的可用性問題它不能防范磁盤物理損壞或者元數(shù)據(jù)目錄被誤刪。定期把Active NameNode的FsImage文件同步到獨立存儲是cost很低但回報極高的事。最后再分享我的一個習慣每次搭建完集群我都會用hdfs haadmin -getAllServiceState確認狀態(tài)然后立刻做一次kill -9演練。這個過程雖然會短暫地制造一次故障但它能暴露幾乎所有配置層面的問題比我后來遇到事故再去救火要劃算得多。把HA集群當成一個需要反復(fù)驗證的系統(tǒng)而不是搭完就撒手的靜態(tài)配置這才是高可用真正落地的開始。