hadoop-2.7.4-翻譯文件-QJM高可用
HDFS高可用(QJM)
本指南概述了HDFS高可用性(HA)功能以及如何使用Quorum Journal Manager(QJM)功能配置和管理HA HDFS叢集。
本文件假設讀者對HDFS叢集中的一般元件和節點型別有一般的瞭解。有關詳細資訊,請參閱分散式叢集部署。
本指南討論如何使用Quorum Journal Manager(QJM)配置和使用HDFS HA,以共享Active和Standby NameNodes之間的編輯日誌。有關如何使用NFS為共享儲存而不是QJM配置HDFS HA的資訊,(暫無)
在Hadoop 2.0.0之前,NameNode在HDFS叢集中存在單點故障(SPOF)。每個叢集只有一個NameNode,如果該機器或程序變得不可用,則整個叢集將不可用,直到NameNode重新啟動或在單獨的計算機上啟動。
這兩個方面影響了HDFS叢集的總體可用性:
-
在計算機事件(如機器崩潰)的情況下,叢集將不可用,直到操作員重新啟動NameNode。
-
對NameNode機器上的計劃維護事件(如軟體或硬體升級),將導致叢集的宕機。
HDFS高可用性功能,通過在一個叢集中提供兩個具有熱備份功能的,主動/被動配置可選的NameNode,來解決上述問題。
在典型的HA群集中,兩個單獨的機器配置為NameNodes。在任何時間點,其中一個NameNodes處於Active狀態,另一個處於Standby狀態。Active NameNode負責群集中的所有客戶端操作,而Standby只是作為從屬節點,維護足夠的狀態以便必要時提供快速故障轉移。
為了使Standby節點保持其狀態與Active節點同步,兩個節點都與一組名為“JournalNodes”(JN)的單獨守護程式進行通訊。
為了提供快速故障切換,還需要Standby節點儲存叢集中檔案塊的位置的最新資訊。為了實現這一點,每個DataNodes配置了兩個NameNodes的位置,並同時向兩者傳送檔案塊資訊和心跳資訊。
對於HA群集的正確操作至關重要,因為一次只能有一個NameNodes處於Active狀態。否則,namespace的狀態將在兩者之間快速產生偏差,產生了資料丟失或其他非正常結果的風險。為了確保此屬性並防止所謂的“腦裂”,JournalNodes將只允許一個NameNode對其進行寫入操作。在故障切換期間,將要轉換為Active的NameNode將直接接管寫入JournalNodes的角色,這將有效地防止其他NameNode繼續處於Active狀態,從而允許新的Active節點可以安全地進行故障切換。
為了部署HA群集,您應該準備以下內容:
- NameNode主機 - 執行Active和Standby狀態NameNodes的計算機應採用效能相當的硬體,以及與非HA叢集中使用的硬體相當的硬體。
- JournalNode主機 -JournalNode守護程序是相對輕量級的,所以這些守護程序可以合理地與其他Hadoop守護程序(例如NameNodes,JobTracker或YARN ResourceManager)並置在同一機器上。注意:必須至少有3個JournalNode守護程序,因為編輯日誌修改必須寫入大多數JN(大於1/2)。這將允許系統容忍單個JN的故障。您還可以執行超過3個JournalNodes,在實際中為了增加系統可以容忍的故障節點數,您應該執行奇數JN(即3,5,7等)。請注意,當使用N JournalNodes執行時,系統最多可以忍受(N-1)/ 2數量的JN故障,並繼續正常工作。
請注意,在HA群集中,Standby NameNode還執行名稱空間狀態的檢查點任務,因此不需要在HA群集中執行Secondary NameNode,CheckpointNode或BackupNode。而且如果執行SNN,CN,BN還會產生錯誤。這一功能還支援在非HA的HDFS叢集轉化為HA叢集時重用先前專用於Secondary NameNode的硬體。
叢集部署
配置概覽
與聯邦HDFS配置類似,HA叢集配置向後相容,允許現有的單節點NameNode配置而無需對叢集做更改。新的配置設計使叢集中所有的節點可以使用相同的配置檔案,而不需要根據節點、機器的不同而採用不同配置。與聯邦HDFS一樣,HA叢集使用新的名稱服務來標識可能實際上由多個HA NameNode組成的單個HDFS例項。另外,一個稱為NameNode ID的新抽象概念與HA同步引入。叢集中的每個不同的NameNode具有不同的NameNode ID來區分。為了支援所有NameNodes配置寫入同一個配置檔案,相關配置引數加入NameNode ID的字尾。
配置細節
要配置HA NameNodes,必須在[hdfs-site.xml]配置檔案中新增多個配置選項。
設定這些配置的順序是不重要的,但是為dfs.nameservices和dfs.ha.namenodes選擇的值[nameservice ID]將決定隨後的關鍵字。因此,在設定其餘配置選項之前,您應該確定這些值。
-
dfs.nameservices - 這個新的名稱服務的邏輯名稱
為此名稱伺服器選擇邏輯名稱,例如“mycluster”,並使用此邏輯名稱作為此配置選項的值。你選擇的名字是任意的。它將用於叢集中的配置和絕對HDFS路徑的許可權元件。
注意:如果您還使用聯邦HDFS,則此配置設定還應包含其他名稱服務(HA或其他)的列表,以逗號分隔。
<property> <name>dfs.nameservices</name> <value>mycluster</value> </property>
-
dfs.ha.namenodes。[nameservice ID] - nameservice中每個NameNode的唯一識別符號
使用以逗號分隔的NameNode ID列表進行配置。DataNodes將使用它來確定叢集中的所有NameNodes。例如,如果以前使用“mycluster”作為nameervice ID,並且想要使用“nn1”和“nn2”作為NameNodes的各個ID,則可以將其配置為:
<property> <name>dfs.ha.namenodes.mycluster</name> <value>nn1,nn2</value> </property>
注意:目前,每個名稱服務最多隻能配置兩個NameNodes。
-
dfs.namenode.rpc-address。[nameservice ID]。[name node ID] - 每個要監聽的NameNode的完全限定的RPC地址
對於以前配置的兩個NameNode ID,請設定NameNode程序的完整地址和IPC埠。請注意,這將導致兩個單獨的配置選項。例如:
<property> <name>dfs.namenode.rpc-address.mycluster.nn1</name> <value>machine1.example.com:8020</value> </property> <property> <name>dfs.namenode.rpc-address.mycluster.nn2</name> <value>machine2.example.com:8020</value> </property>
注意:如果您願意,也可以配置“ servicerpc-address ”設定。
-
dfs.namenode.http-address。[nameservice ID]。[name node ID] - 每個要監聽的NameNode的完全限定的HTTP地址
類似於上面的rpc-address,設定兩個NameNodes的HTTP伺服器進行監聽的地址。例如:
<property> <name>dfs.namenode.http-address.mycluster.nn1</name> <value>machine1.example.com:50070</value> </property> <property> <name>dfs.namenode.http-address.mycluster.nn2</name> <value>machine2.example.com:50070</value> </property>
注意:如果您啟用了Hadoop的安全功能,您還應該為每個NameNode 設定類似的https地址。
-
dfs.namenode.shared.edits.dir - 定義一個包括JN節點的URI物件,用來標識NameNodes將寫/讀編輯日誌的位置。
這是個配置提供了共享編輯儲存的JournalNodes地址,由Active NameNode寫入並由Standby NameNode讀取,以儲存Active NameNode所做的所有檔案系統更改的最新資訊。雖然您必須指定多個JournalNode地址,但只能配置一個URI。URI應具有以下格式:qjournal:// * host1:port1 *; * host2:port2 *; * host3:port3 * / * journalId *。Journal ID應該為此名稱服務的唯一識別符號,允許單個JournalNodes集合為多個聯合名稱系統提供儲存。雖然這麼做不是必須的,但是對於日誌識別符號來說,重用名稱服務的ID是個好主意。
例如,如果此群集的JournalNodes在機器“node1.example.com”,“node2.example.com”和“node3.example.com”上執行,並且名稱服務ID為“mycluster”,則將使用以下作為此設定的值(JournalNode的預設埠為8485):
<property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value> </property>
-
dfs.client.failover.proxy.provider。[nameservice ID] - HDFS客戶端用於連線Active NameNode的Java類
配置將由DFS客戶端使用的Java類的名稱來確定哪個NameNode是當前的Active,因此來確定哪個NameNode當前正在為客戶端請求提供服務。Hadoop當前唯一的實現是ConfiguredFailoverProxyProvider,除非您使用自行定義的java類,否則應採用如下配置:
<property> <name>dfs.client.failover.proxy.provider.mycluster</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property>
-
dfs.ha.fencing.methods - 在故障轉移期間將用於隔離Active NameNode的指令碼或Java類的列表。
它將被用於保證系統的正確性,及在任何時間僅存在一個Active Namenode。重要的是,當使用Quorum Journal Manager時,只有一個NameNode將被允許寫入JournalNodes,所以不會導致檔案系統元資料的破壞,及裂腦現象。但是,發生故障轉移時,以前的Active NameNode可能會向客戶端提供讀取請求,這可能是過期的,直到該NameNode在嘗試寫入JournalNodes時關閉。因此,即使使用Quorum Journal Manager,仍然需要配置一些防護方法。但是,為了提高系統在防護機制發生故障時的可用性,建議配置防護方法,保證將其作為列表中最後的防護方法返回true。注意,如果您選擇不使用實際的防護方法,您仍然必須為此設定配置一些內容,例如“ shell(/ bin / true) ”。
在故障切換期間使用的防護方法被配置為使用回車符分隔的列表,它將按順序嘗試,直到一個指示隔離成功。Hadoop有兩種方法:shell和sshfence。有關實現自己的定製隔離方法的資訊,請參閱org.apache.hadoop.ha.NodeFencer類。
sshfence - SSH到Active NameNode並終止程序
該sshfence選項SSHes到目標節點,並使用fuser命令殺死程序監聽服務的TCP埠上。為了使這個隔離選項工作,它必須能夠SSH到目標節點而不提供密碼。因此,還必須配置dfs.ha.fencing.ssh.private-key-files選項,該選項是以逗號分隔的SSH私鑰檔案列表。例如:
<property> <name>dfs.ha.fencing.methods</name> <value>sshfence</value> </property> <property> <name>dfs.ha.fencing.ssh.private-key-files</name> <value>/home/exampleuser/.ssh/id_rsa</value> </property>
或者,可以配置非標準使用者名稱或埠來執行SSH。也可以為SSH配置超時時間(以毫秒為單位),之後該防護方法將被認為失敗。它可以像這樣配置:
<property> <name>dfs.ha.fencing.methods</name> <value>sshfence([[username][:port]])</value> </property> <property> <name>dfs.ha.fencing.ssh.connect-timeout</name> <value>30000</value> </property>
shell - 執行一個任意的shell命令來隔離Active NameNode
所述shell隔離方法可以執行任意的shell指令碼。它可以像這樣配置:
<property> <name>dfs.ha.fencing.methods</name> <value>shell(/path/to/my/script.sh arg1 arg2 ...)</value> </property>
'('和')'之間的字串會直接傳遞給bash shell,並且不能包含任何括號。
該shell命令所執行的環境將包含所有當前的Hadoop配置變數,將會使用 '_' 替換hadoop配置變數中所有的 '.' 字元。所使用的配置檔案已經從指定的NameNode通用配置中提取出了所有配置資訊 - 例如,dfs_namenode_rpc-address將包含目標節點的RPC地址,即使該配置可以將該變數指定為dfs.namenode.rpc-address.ns1 .nn1。
另外,還可以使用下列參考要隔離的目標節點的變數:
$ target_host 要隔離的節點的主機名 $ target_port 要隔離的節點的IPC埠 $ TARGET_ADDRESS 要隔離的主機:埠 $ target_nameserviceid 要隔離的NN的名稱服務ID $ target_namenodeid 要隔離的NN的namenode ID 這些環境變數也可以用作shell命令本身的替代。例如:
<property> <name>dfs.ha.fencing.methods</name> <value>shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)</value> </property>
如果shell命令返的退出程式碼為0,則確定隔離是成功的。如果它返回任何其他退出程式碼,則隔離不成功,並且將嘗試列表中的下一個隔離方法。
注意:此隔離方法不會執行任何超時。如果超時是必要的,它們應該在shell指令碼本身中實現(例如,通過在幾秒鐘內分割子shell來殺死其父程序)。
-
fs.defaultFS - 當沒有給出Hadoop FS客戶端時使用的預設路徑字首。
或者,您現在可以配置Hadoop客戶端使用新的啟用HA的邏輯URI。如果您以前使用“mycluster”作為名稱服務ID,則它將是所有HDFS路徑中的一部分。在core-site.xml檔案中可以這樣配置:
<property> <name>fs.defaultFS</name> <value>hdfs://mycluster</value> </property>
-
dfs.journalnode.edits.dir - JournalNode守護程序儲存其本地狀態的路徑
這是JournalNode機器上的絕對路徑,來儲存JN的編輯日誌和其他本地狀態。您只能使用單一路徑進行此配置。通過執行多個單獨的JournalNodes或通過在本地連線的RAID陣列上配置此目錄來提供此資料的冗餘。例如:
<property> <name>dfs.journalnode.edits.dir</name> <value>/path/to/journal/node/local/data</value> </property>
部署細節
完成所有必要的配置選項後,必須在對應的的機器上啟動JournalNode守護程式。這可以通過執行命令“ hadoop-daemons.sh start journalnode ”並等待守護程序在每個相關的機器上啟動,或者ssh登入到指定機器啟動單一的journalnode程序“ssh exp hadooop-daemon.sh start journalnode”。
一旦JournalNodes啟動,必須首先同步兩個HA NameNodes的磁碟元資料。
-
如果要啟用新的HDFS群集,則應首先在其中一個NameNode上執行format命令(hdfs namenode -format)(之後啟動該NameNode)。
-
如果您已經格式化了NameNode,或者將非HA叢集轉換為HA叢集,則現在應該在未格式化的NameNode節點通過執行命令“ hdfs namenode -bootstrapStandby ”命令將已啟動NameNode元資料目錄的內容複製到該未格式化的NameNode當中。執行此命令還將確保JournalNodes(由dfs.namenode.shared.edits.dir配置)包含足夠的編輯事務以能夠啟動兩個NameNodes。
-
如果將非HA NameNode轉換為HA NameNode,則應執行命令“ hdfs namenode -initializeSharedEdits ”,該命令將使用本地NameNode編輯目錄中的編輯日誌初始化JournalNodes。
此時,您可以像正常啟動NameNode一樣啟動兩個HA NameNodes。
您可以通過瀏覽其配置的HTTP地址分別訪問每個NameNodes的web-ui。您應該注意,配置的地址旁邊將是NameNode的HA狀態(“standby”或“active”)。每當HA NameNode啟動時,它的初始狀態都是standby。
管理命令
現在,您的HA名稱節點已配置並啟動,您將可以訪問一些其他命令來管理HA HDFS叢集。具體來說,您應該熟悉“ hdfs haadmin ”命令的所有子命令。執行此命令而沒有任何其他引數將顯示以下使用資訊:
用法:haadmin [-transitionToActive <serviceId>] [-transitionToStandby <serviceId>] [-failover [--forcefence] [--forceactive] <serviceId> <serviceId>] [-getServiceState <serviceId>] [-checkHealth <serviceId>] [-help <command>]
本指南介紹了每個子命令的高階使用。對於每個子命令的具體使用資訊,應執行“ hdfs haadmin -help <command >”。
-
transitionToActive / transitionToStandby - 將給定NameNode的狀態轉換為Active或Standby
這些子命令會使給定的NameNode轉換到Active或Standby狀態。這些命令不會嘗試執行任何隔離方法,因此很少使用。我們通常偏向於使用“ hdfs haadmin -failover ”子命令來控制NameNode的狀態轉換而非前者。
-
failover - 在兩個NameNodes之間啟動故障轉移
此子命令啟動故障轉移,從第一個NameNode切換到第二個NameNode。如果第一個NameNode處於standby狀態,則該命令只會將第二個狀態轉換為active狀態,而不會出現錯誤。如果第一個NameNode處於活動狀態,則會嘗試將其正常地轉換到standby狀態。如果轉換失敗,將按順序嘗試隔離方法(由dfs.ha.fencing.methods配置),直到轉換成功。只有在此過程之後,第二個NameNode才會轉換到活動狀態。如果沒有隔離方法成功,則第二個NameNode將不會轉換到活動狀態,並返回錯誤。
-
getServiceState - 確定給定的NameNode的執行狀態,active或者standby
連線到提供的NameNode以確定其當前狀態,將“standby”或“active”適當地列印到標準輸出。計劃任務或監視指令碼可能會使用此子命令,這些指令碼需要基於NameNode當前處於活動狀態或待機狀態而執行不同的操作。
-
checkHealth - 檢查給定NameNode的健康狀況
連線到指定的NameNode以檢查其執行狀況。NameNode能夠對其自身執行一些診斷,包括檢查內部服務是否按預期執行。如果NameNode是健康的,則此命令將返回0,否則返回非零值。可以使用此命令達到監控目的。
注意:checkhealth命令還沒有實現,目前總是會返回成功,除非給定的NameNode完全關閉。
自動故障轉移
介紹
以上部分介紹如何配置手動故障切換。在該模式下,即使主動節點出現故障,系統也不會自動觸發從active NameNode到standby NameNode的故障轉移。本節介紹如何配置和部署自動故障切換。
元件
自動故障切換為HDFS部署添加了兩個新元件:ZooKeeper仲裁和ZKFailoverController程序(簡寫為ZKFC)。
Apache ZooKeeper是一種高度可用的服務,用於維護少量協調資料,通知客戶該資料的更改,以及監控客戶端的故障。自動HDFS故障切換的實現依賴於ZooKeeper,具體如下:
-
故障檢測 - 群集中的每個NameNode機器在ZooKeeper中維護一個持久會話。如果機器崩潰,ZooKeeper會話將過期,通知另一個NameNode應該觸發故障切換。
-
活動NameNode推選 - ZooKeeper提供了一個簡單的機制,專門用於active NameNode的推選。如果當前活動的NameNode崩潰,則另一個節點可能會在ZooKeeper中採取特殊排他鎖,來表示該節點應該成為下一個active節點。
ZKFailoverController(ZKFC)是一個新的元件,它是一個ZooKeeper客戶端,還監視和管理NameNode的狀態。執行NameNode的每臺機器也執行一個ZKFC,ZKFC負責:
-
健康監控 - ZKFC定期使用健康檢查命令對其本地NameNode進行ping操作。只要NameNode以健康狀態作出響應,ZKFC認為節點健康。如果節點崩潰,宕機或以其他方式進入不健康狀態,健康狀況監視器會將其標記為不健康。
-
ZooKeeper會話管理 - 當本地NameNode健康時,ZKFC在ZooKeeper中持有一個會話。如果本地NameNode處於活動狀態,它也會儲存一個特殊的znode“鎖”。這個鎖由ZooKeeper“短暫”的節點提供支援; 如果會話過期,znode鎖將被自動刪除。
-
基於ZooKeeper的選舉 - 如果本地NameNode是健康的,並且ZKFC看到沒有其他節點當前持有znode鎖,則它本身將嘗試獲取該鎖。如果成功,則該zkfc“贏得選舉”,並負責執行故障切換,使其本地NameNode處於活動狀態。故障轉移過程類似於上述手動故障轉移:首先,如果需要的話會先前的active NameNode隔離,然後將本地NameNode轉換到活動狀態。
有關自動故障切換設計的更多詳細資訊,請參閱Apache HDFS JIRA上附帶的HDFS-2185設計文件。
部署ZooKeeper
在典型的部署中,ZooKeeper守護程序配置為在三個或五個節點上執行。由於ZooKeeper本身具有輕量資源要求,因此可以將ZooKeeper節點與HDFS NameNode和Standby Node在同一硬體上並置。許多程式(員)猿選擇在與YARN ResourceManager相同的節點上部署第三個ZooKeeper程序。建議將ZooKeeper節點配置為將其資料儲存在與HDFS元資料不同的磁碟驅動器上,以獲得最佳效能和隔離。
ZooKeeper的設定超出了本文件的範圍。我們假設您已經設定了執行在三個或更多節點上的ZooKeeper叢集,並通過使用ZK CLI進行連線來驗證其正確的操作。
在開始之前
在開始配置自動故障切換之前,應該關閉叢集。當叢集執行時,目前無法從手動故障轉移配置轉換到自動故障轉移配置。
配置自動故障轉移
自動故障轉移的配置需要為您的配置新增兩個新引數。在您的[hdfs-site.xml]檔案中,新增:
<property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property>
這指定應該為叢集設定自動故障切換。在您的[core-site.xml]檔案中,新增:
<property> <name>ha.zookeeper.quorum</name> <value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value> </property>
這將列出執行ZooKeeper服務的主機埠對。
與文件中先前描述的引數一樣,這些設定可以通過使用名稱服務ID作為字尾關鍵字來對每個nameservice進行配置。例如,在啟用聯邦的叢集中,您可以通過設定dfs.ha.automatic-failover.enabled.my-nameservice-id來顯式啟用僅一個名稱伺服器的自動故障轉移。
還有其他幾個配置引數可以設定為控制自動故障切換的行為; 然而,它們對大多數安裝沒有必要。有關詳細資訊,請參閱配置關鍵字具體文件。
在ZooKeeper中初始化HA狀態
新增配置鍵後,下一步是在ZooKeeper中初始化所需的狀態。您可以通過從其中一個NameNode主機執行以下命令來執行此操作。
[hdfs] $ $ HADOOP_PREFIX / bin / hdfs zkfc -formatZK
這將在ZooKeeper中建立一個znode來為自動故障切換系統儲存其資料。
使用start-dfs.sh啟動群集
由於配置中啟用了自動故障轉移功能,所以start-dfs.sh指令碼現在將自動在執行NameNode的任何計算機上啟動ZKFC守護程式。當ZKFC啟動時,它們將自動選舉一個NameNodes以使其成為活動狀態。
手動啟動叢集
如果手動管理叢集中的服務,則需要在執行NameNode的每臺計算機上手動啟動zkfc守護程式。您可以通過執行以下命令啟動守護程式:
[hdfs] $ $ HADOOP_PREFIX / sbin / hadoop-daemon.sh --script $ HADOOP_PREFIX / bin / hdfs start zkfc
訪問ZooKeeper的許可權保護
如果您正在執行安全叢集,則可能需要確保儲存在ZooKeeper中的資訊也得到保護。這樣可以防止惡意客戶端修改ZooKeeper中的元資料或潛在地觸發虛假的故障轉移。
為了保護ZooKeeper中的資訊,首先將以下內容新增到您的core-site.xml檔案中:
<property> <name>ha.zookeeper.auth</name> <value>@/path/to/zk-auth.txt</value> </property> <property> <name>ha.zookeeper.acl</name> <value>@/path/to/zk-acl.txt</value> </property>
請注意這些值中的“@”字元 - 這表示配置不是內聯的,而是指向磁碟上的檔案。
第一個配置的檔案指定了一個ZooKeeper認證列表,與ZK CLI使用的格式相同。例如,您可以指定以下內容:
digest:hdfs-zkfcs:mypassword
...其中hdfs-zkfcs是ZooKeeper的唯一使用者名稱,mypassword是用作密碼的唯一字串。
接下來,使用以下命令生成與此身份驗證相對應的ZooKeeper ACL:
[hdfs]$ java -cp $ZK_HOME/lib/*:$ZK_HOME/zookeeper-3.4.2.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider hdfs-zkfcs:mypassword output: hdfs-zkfcs:mypassword->hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs=
將' - >'字串後的輸出部分複製貼上到檔案zk-acls.txt中,字首為“ digest:” 。例如:
digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda
為了使這些ACL生效,您應該如上所述重新執行zkfc -formatZK命令。
這樣做後,您可以從ZK CLI驗證ACL,如下所示:
[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha 'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM= : cdrwa
驗證自動故障轉移
一旦設定了自動故障切換,您應該測試其操作。為此,首先找到活動的NameNode。您可以通過訪問NameNode Web-UI面來檢視哪個節點處於活動狀態 - 每個節點在頁面頂部顯示了其HA狀態。
找到活動的NameNode後,可以在該節點製造一些故障。例如,可以使用kill -9 <NN/ZKFC pid>來模擬JVM崩潰。或者,您可以重新啟動機器或拔掉其網路介面(可以使用 ifdown eth0 命令)以模擬不同型別的中斷。觸發您想要測試的中斷後,其他NameNode將在幾秒鐘內自動變為活動狀態。檢測故障並觸發故障切換所需的時間取決於ha.zookeeper.session-timeout.ms的配置,但預設為5秒。
如果測試不成功,您可能存在配置錯誤。檢查zkfc守護程式以及NameNode守護程式的日誌,以進一步診斷問題。
自動故障轉移常見問題
-
我以任何特定的順序啟動ZKFC和NameNode守護程序很重要嗎?
否。在任何給定的節點上,您可以在其對應的NameNode之前或之後啟動ZKFC。
-
我應該進行什麼額外的監測嗎?
您應該在執行NameNode的每個主機上新增監控,以確保ZKFC保持執行。在某些型別的ZooKeeper故障中,例如,ZKFC可能會意外退出,並應重新啟動zkfc以確保系統已準備好進行自動故障轉移。
此外,您應該監視ZooKeeper仲裁中的每個伺服器。如果ZooKeeper崩潰,則自動故障切換將不起作用。
-
如果ZooKeeper停機,會發生什麼?
如果ZooKeeper群集崩潰,則不會觸發自動故障轉移。然而,HDFS將繼續執行而沒有任何影響。當ZooKeeper重新啟動時,HDFS將重新連線沒有任何問題。
-
我可以將我的一個NameNodes指定為主要/首選項嗎?
不,目前不支援。首先啟動NameNode將變為活動狀態。您可以選擇以特定順序啟動叢集,以便首選節點首先啟動。
-
配置自動故障切換時,如何啟動手動故障切換?
即使配置了自動故障切換,也可以使用相同的hdfs haadmin命令啟動手動故障切換。它將進行協調故障切換。
HDFS升級/完成/回滾與HA啟用
在HDFS版本之間進行更改時,有時可以簡單地安裝較新的版本,並重新啟動叢集。然而,有時升級您正在執行的HDFS版本可能需要更改磁碟上的資料。在這種情況下,在安裝新軟體之後,必須使用HDFS升級/完成/回滾工具。這個過程在HA環境中變得更加複雜,因為NN所依賴的磁碟元資料是被定義為分部核實儲存的:在成對的HA NN上,在JournalNodes上,以及在QJM被用於共享的編輯日誌。本部分介紹在HA設定中使用HDFS升級/完成/回滾工具的步驟。
要執行HA升級,操作員必須執行以下操作:
-
正常關閉所有NN,並安裝較新的版本。
-
啟動所有JN。請注意,執行升級、回滾或完成操作時,所有JN都正在執行至關重要。如果任何JN在執行任何這些操作時關閉,操作都將失敗。
-
使用'-upgrade'引數啟動其中一個NN。
-
一開始,這個NN將不像往常一樣在HA設定中進入待機狀態。相反,此NN將立即進入活動狀態,執行其本地儲存目錄的升級,並執行共享編輯日誌的升級。
-
此時,HA對中的其他NN將與升級的NN不同步。為了使其恢復同步,並且再次具有高度可用的設定,您應該通過使用'-bootstrapStandby'引數執行NN來重新引導該NameNode 。使用'-upgrade'標誌啟動這個第二個NN是一個錯誤操作。
請注意,如果您在完成、升級或回滾操作之前的任何時候之前重新啟動NameNodes,那麼您應該正常啟動NN,即沒有任何特殊的啟動引數。
要完成HA升級,操作員可以在兩個NN同時執行並且有且只有其中一個處於active態時使用“hdfs dfsadmin -finalizeUpgrade”命令。此時發生的活動NN將執行共享日誌的最終化,並且本地目錄中包含其先前FS狀態的NN將對其狀態進行刪除。
要執行升級的回滾,應首先關閉兩個NN。運營商應該在啟動升級過程的NN上執行回滾命令,該命令將對本地目錄進行回滾,以及NFS或JN上的共享日誌。之後,應該啟動這個NN,並且操作員應該在另一個NN上執行`-bootstrapStandby',使兩個NN以回滾後的檔案系統狀態保持同步。