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