翻譯： http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
版本： 2.9.0
- Purpose
- Note: Using the Quorum Journal Manager or Conventional Shared Storage
- Background
- Architecture
- Hardware resources
- Deployment
- Automatic Failover
- Automatic Failover FAQ
- HDFS Upgrade/Finalization/Rollback with HA Enabled
目的
本指南介紹基于Quorum Journal Manager （QJM）的 高可用性（HA）以及如何配置和管理HA HDFS群集。
本文檔假定讀者對HDFS集群中的通用組件和節點類型有一個大體的了解。有關詳細信息，請參閱HDFS體系結構指南。
注意：使用仲裁日記管理器QJM或常規共享存儲
本指南討論如何使用仲裁日志管理器（QJM）配置HDFS HA。有關如何使用NFS配置HDFS HA而不是QJM的信息，請參閱此替代指南。
背景
在Hadoop 2.0.0之前，NameNode是HDFS集群中的單點故障（SPOF）。每個群集都有一個NameNode，如果該機器或進程不可用，整個群集將不可用，直到NameNode重新啟動或在單獨的計算機上啟動為止。
這在兩個主要方面影響了HDFS集群的總體可用性：
在計劃外事件（例如機器崩潰）的情況下，直到操作員重新啟動NameNode后，群集才可用。
計劃的維護事件（如NameNode計算機上的軟件或硬件升級），集群在維護時間內都不可用。
HDFS高可用性功能通過在同一集群中運行兩個NameNode來實現，冗余NameNode具有熱備功能。這允許在計算機崩潰的情況下快速故障轉移到新的NameNode，或者為計劃維護目的而進行正常的管理員啟動的故障轉移。
架構
在典型的HA群集中，將兩臺獨立的機器配置為NameNode。在任何時候，只有一個NameNodes處于Active狀態，另一個處于Standby狀態。活動NameNode負責群集中的所有客戶端操作，而Standby僅充當從服務器，并保持同步狀態時刻準備在必要時提供快速故障轉移。
為了使備用節點保持其與主動節點的狀態同步，兩個節點都與一組稱為“日志節點”（JN）的獨立守護進程進行通信。當活動節點執行任何名稱空間修改時，它會將修改記錄持久記錄到大多數的JN中。備用節點能夠讀取來自JN的編輯日志，并不斷監視更改編輯日志。當備用節點看到編輯時，它將它們應用到自己的名稱空間。如果發生故障轉移，備用服務器將確保它在將自己提升為活動狀態之前已經從JounalNodes中讀取所有編輯。這確保了在故障轉移發生之前命名空間狀態已完全同步。
為了提供快速故障切換，備用節點還需要有關于集群中塊的位置的最新信息。為了實現這一點，DataNode配置了兩個NameNode的位置，并將塊位置信息和心跳發送到兩者。
一次只有一個NameNode處于活動狀態對HA集群至關重要。否則，命名空間狀態將很快在兩者之間發生分歧，從而可能導致數據丟失或其他不正確的結果。為了防止所謂的“裂腦場景”，JournalNodes將永遠只允許一個NameNode成為一個writer。在故障轉移期間，要成為活動狀態的NameNode將簡單地接管寫入JournalNodes的角色，這將有效地防止其他NameNode繼續處于活動狀態，從而允許新的活動安全地進行故障轉移。
硬件資源
為了部署HA群集，您應該準備以下內容：
NameNode 機器 - 運行Active和Standby NameNode的計算機應該具有相同的硬件，以及與不使用HA集群時的硬件相同。
JournalNode機器 - 您運行JournalNodes的機器。JournalNode守護進程相對輕量級，因此這些守護進程可以合理地與具有其他Hadoop守護進程的計算機并置，例如NameNodes，JobTracker或YARN ResourceManager。注意：必須至少有3個JournalNode守護進程，因為必須將編輯日志修改寫入大多數JN。這將允許系統容忍單臺機器的故障。您也可以運行3個以上的JournalNodes，但為了實際增加系統可以容忍的故障次數，您應該運行奇數個JN（即3，5，7等）。請注意，在運行N個JournalNodes時，系統最多可以承受（N-1）/ 2次故障并繼續正常運行。
請注意，在HA群集中，備用NameNode還執行名稱空間狀態的檢查點，因此不需要在HA群集中運行Secondary NameNode，CheckpointNode或BackupNode。事實上，運行這些服務會出現錯誤。因此允許將原來準備專用于Secondary NameNode的硬件用于部署其他服務。
部署
配置概述
與聯盟federation配置類似，HA配置向后兼容，允許現有的單一NameNode無需更改即可運行。新配置的設計使集群中的所有節點都可以具有相同的配置，而無需根據節點的類型將不同的配置文件部署到不同的機器。
和HDFS聯合一樣，HA集群重用 nameservice ID 來標識實際上可能由多個HA NameNode組成的單個HDFS實例。另外，HA中添加了名為 NameNode ID 的新抽象。群集中每個不同的NameNode都有一個不同的NameNode ID來區分它。為了支持在單個配置文件配置所有NameNode，請在相關配置參數使用后綴nameservice ID以及NameNode ID。
配置細節
要配置HA NameNode，您必須將多個配置選項添加到您的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列表。這將由DataNode用于確定群集中的所有NameNode。例如，如果您使用“mycluster”作為名稱服務標識，并且您希望使用“nn1”和“nn2”作為NameNodes的單個標識，則可以這樣配置它：
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2</value>
</property>
注意：目前，每個名稱服務最多只能配置兩個NameNode。
-
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類似，為兩個NameNode的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 - 標識NameNode將寫入/讀取編輯的JN組的URI
該配置提供JournalNode的地址，由Active NameNode編寫并由Standby NameNode讀取，使用Standby保持與Active NameNode所做的所有文件系統更改的一致最新狀態。盡管您必須指定多個JournalNode地址，但您應該只配置其中一個URI。URI的格式應為：qjournal://host1:port1;host2:port2;host3:port3/journalId 。日志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和RequestHedgingProxyProvider（對于第一次調用，它同時調用所有名稱節點來確定活動的名稱節點，并且在隨后的請求中調用活動的名稱節點直到發生故障轉移），所以除非您使用自定義代理提供程序，否則請使用其中之一。例如：
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
-
dfs.ha.fencing.methods - 在故障轉移期間將用于遏制活動NameNode的腳本或Java類的列表
系統的正確性是基于如下期望的，即在任何給定時間只有一個NameNode處于活動狀態。重要的是，在使用仲裁日志管理器時，只有一個NameNode將被允許寫入JournalNodes，因此不會破壞裂腦場景中的文件系統元數據。但是，當發生故障轉移時，前面的Active NameNode仍可能向客戶端提供讀取請求，這可能會過時，直到NameNode在嘗試寫入JournalNodes時關閉。由于這個原因，即使在使用仲裁日志管理器時，仍然需要配置一些屏蔽方法。但是，為了在防護機制發生故障的情況下提高系統的可用性，建議配置一種防護方法，該防護方法可保證作為列表中的最后一個防護方法返回成功。請注意，如果您選擇不使用實際的防護方法，則仍必須為此設置配置一些內容，例如 “shell(/bin/true)” 。
故障切換期間使用的防護方法將配置為一個以回車分隔的列表，該列表將按順序嘗試，直到指示防護成功為止。Hadoop提供了兩種方法：shell和sshfence。有關實現自己的自定義fencing方法的信息，請參閱org.apache.hadoop.ha.NodeFencer類。
sshfence - SSH到活動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命令來隔離活動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配置變量的環境中運行，'_'字符替換任何'.'。配置鍵中的字符。所使用的配置已將任何名稱特定于節點的配置升級為其通用形式 - 例如dfs_namenode_rpc-address將包含目標節點的RPC地址，即使配置可能將該變量指定為dfs.namenode.rpc-address.ns1 .nn1。
此外，還提供了以下指向要防護的目標節點的變量：
這些環境變量也可以用作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”作為名稱服務標識，則這將是所有HDFS路徑的權限部分的值。這可能是這樣配置的，在你的core-site.xml文件中：
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
-
dfs.journalnode.edits.dir - JournalNode守護進程用于存儲其本地狀態的路徑
這是JournalNode計算機上絕對路徑，JN將使用編輯和其他本地狀態進行存儲。您只能為此配置使用單個路徑。通過運行多個單獨的JournalNode或通過在本地連接的RAID陣列上配置此目錄來提供此數據的冗余。例如：
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/path/to/journal/node/local/data</value>
</property>
部署詳情
在設置了所有必要的配置選項之后，您必須啟動JournalNode守護進程。這可以通過運行命令“ hadoop-daemon.sh start journalnode ”并等待守護進程在每臺相關機器上啟動來完成。
JournalNodes啟動后，必須首先同步兩個HA NameNodes的磁盤元數據。
如果您正在設置新的HDFS集群，則應首先在NameNode之一上運行format命令（hdfs namenode -format）。
如果您已經格式化了NameNode，或者將未啟用HA的群集轉換為啟用HA，那么現在拷貝NameNode上的元數據目錄到另一臺，然后在未格式化的NameNode上執行 “hdfs namenode -bootstrapStandby” 。運行此命令還將確保JournalNodes（由dfs.namenode.shared.edits.dir配置）包含足夠多的編輯事務以便能夠啟動兩個NameNode。
如果要將非HA NameNode轉換為HA，則應運行命令“ hdfs namenode -initializeSharedEdits ”，該命令將使用NameNode的編輯目錄的編輯數據初始化JournalNodes。
此時，您可以像平時啟動NameNode一樣啟動兩個HA NameNode。
您可以通過瀏覽到其配置的HTTP地址來分別訪問每個NameNode的網頁。您應該注意到，配置的地址旁邊將是NameNode的HA狀態（“待機”或“活動”）。每當HA NameNode啟動時，它最初都處于Standby狀態。
管理命令
現在您的HA NameNode已配置并啟動，您將可以訪問一些其他命令來管理HA HDFS集群。具體來說，您應該熟悉“ hdfs haadmin ”命令的所有子命令。不帶任何附加參數運行此命令將顯示以下使用信息：
Usage: haadmin
[-transitionToActive <serviceId>]
[-transitionToStandby <serviceId>]
[-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
[-getServiceState <serviceId>]
[-getAllServiceState]
[-checkHealth <serviceId>]
[-help <command>]
本指南介紹了每個子命令的高級用法。有關每個子命令的具體使用信息，應運行“ hdfs haadmin -help <命令 >”。
-
transitionToActive和transitionToStandby - 將給定NameNode的狀態轉換為Active或Standby
這些子命令會使給定的NameNode分別轉換到活動或待機狀態。這些命令不會嘗試執行任何防護，因此應該很少使用。相反，人們應該總是喜歡使用“ hdfs haadmin -failover”子命令。
-
**failover ** - 在兩個NameNode之間啟動故障轉移
此子命令導致從第一個提供的NameNode到第二個的故障轉移。如果第一個NameNode處于Standby狀態，則此命令只是將第二個NameNode轉換為Active狀態而不會出錯。如果第一個NameNode處于Active狀態，則會嘗試將其正常轉換到Standby狀態。如果失敗，則會嘗試按照順序嘗試防護方法（由dfs.ha.fencing.methods配置），直到成功為止。只有在這個過程之后，第二個NameNode才會轉換到活動狀態。如果沒有防護方法成功，則第二個NameNode不會轉換為活動狀態，并且會返回錯誤。
-
getServiceState - 確定給定的NameNode是Active還是Standby
連接到提供的NameNode以確定其當前狀態，打印“待機”或“激活”到STDOUT。此子命令可能由cron作業或監視腳本使用，這些腳本需要根據NameNode當前處于活動狀態還是待機狀態而具有不同的行為。
-
getAllServiceState - 返回所有NameNode的狀態
連接到已配置的NameNode以確定當前狀態， 向STDOUT打印“待機”或“激活”。
-
checkHealth - 檢查給定NameNode的健康狀況
連接到提供的NameNode以檢查其健康狀況。NameNode能夠對自身執行一些診斷，包括檢查內部服務是否按預期運行。如果NameNode健康，該命令將返回0，否則返回非零值。有人可能會將此命令用于監視目的。
注意：這還沒有實現，并且目前將始終返回成功，除非給定的NameNode完全關閉。
自動故障轉移
介紹
以上各節介紹如何配置手動故障轉移。在該模式下，即使主動節點發生故障，系統也不會自動觸發從活動節點到備用節點的故障轉移。本節介紹如何配置和部署自動故障轉移。
組件
自動故障轉移為HDFS部署添加了兩個新組件：一個ZooKeeper 仲裁和ZKFailoverController進程（縮寫為ZKFC）。
Apache ZooKeeper是一種高度可用的服務，它使用少量的協調數據，通知客戶端數據發生變化，并監視客戶端的故障。自動HDFS故障轉移的實現依賴ZooKeeper進行以下操作：
失敗檢測 - 集群中的每個NameNode機器都在ZooKeeper中維護一個持久會話。如果機器崩潰，ZooKeeper會話將過期，并通知其他NameNode應該觸發故障轉移。
活動NameNode選舉 - ZooKeeper提供了一種簡單的機制來獨占選擇節點為活動狀態。如果當前活動的NameNode崩潰，另一個節點可能會在ZooKeeper中使用一個特殊的獨占鎖，表明它應該成為下一個活動。
ZKFailoverController（ZKFC）是一個新的組件，它是一個ZooKeeper客戶端，它也監視和管理NameNode的狀態。每個運行NameNode的機器也運行一個ZKFC，ZKFC負責：
健康監控 - ZKFC定期使用健康檢查命令對其本地NameNode執行ping操作。只要NameNode及時響應并具有健康狀態，ZKFC就認為節點健康。如果節點崩潰，凍結或以其他方式進入不健康狀態，則健康監視器會將其標記為不健康。
ZooKeeper會話管理 - 當本地NameNode健康時，ZKFC在ZooKeeper中保持會話打開狀態。如果本地NameNode處于活動狀態，則它還包含一個特殊的“鎖”znode。該鎖使用ZooKeeper對“臨時”節點的支持; 如果會話過期，鎖定節點將被自動刪除。
基于ZooKeeper的選舉 - 如果本地NameNode健康，并且ZKFC發現當前沒有其他節點持有鎖定znode，它將自己嘗試獲取鎖定。如果成功，則它“贏得選舉”，并負責運行故障轉移以使其本地NameNode處于活動狀態。故障切換過程與上述手動故障切換類似：首先，如果必要，先前的活動將被隔離，然后本地NameNode轉換為活動狀態。
有關自動故障轉移設計的更多詳細信息，請參閱Apache HDFS JIRA上HDFS-2185附帶的設計文檔。
部署ZooKeeper
在典型的部署中，ZooKeeper守護進程被配置為在三個或五個節點上運行。由于ZooKeeper本身具有輕量資源需求，因此可以在與HDFS NameNode和Standby節點相同的硬件上配置ZooKeeper節點。許多運營商選擇在與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后綴來配置這些設置。例如，在啟用了聯合的群集中，您可以通過設置<tt>dfs.ha.automatic-failover.enabled.my-nameservice-id</tt>為其中一個名稱服務顯式啟用自動故障轉移。
還可以設置其他幾個配置參數來控制自動故障轉移的行為; 然而，對于大多數安裝來說它們并不是必需的 有關詳細信息，請參閱配置密鑰特定文檔。
在ZooKeeper中初始化HA狀態
添加配置密鑰后，下一步是在ZooKeeper中初始化所需的狀態。您可以通過從其中一個NameNode主機運行以下命令來完成此操作。
[hdfs]$ $HADOOP_PREFIX/bin/hdfs zkfc -formatZK
這將在自動故障轉移系統存儲其數據的ZooKeeper中創建一個znode。
用<tt>start-dfs.sh</tt>啟動集群
由于配置中啟用了自動故障轉移功能，因此<tt>start-dfs.sh</tt>腳本將自動在任何運行NameNode的計算機上啟動ZKFC守護程序。當ZKFC啟動時，他們將自動選擇一個NameNode變為活動狀態。
手動啟動集群
如果您手動管理群集上的服務，則需要在運行NameNode的每臺機器上手動啟動<tt>zkfc</tt>守護進程。您可以運行以下命令來啟動守護進程：
[hdfs]$ $HADOOP_PREFIX/sbin/hadoop-daemon.sh --script $HADOOP_PREFIX/bin/hdfs start zkfc
安全訪問ZooKeeper
如果您正在運行安全集群，您可能需要確保存儲在ZooKeeper中的信息也是安全的。這可以防止惡意客戶修改ZooKeeper中的元數據或者可能觸發錯誤的故障轉移。
為了保護ZooKeeper中的信息，首先將以下內容添加到<tt>core-site.xml</tt>文件中：
<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>
請注意這些值中的'@'字符 - 它指定配置不是內聯的，而是指向磁盤上的文件。
第一個配置的文件指定了ZK CLI使用的相同格式的ZooKeeper認證列表。例如，您可以指定如下所示的內容：
digest:hdfs-zkfcs:mypassword
...其中<tt>hdfs-zkfcs</tt>是ZooKeeper的唯一用戶名，<tt>mypassword</tt>是用作密碼的一些唯一字符串。
接下來，使用類似下面的命令生成與此驗證對應的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=
將' - >'字符串后面的輸出部分復制并粘貼到文件<tt>zk-acls.txt中</tt>，并以字符串“ digest： ” 作為前綴。例如：
digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda
為了使這些ACL生效，您應該重新運行<tt>zkfc -formatZK</tt>命令，如上所述。
這樣做后，您可以按如下方式驗證ZK CLI的ACL：
[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa
驗證自動故障轉移
一旦設置了自動故障轉移，您應該測試其操作。為此，首先找到活動的NameNode。您可以通過訪問NameNode Web界面來確定哪個節點處于活動狀態 - 每個節點都會在頁面頂部報告其HA狀態。
找到活動的NameNode后，可能會在該節點上導致失敗。例如，可以使用 kill -9 <pid of NN> 來模擬JVM崩潰。或者，您可以重新啟動機器或拔下其網絡接口以模擬其他類型的中斷。觸發您希望測試的中斷后，另一個NameNode應在幾秒鐘內自動激活。檢測故障并觸發故障切換所需的時間取決于<tt>ha.zookeeper.session-timeout.ms</tt>的配置，但默認為5秒。
如果測試不成功，則可能是配置錯誤。檢查<tt>zkfc</tt>守護進程以及NameNode守護進程的日志，以便進一步診斷問題。
自動故障轉移常見問題
-
我以任何特定順序啟動ZKFC和NameNode守護進程是否很重要？
不需要。在任何給定節點上，您可以在其相應的NameNode之前或之后啟動ZKFC。
-
我應該進行哪些額外的監測？
您應該在運行NameNode的每臺主機上添加監視，以確保ZKFC保持運行。例如，在某些類型的ZooKeeper故障中，ZKFC可能意外退出，應該重新啟動以確保系統已準備好進行自動故障轉移。
此外，您應該監視ZooKeeper法定人數中的每個服務器。如果ZooKeeper崩潰，則自動故障轉移將不起作用。
-
如果ZooKeeper出現故障會發生什么？
如果ZooKeeper群集崩潰，則不會觸發自動故障轉移。但是，HDFS將繼續運行，沒有任何影響。當ZooKeeper重新啟動時，HDFS將不會重新連接。
-
我可以將我的NameNode中的一個指定為主/首選嗎？
目前，這不支持。NameNode首先啟動的任何一個都將變為活動狀態。您可以選擇以特定順序啟動群集，以便首選節點首先啟動。
-
如何在配置自動故障轉移時啟動手動故障轉移？
即使配置了自動故障切換，也可以使用相同的<tt>hdfs haadmin</tt>命令啟動手動故障切換。它將執行協調的故障轉移。
已啟用HA的HDFS升級/終結/回滾
在HDFS版本之間移動時，有時可以簡單地安裝新軟件并重新啟動集群。然而，有時候，升級正在運行的HDFS版本可能需要更改磁盤上的數據。在這種情況下，安裝新軟件后必須使用HDFS升級/終結/回滾功能。在高可用性環境中，這個過程變得更加復雜，因為NN依賴的磁盤上元數據按照定義分布在對中的兩個HA NN上，并且在使用QJM的情況下在JournalNodes上共享編輯存儲。本文檔部分描述在HA設置中使用HDFS升級/終結/回滾功能的過程。
要執行HA升級，操作員必須執行以下操作：
照常關閉所有NN，然后安裝較新的軟件。
啟動所有的JN。請注意，這是至關重要的，所有的JNS執行升級，回滾或完成操作時運行。如果任何JN在運行這些操作時都處于關閉狀態，則操作將失敗。
用<tt>'-upgrade'</tt>標志啟動一個<tt>NN</tt>。
在開始時，這個NN不會像往常一樣在HA設置中進入待機狀態。相反，此NN將立即進入活動狀態，執行其本地存儲目錄的升級，并執行共享編輯日志的升級。
此時，HA對中的其他NN將與升級的NN不同步。為了使其恢復同步并且再次具有高度可用的設置，您應該通過使用<tt>'-bootstrapStandby'</tt>標志運行NN來重新引導此NameNode 。用<tt>'-upgrade'</tt>標志啟動第二個NN是錯誤的。
請注意，如果您在任何時候想要在完成或回滾升級之前重新啟動NameNodes，則應該照常啟動NN，即不需要任何特殊的啟動標志。
要完成高可用性升級，運營商將在神經網絡運行時使用<tt>`hdfs dfsadmin -finalizeUpgrade'</tt>命令，并且其中一個是活動的。發生這種情況時的活動NN將執行共享日志的終結，而本地存儲目錄包含以前FS狀態的NN將刪除其本地狀態。
要執行升級的回滾，應首先關閉兩個NN。運營商應在NN發起升級程序的NN上運行回滾命令，該命令將在那里執行本地dir的回滾以及共享日志（NFS或JN）上的回滾。之后，這個NN應該啟動，操作員應該在另一個NN上運行<tt>`-bootstrapStandby'</tt>，以使這兩個NN與這個回退的文件系統狀態同步。
