Table of Contents

本節概述HDFS高可用性(HA)特性以及如何配置和管理HA HDFS集羣。

HDFS高可用性介紹

背景

在標準配置中，NameNode 是 HDFS 集羣中的單點故障(SPOF)。每個集羣都有一個 NameNode，如果該主機或進程變得不可用，則整個集羣都不可用，直到 NameNode 重新啓動或在新主機上啓動。Secondary NameNode 不提供故障轉移功能。

標準配置通過兩種主要方式減少了HDFS 集羣的總可用性：

在發生意外事件(如主機崩潰)的情況下，在操作員重新啓動 NameNode 之前，集羣是不可用的。
計劃的維護事件(如NameNode機器上的軟件或硬件升級)會導致集羣停機。

HDFS HA 通過提供在同一集羣中以主動/被動配置運行兩個 namenode 的選項來解決上述問題。這些被稱爲活動 NameNode 和備用 NameNode。與備用的 NameNode 不同，備用的 NameNode 是熱備用的，它允許在主機崩潰的情況下快速自動轉移到一個新的 NameNode，或者允許運維發起的用於計劃維護的故障轉移。不能擁有兩個以上的 namenode。

HA實現

Cloudera Manager 5 和 cdh5 支持 Quorum-based 存儲來實現 HA。

Quorum-based存儲

Quorum-based Storage 是指使用 Quorum Journal Manager (QJM) 的 HA 實現。

爲了使備用 NameNode 的狀態與此實現中的活動 NameNode 保持同步，兩個節點都與一組稱爲 JournalNodes 的獨立守護進程通信。當活動的 NameNode 執行任何名稱空間修改時，它會將修改的記錄持久地記錄到大多數日誌節點上。備用的 NameNode 能夠從 JournalNodes 讀取編輯，並不斷監視它們對編輯日誌的更改。當備用節點看到編輯時，它將它們應用到自己的名稱空間。在發生故障轉移時，備用服務器將確保它正常工作。

爲了提供快速的故障轉移，備用 NameNode 還必須具有關於集羣中數據塊的位置的最新信息。爲此，datanode 配置了兩個 namenode 的位置，並將塊位置信息和心跳發送給兩個 namenode。

對於 HA 集羣的正確操作來說，一次只激活一個 namenode 是非常重要的。否則，名稱空間狀態將很快在兩者之間產生分歧，可能導致數據丟失或其他不正確的結果。爲了確保這個屬性並防止所謂的“分裂大腦場景”，JournalNodes 一次只允許一個 NameNode 作爲寫入器。在故障轉移期間，將被激活的 NameNode 簡單地接管了向 JournalNodes 寫入的角色，這有效地阻止了其他 NameNode 繼續處於活動狀態，從而允許新的活動 NameNode 安全的進行故障轉移。

自動故障轉移

自動故障轉移依賴於 HDFS 中的兩個附加組件：ZooKeeper quorum 和 ZKFailoverController 進程(縮寫爲ZKFC)。在 Cloudera Manager 中，ZKFC 進程映射到 HDFS 故障轉移控制器角色。

Apache ZooKeeper是一種高可用性的服務，用於維護少量的協調數據、通知客戶端數據的更改以及監控客戶端故障。HDFS自動故障轉移的實現依賴於ZooKeeper實現以下功能：

故障檢測 —— 集羣中的每個 NameNode 機器都在 ZooKeeper 中維護一個持久會話。如果機器崩潰，ZooKeeper 會話將到期，通知另一個 NameNode 應該觸發故障轉移。
活躍的NameNode選舉 —— ZooKeeper 提供了一個簡單的機制來專門選擇一個活動節點。如果當前活動的 NameNode 崩潰，則另一個節點可以在 ZooKeeper 中獲取一個特殊的獨佔鎖，表明它應該成爲下一個活動的 NameNode。

ZKFailoverController (ZKFC)是一個 ZooKeeper 客戶機，它還監視和管理 NameNode 的狀態。運行 NameNode 的每個主機也運行 ZKFC。ZKFC 負責：

健康監控 —— ZKFC 定期通過健康檢查命令與本機的 NameNode 聯繫。只要 NameNode 以健康狀態迅速響應，ZKFC 就認爲 NameNode 是健康的。如果 NameNode 崩潰、凍結或以其他方式進入不健康狀態，則健康監視器將其標記爲不健康。
Zookeeper會話管理 —— 當本機的 NameNode 是健康的，ZKFC 會在 ZooKeeper 中打開一個會話。如果本機 NameNode 是活動的，它還持有一個特殊的鎖 znode。此鎖使用 ZooKeeper 對“臨時”節點的支持；如果會話過期，鎖節點將被自動刪除。
ZooKeeper-based選舉 —— 如果本機的 NameNode 是健康的，並且 ZKFC 發現當前沒有其他的 NameNode 持有鎖 znode，它將自己嘗試獲取鎖。如果它成功了，那麼它就“贏得了選舉”，並負責運行故障轉移來激活本機 NameNode。故障轉移過程類似於上面描述的手動故障轉移：首先，前一個活動被隔離(如果需要)，然後本地 NameNode 轉換爲活動狀態。

關於HDFS HA的一般問題

“Operation category READ/WRITE is not supported in state standby”是什麼意思?

以下信息來自Apache Hadoop wiki：

在啓用了 ha 的集羣中，DFS 客戶機不能預先知道在給定時間內哪個 NameNode 是活動的。因此，當客戶端連接到 NameNode 並且它恰好是備用服務器時，讀或寫操作將被拒絕，並記錄此消息。然後客戶端將自動聯繫另一個 NameNode 並再次嘗試操作。只要集羣中有一個活動 NameNode 和一個備用 NameNode，就可以安全地忽略該消息。

如果將應用程序配置爲始終只聯繫一個NameNode，則此消息表明應用程序未能執行任何讀/寫操作。在這種情況下，需要修改應用程序以使用集羣的HA配置。

爲HDFS HA配置硬件

要使用 Quorum-based 存儲部署 HA 集羣，您應該準備以下內容：

NameNode 主機——這是運行活動和備用 NameNode 的主機。它們應該具有彼此等價的硬件，以及與非 ha 集羣中使用的硬件等價。
JournalNod e主機——這些是運行 JournalNodes 的主機。Cloudera 建議在“master”主機( NameNode、備用 NameNode、JobTracke r等)上部署 JournalNode 守護進程，這樣，JournalNode 的本地目錄就可以在這些機器上使用可靠的本地存儲。
如果位於同一主機上，則每個 JournalNode 進程和每個 NameNode 進程都應該有自己的專用磁盤。不應該對這些目錄使用 SAN 或 NAS 存儲。
必須至少有三個 JournalNode 守護進程，因爲編輯日誌修改必須寫入到大多數 JournalNode。這將允許系統容忍單個主機的故障。您還可以運行三個以上的 JournalNodes，但是要實際增加系統能夠容忍的故障數量，您應該運行奇數個 JournalNodes( 3、5、7，等等)。注意，當使用 N 個 JournalNodes 運行時，系統最多可以容忍 (N - 1) / 2 個故障，並繼續正常運行。如果所需的 quorum 不可用，NameNode 將不會格式化或啓動，您將看到類似這樣的錯誤：

12/10/01 17:34:18 WARN namenode.FSEditLog: Unable to determine input streams from QJM to [10.0.1.10:8485, 10.0.1.10:8486, 10.0.1.10:8487]. Skipping.
java.io.IOException: Timed out waiting 20000ms for a quorum of nodes to respond.

在HA集羣中，備用的NameNode也執行名稱空間狀態的檢查點，因此不需要在HA集羣中運行備用的NameNode、CheckpointNode或BackupNode。事實上，這樣做是錯誤的。如果將不支持ha的HDFS集羣重新配置爲支持ha，則可以重用以前專用於輔助NameNode的硬件。

開啓HDFS HA

HDFS 高可用性(HA)集羣使用兩個 NameNode —— 一個活動的 NameNode 和一個備用的 NameNode。在任何時間點，只有一個 NameNode 可以被激活。HDFS HA 依賴於在一個對兩個 NameNode 都可用的位置上維護所有名稱空間修改的日誌，以便在發生故障時，備用 NameNode 具有關於集羣中塊的編輯和位置的最新信息。

重要：啓用和禁用HA會導致HDFS服務和所有依賴於HDFS的服務中斷。在啓用或禁用HA之前，請確保集羣上沒有運行作業。

使用 Cloudera 管理器啓用 HDFS HA

您可以使用 Cloudera Manager 爲 HDFS HA 和自動故障轉移配置 cdh5 集羣。在 Cloudera Manager 5 中，HA 是使用 Quorum-based 的存儲來實現的。Quorum-based 的存儲依賴於一組 JournalNodes，每個 JournalNodes 維護一個本地編輯目錄，該目錄記錄對名稱空間元數據的修改。啓用 HA 使自動故障轉移成爲同一命令的一部分。

重要：

啓用或禁用 HA 將導致先前的監控歷史記錄不可用。

一旦啓用了JobTracker HA，一些參數將自動設置如下。如果希望更改這些參數的默認值，請使用高級配置片段。
        mapred.jobtracker.restart.recover: true
        mapred.job.tracker.persist.jobstatus.active: true
        mapred.ha.automatic-failover.enabled: true
        mapred.ha.fencing.methods: shell(true)

啓用高可用性和自動故障轉移

啓用高可用性工作流引導您添加第二個(備用) NameNode 並配置 JournalNodes。

執行在爲HDFS HA配置硬件中描述的所有配置和設置任務。
確保你有一個 ZooKeeper 服務。
轉到 HDFS 服務。
Select Actions > Enable High Availability。顯示有資格運行備用 NameNode 的主機的屏幕，並顯示 JournalNodes。a.爲 nameservice 指定一個名稱，或者接受默認名稱 nameservice1 並單擊 Continue。b.在NameNode Hosts 字段中，單擊 Select a host。將顯示“主機選擇”對話框。c.選中您希望設置備用NameNode的主機旁邊的複選框，然後單擊OK。備用的NameNode不能與活動的NameNode在同一主機上，所選的主機應該與活動的NameNode具有相同的硬件配置(RAM、磁盤空間、內核數量等)。d.在J ournalNode Hosts 字段中，單擊 Select Hosts。將顯示“主機選擇”對話框。e.選中奇數臺主機(至少3臺)旁邊的複選框，作爲 JournalNodes 並單擊 OK。JournalNodes 應該駐留在具有與 namenode 類似的硬件規範的主機上。Cloudera 建議將一個 JournalNode 分別放在與活動和備用 namenode 相同的主機上，而將第三個 JournalNode 放在類似的硬件上，比如 JobTracker。f.單擊 Continue。g.在 JournalNode 編輯目錄屬性中，爲每個 JournalNode 主機的字段輸入 JournalNode 編輯目錄的目錄位置。對於每個 JournalNode 只能輸入一個目錄。在每個 JournalNode 上，路徑不必相同。指定的目錄應該是空的。目錄所有者應該是hdfs:hadoop，並且必須具有讀、寫和執行權限(drwx——)。h.額外選項：決定 Cloudera manager 是否應該清除 ZooKeeper、standby NameNode 和 JournalNodes 中的現有數據。如果目錄不是空的(例如，您正在重新啓用以前的 HA 配置)，Cloudera manager 將不會自動刪除內容—您可以通過保留默認的複選框選擇來選擇刪除內容。推薦的默認設置是清除目錄。如果您選擇不這樣做，那麼數據應該在 JournalNodes 的編輯目錄中保持同步，並且應該具有與 NameNodes 相同的版本數據。i.單擊 Continue。
Cloudera Manager 執行一組命令，這些命令停止依賴的服務，根據需要刪除、創建和配置角色和目錄，創建名稱服務和故障轉移控制器，重新啓動依賴的服務，並部署新的客戶端配置。注意：如果操作已經完成，則格式化NameNode等一些步驟可能會報告失敗。但是，在報告了非關鍵的失敗步驟之後，配置步驟將繼續執行。
如果希望在集羣中使用配置了 HA 的其他服務，請遵循配置其他 CDH 組件以使用 HDFS HA 的過程。

注意：如果在啓用自動故障轉移時更改 NameNode 服務 RPC 端口(dfss . NameNode .servicerpc-address)，將導致ZooKeeper /hadoop-ha znode 中保存的 NameNode 地址與故障轉移控制器配置的 NameNode 地址不匹配。這將防止故障轉移控制器重新啓動。如果在啓用自動故障轉移後需要更改 NameNode 服務 RPC 端口，則必須執行以下操作來重新初始化 znode：
停止HDFS服務。

配置服務RPC端口：a.轉到HDFS服務。b.單擊Configuration選項卡。c.選擇 Scope > NameNode。d.選擇 Category > Ports and Addresses。e.找到NameNode服務RPC端口屬性，或者通過在搜索框中鍵入它的名稱來搜索它。f.根據需要更改端口值。如果有多個角色組應用於此配置，請編輯相應角色組的值。
在Z ooKeeper 服務器主機上運行 ZooKeeper -client。執行以下步驟以刪除已配置的名稱服務。本例假設 nameservice 的名稱是 nameservice1。你可以在 HDFS 實例標籤頁的 Federation and High Availability 部分找到nameservice ：
rmr /hadoop-ha/nameservice1
單擊Instances選項卡。

選擇 Actions > Initialize High Availability State in ZooKeeper。

啓動HDFS服務。

Fencing Methods

爲了確保一次只有一個 NameNode 是活動的，共享編輯目錄需要一個隔離方法。在故障轉移期間，隔離方法負責確保以前的活動 NameNode 不再具有對共享編輯目錄的訪問權限，以便新的活動 NameNode 能夠安全地繼續對其進行寫入。

默認情況下，Cloudera Manager將HDFS配置爲使用 a shell fencing method (shell(true))。

fencing 參數可以在 Service-Wide > High Availability 類別下的HDFS服務配置屬性中找到。

使用命令行啓用HDFS HA

重要：在不使用 Cloudera 管理器的系統上遵循這些命令行說明。此信息特別適用於CDH 5.11.x。

本節描述 cdh5 中 HDFS HA 所需的軟件配置，並解釋如何設置配置屬性和使用命令行部署 HDFS HA。

爲HDFS HA配置軟件

配置概述

HA 配置是向後兼容的，允許現有的單個 NameNode 配置無需更改即可工作。新配置的設計使集羣中的所有節點都可以擁有相同的配置，而不需要根據節點的類型將不同的配置文件部署到不同的機器上。

HA 集羣重用 Nameservice ID 來標識一個可能包含多個 HA namenode 的 HDFS 實例。此外，還有一個名爲 NameNode ID 的新抽象。集羣中每個不同的 NameNode 都有一個不同的 NameNode ID。爲了支持所有 NameNode 的單個配置文件，相關的配置參數包括 Nameservice ID 和 NameNode ID。

更改現有的配置參數

YARN 實現更改了以下配置參數：

fs.defaultFS - 原名 fs.default.name，當沒有指定時，Hadoop FS 客戶端使用的默認路徑前綴。fs.default.name 不支持 YARN，但是仍會工作。

還可以爲 Hadoop 客戶機配置默認路徑，以使用啓用 ha 的邏輯 URI。例如，如果使用 mycluster 作爲如下所示的 Nameservice ID，這將是所有 HDFS 路徑的權限部分的值。您可以在您的 core-site.xml 文件中配置默認路徑：

For YARN:

<property>
  <name>fs.defaultFS</name>
  <value>hdfs://mycluster</value>
</property>

For MRv1:

<property>
  <name>fs.default.name</name>
  <value>hdfs://mycluster</value>
</property>

新的配置參數

要配置 HA namenode，必須將幾個配置選項添加到 hdfs-site.xml 配置文件中。

您設置這些配置的順序並不重要，但是您爲 dfs. namespace 服務和 dfs.ha.namenodes.[Nameservice ID] 選擇的值將決定後面那些配置的鍵。這意味着您應該在設置其他配置選項之前確定這些值。

dfs.nameservices

dfs.nameservices - 此新名稱服務的邏輯名稱

爲這個 nameservice 選擇一個邏輯名，例如mycluster，然後使用這個邏輯名作爲這個配置選項的值。您選擇的名稱是任意的。它將用於配置和作爲集羣中絕對 HDFS 路徑的權威組件。

<property>
  <name>dfs.nameservices</name>
  <value>mycluster</value>
</property>

dfs.ha.namenodes.[nameservice ID]

dfs.ha.namenodes.[nameservice ID] - nameservice 中每個 NameNode 的惟一標識符

配置逗號分隔的 NameNode id 列表。datanode 將使用它來確定集羣中的所有 namenode。例如，如果您以前使用 mycluster 作爲 NameService ID，並且希望使用 nn1 和 nn2 作爲 namenode 的單獨 ID，您可以這樣配置：

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

注意：在這個版本中，每個名稱服務最多可以配置兩個 namenode。

dfs.namenode.rpc-address.[nameservice ID]

dfs.namenode.rpc-address.[nameservice ID].[name node ID] - 要監聽的每個 NameNode 的完全限定 RPC 地址

對於前面配置的兩個 NameNode id，設置 NameNode 進程的完整地址和 RPC 端口。注意，這會導致兩個單獨的配置選項。例如：

<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]

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 Kerberos 安全特性，並且打算使用 HSFTP，那麼還應該爲每個 NameNode 設置類似的 https-address。

dfs.namenode.shared.edits.dir

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

配置提供共享編輯存儲的 JournalNodes 的地址，這些地址由活動 NameNode 寫入，由備用 NameNode 讀取，以便與活動 NameNode 所做的所有文件系統更改保持最新。雖然必須指定幾個 JournalNode 地址，但是應該只配置其中一個 uri。URI 的格式應該是：

qjournal://<host1:port1>;<host2:port2>;<host3:port3>/<journalId>

Journal ID 是此名稱服務的唯一標識符，它允許一組日誌節點爲多個聯合名稱系統提供存儲。雖然這不是必需的，但是最好重用 Nameservice ID 作爲日誌標識符。

例如，如果這個集羣的 JournalNodes 運行在機器 node1.example.com、node2.example.com和node3.example.com 上，而 nameservice 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.journalnode.edits.dir

dfs.journalnode.edits.dir - JournalNode 守護進程將存儲其本地狀態的路徑

在每臺 JournalNode 機器上，配置存儲 JournalNode 使用的編輯和其他本地狀態信息的絕對路徑；每個 JournalNode 只使用一條路徑。(其他的日誌節點提供冗餘；您還可以在本地附加的RAID-1或RAID-10數組上配置此目錄。)

例如：

<property>
  <name>dfs.journalnode.edits.dir</name>
  <value>/data/1/dfs/jn</value>
</property>

現在創建目錄(如果它還不存在)，並確保其所有者是 hdfs，例如：

$ sudo mkdir -p /data/1/dfs/jn
$ sudo chown -R hdfs:hdfs /data/1/dfs/jn

客戶端故障轉移配置

dfs.client.failover.proxy.provider.[nameservice ID] - HDFS客戶端用來聯繫活動 NameNode 的 Java 類

配置 Java 類的名稱，DFS 客戶機將使用它來確定哪個 NameNode 是當前活動的，因此哪個 NameNode 當前正在爲客戶機請求提供服務。目前與 Hadoop 一起提供的唯一實現是 ConfiguredFailoverProxyProvider，所以除非您使用自定義的，否則就使用它。例如：

<property>
  <name>dfs.client.failover.proxy.provider.mycluster</name>
  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

Fencing 配置

dfs.ha.fencing.methods - 將用於在故障轉移期間保護活動 NameNode 的腳本或 Java 類的列表

爲了保證系統的正確性，在任何給定的時間只有一個 NameNode 處於活動狀態。

當您使用 Quorum-based 的存儲時，只允許一個 NameNode 寫入到 JournalNodes，因此在“分裂大腦”場景中不會破壞文件系統元數據。這映射 dfs.ha.fencing.methods 的默認值 true，它不會顯式地嘗試保護備用 NameNode。

在沒有明確的隔離的情況下，有一個很窄的時間窗口，以前活動的 NameNode 可能爲來自客戶機的讀操作提供過時的響應。當先前活動的 NameNode 試圖寫入到 JournalNodes 時，此窗口將結束，此時 NameNode 將關閉。

對於應用程序來說，這種陳舊的讀響應窗口很少成爲問題，因爲不存在分裂大腦損壞的危險。在需要強讀一致性的罕見或特殊情況下，使用顯式擊劍方法，如 agent-based fencer。

注意：如果您選擇使用 agent-based fencing 方法，您仍然應該配置shell(true)作爲備用擊劍選項，因爲如果另一個 NameNode 沒有響應，那麼 agent-based fencing 將失敗。

故障轉移期間使用的 fencing 方法被配置爲一個以載物-返回-分隔的列表，這些方法將按順序嘗試，直到其中一個方法指示 fencing 成功爲止。

有關實現自定義 fencing 方法的信息，請參閱 org.apache.hadoop.ha.NodeFencer 類。
the shell fencing method

shell - 運行任意 shell 命令來保護活動的 NameNode

<property>
  <name>dfs.ha.fencing.methods</name>
  <value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
</property>

'('和')之間的字符串直接傳遞給 bash shell，不能包含任何右括號。

在執行時，配置腳本的第一個參數將是要保護的 NameNode 的地址，然後是配置中指定的所有參數。

shell 命令將在一個環境中運行，該環境設置爲包含所有當前的 Hadoop 配置變量，用“_”字符替換“any”。配置鍵中的字符。所使用的配置已經將任何特定於 namenode 的配置提升爲它們的通用形式—例如，dfs_namenode_rpc-address 將包含目標節點的 RPC 地址，即使配置可能將該變量指定爲 dfs.namenode.rpc-address.ns1.nn1。

下列變量引用的目標節點被隔離也可用：

Variable	Description
$target_host	Hostname of the node to be fenced
$target_port	IPC port of the node to be fenced
$target_address	The above two variables, combined as host:port
$target_nameserviceid	The nameservice ID of the NameNode to be fenced
$target_namenodeid	The NameNode ID of the NameNode to be fenced

您還可以在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，則判斷 fencing 成功。如果返回任何其他退出碼，則說明 fencing 不成功，將嘗試列表中的下一個 fencing 方法。

注意：此隔離方法不實現任何超時。如果需要超時，則應該在 shell 腳本中實現超時(例如，通過分叉子 shell 在幾秒鐘內殺死其父 shell)。

自動故障轉移配置

上述部分描述瞭如何配置手動故障轉移。在這種模式下，即使活動節點失敗，系統也不會自動觸發從活動節點到備用NameNode的故障轉移。本節描述如何配置和部署自動故障轉移。

部署ZooKeeper

在典型的部署中，ZooKeeper 守護進程被配置爲在三個或五個節點上運行。由於 ZooKeeper 本身需要較少的資源，所以可以將 ZooKeeper 節點配置在與 HDFS NameNode 和備用節點相同的硬件上。使用 MapReduce v2 (MRv2)的操作員通常選擇將第三個 ZooKeeper 進程部署在與 YARN 資源管理器相同的節點上。建議將 ZooKeeper 節點配置爲將數據從 HDFS 元數據存儲到單獨的磁盤驅動器上，以獲得最佳性能和隔離性。

在下面的部分中，我們假設您已經設置了一個運行在三個或更多節點上的ZooKeeper集羣，並通過使用ZooKeeper命令行接口(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服務的主機端口對。

與本文檔前面描述的參數一樣，可以在每個 nameservice 的基礎上配置這些設置，方法是用 nameservice ID 作爲配置鍵的後綴。例如，在啓用了聯合的集羣中，您可以通過設置 dfs.ha.automatic-failover.enabled.my-nameservice-id 來顯式地爲其中一個 nameservices 啓用自動故障轉移。

您可以設置其他幾個配置參數來控制自動故障轉移的行爲，但是對於大多數安裝來說，這些參數不是必需的。

在ZooKeeper中初始化HA狀態

添加配置鍵之後，下一步是在ZooKeeper中初始化所需的狀態。可以通過在NameNode主機上運行以下命令來實現這一點。

使用此命令時，ZooKeeper 集合必須正在運行;否則它將不能正常工作。

$ hdfs zkfc -formatZK

這將在 ZooKeeper 中創建一個 znode，自動故障轉移系統將在其中存儲其數據。

確保與 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 身份驗證的列表，格式與 ZooKeeper CLI 使用的格式相同。例如，可以指定如下內容： digest:hdfs-zkfcs:mypassword，其中 hdfs-zkfcs 是 ZooKeeper 的惟一用戶名，而 mypassword 是用作密碼的惟一字符串。

接下來，使用以下命令生成與此身份驗證對應的 ZooKeeper 訪問控制列表(ACL)：

$ 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:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

要使這些 acl 生效，請如上所述重新運行 zkfc -formatZK 命令。

這樣做之後，你可以驗證來自 ZooKeeper CLI 的 acl 如下：

[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa

自動故障轉移常見問題解答

我以特定的順序啓動 ZKFC 和 NameNode 守護進程重要嗎?

不。在任何給定的節點上，您都可以在其相應的 NameNode 之前或之後啓動 ZKFC。

我應該進行哪些額外的監視?

您應該在運行 NameNode 的每個主機上添加監控，以確保 ZKFC 保持運行。例如，在某些類型的 ZooKeeper 故障中，ZKFC 可能會意外退出，應該重新啓動以確保系統準備好進行自動故障轉移。另外，您應該監視 ZooKeeper 集羣中的每個服務器。如果 ZooKeeper 崩潰，自動故障轉移將不起作用。

如果 Zookeeper 宕了怎麼辦?

如果 ZooKeeper 集羣崩潰，則不會觸發自動故障轉移。但是，HDFS 將繼續運行，不會受到任何影響。當 ZooKeeper 重新啓動時，HDFS 將重新連接，沒有問題。

我可以指定一個 NameNode 作爲首選嗎？

不。目前，這是不支持的。首先啓動的 NameNode 將成爲活動的。您可以選擇以特定的順序啓動集羣，以便首選節點首先啓動。

在配置自動故障轉移時，如何啓動手動故障轉移?

即使配置了自動故障轉移，也可以啓動手動故障轉移。它將執行協調的故障轉移。

部署HDFS高可用性

設置完所有必要的配置選項後，就可以啓動 JournalNodes 和兩個 HA namenode了。

重要：啓動之前：確保您已經執行了爲 HDFS HA 配置硬件和爲 HDFS HA 配置軟件中描述的所有配置和設置任務，包括在部署自動故障轉移時在 ZooKeeper 中初始化 HA 狀態。

安裝並啓動JournalNodes

1、在它們將要運行的每臺機器上安裝 JournalNode 守護進程。

To install JournalNode on Red Hat-compatible systems:

$ sudo yum install hadoop-hdfs-journalnode

To install JournalNode on Ubuntu and Debian systems:

$ sudo apt-get install hadoop-hdfs-journalnode

To install JournalNode on SLES systems:

$ sudo zypper install hadoop-hdfs-journalnode

2、在將要運行它們的每臺機器上啓動 JournalNode 守護進程：

sudo service hadoop-hdfs-journalnode start

在格式化主 NameNode (在新的集羣中)和啓動 NameNode (在所有情況下)之前，等待守護進程啓動。

格式化NameNode(如果是新的集羣)

如果要設置一個新的 HDFS 集羣，請格式化將用作主 NameNode 的 NameNode

重要：確保已經啓動了 JournalNodes。如果您將 NameNode 配置爲與 JournalNodes 通信，但尚未啓動 JournalNodes，則格式化將失敗。

初始化共享編輯目錄(如果轉換現有的非ha集羣)

如果要將非 HA NameNode 轉換爲 HA，請使用本地 NameNode 編輯目錄中的編輯數據初始化共享編輯目錄：

hdfs namenode -initializeSharedEdits

啓動 namenode

1、啓動主(格式化)NameNode：

$ sudo service hadoop-hdfs-namenode start

2、啓動備用NameNode：

$ sudo -u hdfs hdfs namenode -bootstrapStandby
$ sudo service hadoop-hdfs-namenode start

注意：如果啓用了 Kerberos，不要使用 sudo -u <user> <command>；它們將由於安全錯誤而失敗。相反，使用以下命令：$ kinit <user> （使用密碼）或 $ kinit -kt <keytab> <principal> （使用keytab）然後，對於該用戶執行的每個命令，$ <command>。

使用 -bootstrapStandby 選項啓動備用 NameNode，將主 NameNode 的元數據目錄(包括 namespace 信息和最近的檢查點)的內容複製到備用 NameNode。(包含 NameNode 元數據的目錄的位置是使用配置選項 dfs.namenode.name.dir 和 dfs. NameNode .edit .dir 來配置的。)

您可以通過瀏覽其配置的 HTTP 地址來訪問每個 NameNode 的 web 頁面。注意，在配置的地址旁邊是 NameNode 的 HA 狀態(“備用”或“活動”)。無論何時 HA NameNode 啓動，且未啓用自動故障轉移，它最初都處於備用狀態。如果啓用了自動故障轉移，則啓動的第一個 NameNode 將成爲活動的。

重新啓動服務(如果正在轉換現有的非ha集羣)

如果您從非 HA 配置轉換爲 HA 配置，則需要重新啓動 JobTracker 和 TaskTracker (對於 MRv1，如果使用)，或 ResourceManager、NodeManager 和 JobHistory Server (對於 YARN)，以及 DataNode：

每個 DataNode 上:

$ sudo service hadoop-hdfs-datanode start

在每個 TaskTracker 系統上(MRv1):

$ sudo service hadoop-0.20-mapreduce-tasktracker start

在每個 TaskTracker 系統上(MRv1):

$ sudo service hadoop-0.20-mapreduce-jobtracker start

確認 JobTracker 和 TaskTracker 啓動正常:

sudo jps | grep Tracker

關於 ResourceManager 系統(YARN):

$ sudo service hadoop-yarn-resourcemanager start

在每個 NodeManager 系統上(YARN;通常與 DataNode 服務運行的地方相同):

$ sudo service hadoop-yarn-nodemanager start

關於 MapReduce JobHistory 服務器系統(YARN):

$ sudo service hadoop-mapreduce-historyserver start

部署自動故障轉移(如果已配置)

如果您已經使用 ZooKeeper 故障轉移控制器( ZKFC )配置了自動故障轉移，則必須在運行 NameNode 的每臺機器上安裝並啓動 ZKFC 守護進程。進行如下。

To install ZKFC on Red Hat-compatible systems:

$ sudo yum install hadoop-hdfs-zkfc

To install ZKFC on Ubuntu and Debian systems:

$ sudo apt-get install hadoop-hdfs-zkfc

To install ZKFC on SLES systems:

$ sudo zypper install hadoop-hdfs-zkfc

To start the zkfc daemon:

$ sudo service hadoop-hdfs-zkfc start

以特定的順序啓動 ZKFC 和 NameNode 守護進程並不重要。在任何給定的節點上，您都可以在其相應的 NameNode 之前或之後啓動 ZKFC。

您應該在運行 NameNode 的每個主機上添加監控，以確保 ZKFC 保持運行。例如，在某些類型的 ZooKeeper 故障中，ZKFC 可能會意外退出，應該重新啓動以確保系統準備好進行自動故障轉移。

另外，您應該監視 ZooKeeper 集羣中的每個服務器。如果 ZooKeeper 崩潰，那麼自動故障轉移將不起作用。如果 ZooKeeper 集羣崩潰，則不會觸發自動故障轉移。但是，HDFS 將繼續運行，不會受到任何影響。當 ZooKeeper 重新啓動時，HDFS 將重新連接，沒有問題。

驗證自動故障轉移

在啓用了自動故障轉移的集羣的初始部署之後，您應該測試它的操作。爲此，首先找到活動的 NameNode。如前所述，您可以通過訪問 NameNode web 接口來判斷哪個節點是活動的。

一旦定位了活動的 NameNode，就可能導致該節點出現故障。例如，您可以使用 kill -9 <pid of NN> 來模擬 JVM 崩潰。或者您可以對計算機或其網絡接口進行電源循環，以模擬不同類型的停機。在觸發要測試的停機之後，另一個 NameNode 應該在幾秒鐘內自動激活。檢測故障和觸發故障轉移所需的時間取決於 ha.zookeeper.session-timeout 的配置。，但默認爲5秒。

如果測試不成功，則可能是配置錯誤。檢查 zkfc 守護進程和 NameNode守護進程的日誌，以進一步診斷問題。

CDH HDFS High Availability（CDH啓用HDFS高可用）5.11.x

HDFS高可用性介紹

背景

HA實現

Quorum-based存儲

自動故障轉移

關於HDFS HA的一般問題

“Operation category READ/WRITE is not supported in state standby”是什麼意思?

爲HDFS HA配置硬件

開啓HDFS HA

使用 Cloudera 管理器啓用 HDFS HA

啓用高可用性和自動故障轉移

Fencing Methods

使用命令行啓用HDFS HA

爲HDFS HA配置軟件

部署HDFS高可用性

Redis數據類型

Hive創建/刪除/截斷表

Flink流處理（Stream API）- State & Fault Tolerance（狀態和容錯）之 The Broadcast State Pattern（廣播狀態模式）

Flink流處理（Stream API）- State & Fault Tolerance（狀態和容錯）之 State Schema Evolution（狀態模式演化）

CDH HDFS High Availability（CDH啓用HDFS高可用）5.11.x

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結