HDFS 高可用性

設定總覽

與聯合設定類似，HA 設定具有向後相容性，並允許現有的單一 NameNode 設定在不變更的情況下運作。新設定的設計方式，讓叢集中的所有節點都能具有相同的設定，而不需要根據節點類型將不同的設定檔部署到不同的電腦。

與 HDFS 聯合類似，HA 集群重複使用 名稱服務 ID 來識別實際上可能包含多個 HA NameNode 的單一 HDFS 執行個體。此外，HA 中會新增一個稱為 NameNode ID 的新抽象。叢集中每個不同的 NameNode 都會有一個不同的 NameNode ID，以資區分。為了支援所有 NameNode 的單一設定檔，相關設定參數會加上 名稱服務 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] - 名稱服務中每個 NameNode 的唯一識別碼

  使用逗號分隔的 NameNode ID 清單進行組態。DataNode 會使用這個清單來確定叢集中的所有 NameNode。例如，如果您先前使用「mycluster」作為名稱服務 ID，並希望使用「nn1」、「nn2」和「nn3」作為 NameNode 的個別 ID，您會這樣進行組態

  <property>
    <name>dfs.ha.namenodes.mycluster</name>
    <value>nn1,nn2,nn3</value>
  </property>
  

  注意：HA 的 NameNode 最少數目為兩個，但您可以組態更多。建議不要超過 5 個（建議為 3 個 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>
  <property>
    <name>dfs.namenode.rpc-address.mycluster.nn3</name>
    <value>machine3.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:9870</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.mycluster.nn2</name>
    <value>machine2.example.com:9870</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.mycluster.nn3</name>
    <value>machine3.example.com:9870</value>
  </property>
  

  注意：如果您已啟用 Hadoop 的安全性功能，您還應為每個 NameNode 類似地設定 https-address。

• dfs.namenode.shared.edits.dir - 共用儲存目錄的位置

  這是組態備用 NameNode 用來隨時掌握 Active NameNode 進行的所有檔案系統變更的遠端共用編輯目錄路徑的地方。您應只組態這些目錄中的其中一個。這個目錄應在 NameNode 電腦上掛載為 r/w。這個設定的值應為 NameNode 電腦上這個目錄的絕對路徑。例如

  <property>
    <name>dfs.namenode.shared.edits.dir</name>
    <value>file:///mnt/filer1/dfs/ha-name-dir-shared</value>
  </property>
  

• dfs.client.failover.proxy.provider.[nameservice ID] - HDFS 用戶端用來連絡 Active NameNode 的 Java 類別

  設定 Java 類別的名稱，DFS Client 將使用此名稱來判斷哪個 NameNode 是目前的 Active，因此哪個 NameNode 目前正在處理客戶端要求。Hadoop 目前附帶的兩個實作是 ConfiguredFailoverProxyProvider 和 RequestHedgingProxyProvider（對於第一次呼叫，同時呼叫所有名稱節點以判斷哪個是 active，而在後續要求中，呼叫 active 名稱節點，直到發生故障轉移），因此請使用其中一個，除非您使用自訂代理程式提供者。

  <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 類別清單

  系統正確性的關鍵在於任何時間只有一個 NameNode 處於 Active 狀態。因此，在故障轉移期間，我們首先確保 Active NameNode 處於備用狀態，或程序已終止，然後再將另一個 NameNode 轉移到 Active 狀態。為此，您必須設定至少一個隔離方法。這些方法設定為以換行符號分隔的清單，將按順序嘗試，直到其中一個表示隔離已成功。Hadoop 附帶兩種方法：shell 和 sshfence。有關實作您自己的自訂隔離方法的資訊，請參閱 org.apache.hadoop.ha.NodeFencer 類別。

  ---

  sshfence - SSH 到 Active NameNode 並終止程序

  sshfence 選項會 SSH 到目標節點，並使用 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 組態變數的環境中執行，其中「_」字元會取代組態金鑰中的所有「.」字元。已使用的組態已將所有特定於名稱節點的組態提升至其一般形式，例如，dfs_namenode_rpc-address 會包含目標節點的 RPC 位址，即使組態可能將該變數指定為 dfs.namenode.rpc-address.ns1.nn1。

  此外，下列變數也可用於要圍起來的目標節點

  $target_host	要圍起來的節點主機名稱
  $target_port	要圍起來的節點 IPC 埠
  $target_address	上述兩個，組合為 host:port
  $target_nameserviceid	要圍起來的 NN 的名稱服務 ID
  $target_namenodeid	要圍起來的 NN 的名稱節點 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 在幾秒內終止其父 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.ha.nn.not-become-active-in-safemode - 如果防止安全模式名稱節點變為 active

  是否允許名稱節點在安全模式下變為 active，如果設定為 true，則安全模式下的名稱節點會在自動故障轉移開啟時向 ZKFC 回報 SERVICE_UNHEALTHY，或在自動故障轉移關閉時擲回例外，以使轉換為 active 失敗。例如

  <property>
    <name>dfs.ha.nn.not-become-active-in-safemode</name>
    <value>true</value>
  </property>
  

部署詳細資料

設定所有必要的組態選項後，必須先同步兩個 HA 名稱節點的磁碟上元資料。

• 如果您正在設定新的 HDFS 群集，您應先在其中一個名稱節點上執行格式化指令（hdfs namenode -format）。

• 如果您已格式化名稱節點，或正在將非啟用 HA 的群集轉換為啟用 HA，您現在應透過在未格式化名稱節點上執行指令「hdfs namenode -bootstrapStandby」，將名稱節點元資料目錄的內容複製到另一個未格式化名稱節點。執行此指令也會確保共用編輯目錄（由 dfs.namenode.shared.edits.dir 組態）包含足夠的編輯交易，以便啟動兩個名稱節點。

• 如果您要將非 HA NameNode 轉換為 HA，您應該執行「hdfs -initializeSharedEdits」指令，這會初始化共用編輯目錄，並使用來自本機 NameNode 編輯目錄的編輯資料。

此時，您可以像正常啟動 NameNode 一樣，啟動所有 HA NameNode。

您可以瀏覽到 NameNode 的已設定 HTTP 位址，分別造訪每個 NameNode 的網頁。您應該會注意到，在已設定的位址旁邊會顯示 NameNode 的 HA 狀態（「備用」或「作用中」）。每當 HA NameNode 啟動時，它最初會處於備用狀態。

管理指令

現在您的 HA NameNode 已設定並啟動，您將可以存取一些額外的指令來管理您的 HA HDFS 群集。具體來說，您應該熟悉「hdfs haadmin」指令的所有子指令。在沒有任何其他引數的情況下執行此指令，將顯示下列使用資訊

Usage: DFSHAAdmin [-ns <nameserviceId>]
    [-transitionToActive <serviceId>]
    [-transitionToStandby <serviceId>]
    [-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
    [-getServiceState <serviceId>]
    [-getAllServiceState]
    [-checkHealth <serviceId>]
    [-help <command>]

本指南說明了這些子指令的各個層級用途。如需每個子指令的特定使用資訊，您應該執行「hdfs haadmin -help <command>」。

• transitionToActive 和 transitionToStandby - 將指定 NameNode 的狀態轉換為作用中或備用

  這些子指令分別使指定的 NameNode 轉換到作用中或備用狀態。這些指令不會嘗試執行任何圍欄，因此很少使用。相反地，人們幾乎總是偏好使用「hdfs haadmin -failover」子指令。

• failover - 在兩個 NameNode 之間啟動故障轉移

  此子指令會導致從第一個提供的 NameNode 故障轉移到第二個。如果第一個 NameNode 處於備用狀態，此指令只會將第二個轉換到作用中狀態，而不會出現錯誤。如果第一個 NameNode 處於作用中狀態，將嘗試優雅地將它轉換到備用狀態。如果失敗，將按順序嘗試圍欄方法（由 dfs.ha.fencing.methods 設定），直到其中一個成功為止。只有在這個程序之後，第二個 NameNode 才會轉換到作用中狀態。如果沒有圍欄方法成功，第二個 NameNode 將不會轉換到作用中狀態，並且會傳回錯誤。

• getServiceState - 確定指定的 NameNode 是作用中還是備用

  連線到提供的 NameNode 以確定其目前狀態，並適當地將「備用」或「作用中」列印到 STDOUT。此子指令可用於 cron 工作或監控腳本，這些腳本需要根據 NameNode 目前是作用中還是備用而有不同的行為。

• getAllServiceState - 傳回所有 NameNode 的狀態

  連線到已設定的 NameNode 以確定目前狀態，並適當地將「備用」或「作用中」列印到 STDOUT。

• checkHealth - 檢查指定 NameNode 的健康狀態

  連線至提供的 NameNode 以檢查其狀態。NameNode 能夠對自身執行一些診斷，包括檢查內部服務是否如預期般執行。如果 NameNode 狀態正常，此命令會傳回 0，否則會傳回非零值。可以將此命令用於監控目的。

  注意：此功能尚未實作，目前會一直傳回成功，除非指定的 NameNode 已完全停機。

簡介

以上各節說明如何設定手動故障轉移。在該模式中，即使主節點已故障，系統也不會自動從主 NameNode 觸發故障轉移至備用 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 會定期使用健康檢查指令 ping 其本機 NameNode。只要 NameNode 能及時回應健康狀態，ZKFC 就會認為該節點是健康的。如果節點已崩潰、凍結或進入其他不健康狀態，健康監控器將會將其標記為不健康。

• ZooKeeper 會話管理 - 當本機 NameNode 健康時，ZKFC 會在 ZooKeeper 中保持一個開啟的會話。如果本機 NameNode 處於活動狀態，它還會持有特殊的「鎖定」znode。此鎖定使用 ZooKeeper 對「臨時」節點的支持；如果會話過期，鎖定節點將會自動刪除。

• 基於 ZooKeeper 的選舉 - 如果本機 NameNode 健康，且 ZKFC 看到目前沒有其他節點持有鎖定 znode，它本身會嘗試取得鎖定。如果成功，則表示它「贏得選舉」，並負責執行故障轉移，使其本機 NameNode 處於活動狀態。故障轉移程序類似於上述手動故障轉移：首先，如果需要，會將先前的活動節點圍起來，然後本機 NameNode 轉移到活動狀態。

如需有關自動故障轉移設計的更多詳細資訊，請參閱附加到 Apache HDFS JIRA 上 HDFS-2185 的設計文件。

部署 ZooKeeper

在典型的部署中，ZooKeeper 程式會設定在三個或五個節點上執行。由於 ZooKeeper 本身對資源需求較低，因此可以將 ZooKeeper 節點與 HDFS NameNode 和備用節點配置在相同的硬體上。許多操作員會選擇將第三個 ZooKeeper 程序部署在與 YARN ResourceManager 相同的節點上。建議將 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 來針對每個名稱服務設定。例如，在已啟用聯合的群集中，您可以透過設定 dfs.ha.automatic-failover.enabled.my-nameservice-id 來明確地只為其中一個名稱服務啟用自動故障轉移。

還有幾個其他設定參數可以設定來控制自動故障轉移的行為；但是，大多數安裝並不需要這些參數。請參閱設定金鑰特定文件以取得詳細資訊。

在 ZooKeeper 中初始化 HA 狀態

加入組態金鑰後，下一步是在 ZooKeeper 中初始化必要的狀態。您可以從其中一台 NameNode 主機執行下列指令來執行此動作。

[hdfs]$ $HADOOP_HOME/bin/zkfc -formatZK

這會在 ZooKeeper 中建立一個 znode，自動故障轉移系統會將其資料儲存在其中。

使用 start-dfs.sh 啟動叢集

由於已在組態中啟用自動故障轉移，因此 start-dfs.sh 指令碼現在會自動在執行 NameNode 的任何機器上啟動 ZKFC 程式。當 ZKFC 啟動時，它們會自動選取其中一個 NameNode 成為 active。

手動啟動叢集

如果您手動管理叢集上的服務，則需要在執行 NameNode 的每台機器上，手動啟動 zkfc 程式。您可以透過執行以下指令來啟動程式

[hdfs]$ $HADOOP_HOME/bin/hdfs --daemon 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>

請注意這些值中的「@」字元，這表示組態不是內嵌的，而是指向磁碟上的檔案。驗證資訊也可以透過 CredentialProvider 讀取（請參閱 hadoop-common 專案中的 CredentialProviderAPI 指南）。

第一個已組態的檔案會指定 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 網路介面來判斷哪個節點是活動的，每個節點都會在頁面頂端報告其 HA 狀態。

在找出活動的 NameNode 後，您可以在該節點上造成故障。例如，您可以使用 kill -9 <pid of NN> 來模擬 JVM 崩潰。或者，您可以循環電源或拔除其網路介面來模擬不同類型的中斷。在觸發您想要測試的中斷後，另一個 NameNode 應該會在幾秒鐘內自動變為活動狀態。偵測故障並觸發故障轉移所需的時間取決於 ha.zookeeper.session-timeout.ms 的設定，但預設為 5 秒。

如果測試沒有成功，您可能設定錯誤。請查看 zkfc 程式和 NameNode 程式的記錄，以進一步診斷問題。