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以回滾後的檔案系統狀態保持同步。