HDFS概述（5）————HDFS HA

HA With QJM

目標

本指南概述了HDFS高可用性（HA）功能以及如何使用Quorum Journal Manager（QJM）功能配置和管理HA HDFS集群。

本文檔假設讀者對HDFS集群中的一般組件和節點類型有一般的了解。有關詳細信息，請參閱HDFS架構指南。

本指南討論如何使用Quorum Journal Manager（QJM）配置和使用HDFS HA，以在Active和Standby NameNodes之間共享編輯日志

?

背景

在Hadoop 2.0.0之前，NameNode是HDFS集群中的單點故障（SPOF）。每個集群都有一個NameNode，如果該機器或進程變得不可用，則整個集群將不可用，直到NameNode重新啟動或在單獨的計算機上啟動。

這兩個方面影響了HDFS集群的總體可用性：

　　在計算機事件（例如機器崩潰）的情況下，集群將不可用，直到操作員重新啟動NameNode。

　　NameNode機器上的計劃維護事件（如軟件或硬件升級）將導致集群停機時間的窗口。

HDFS高可用性功能通過提供在具有熱備用的主動/被動配置中的同一集群中運行兩個冗余名稱節點來解決上述問題。這允許在機器崩潰的情況下快速故障切換到新的NameNode，或者為了計劃維護而對管理員啟動的優化優雅轉換。

?

架構

在典型的HA集群中，將兩臺獨立的計算機配置為NameNodes。在任何時間點，其中一個NameNodes處于活動狀態，另一個處于待機狀態。Active NameNode負責集群中的所有客戶端操作，而Standby僅作為從站，維護足夠的狀態以在必要時提供快速故障轉移。

為了使備用節點保持與Active節點同步的狀態，兩個節點都與一組名為“JournalNodes”（JN）的獨立守護程序進行通信。當Active節點執行任何命名空間修改時，它可以將修改的記錄持久記錄到大多數這些JN。備用節點能夠讀取JN的編輯，并且不斷地觀察它們對編輯日志的更改。當待機節點看到編輯時，它將它們應用于自己的命名空間。在故障切換的情況下，待機將確保它已經讀取了JounalNodes的所有編輯，然后再將其自身升級到Active狀態。這將確保名稱空間狀態在發生故障轉移之前完全同步。

為了提供快速故障切換，還需要備用節點具有有關集群中塊的位置的最新信息。為了實現這一點，DataNodes配置有兩個NameNodes的位置，并向兩者發送塊位置信息和心跳。

對于HA群集的正確操作至關重要，因此一次只能有一個NameNodes處于活動狀態。否則，命名空間狀態將在兩者之間快速分離，冒著數據丟失或其他不正確的結果。為了確保這種屬性并防止所謂的“腦裂”，JournalNodes將只允許一個NameNode作為一個作者。在故障切換期間，要變為活動狀態的NameNode將簡單地接管寫入JournalNodes的角色，這將有效地防止其他NameNode繼續處于活動狀態，允許新的Active安全地進行故障轉移。

?

硬件資源

為了部署HA群集，您應該準備以下內容：

　　NameNode機器 - 運行Active和Standby NameNodes的機器應具有彼此的等效硬件，以及與非HA集群中使用的硬件相同的硬件。

　　JournalNode機器 - 運行JournalNodes的機器。JournalNode守護進程是相對輕量級的，因此這些守護進程可能會合理地與其他Hadoop守護程序（例如NameNodes，JobTracker或YARN ResourceManager）并置在機器上。注意：必須至少有3個JournalNode守護程序，因為編輯日志修改必須寫入大多數JN。這將允許系統容忍單個機器的故障。您也可以運行超過3個JournalNodes，但為了實際增加系統可以忍受的故障次數，您應該運行奇數JN（即3，5，7等）。請注意，當使用N JournalNodes運行時，系統最多可以忍受（N-1）/ 2故障，并繼續正常工作

請注意，在HA群集中，Standby NameNode還執行命名空間狀態的檢查點，因此不需要在HA群集中運行Secondary NameNode，CheckpointNode或BackupNode。其實這樣做會是一個錯誤。這還允許正在重新配置不支持HA的HDFS集群的HA被啟用以重新使用先前專用于Secondary NameNode的硬件。

?

部署

配置概述

與聯邦配置類似，HA配置向后兼容，并允許現有的單個NameNode配置工作，無需更改。新配置被設計為使得集群中的所有節點可以具有相同的配置，而不需要基于節點的類型將不同的配置文件部署到不同的機器。

像HDFS聯盟一樣，HA集群重新使用名稱服務ID來標識單個HDFS實例，其實際上可能由多個HA名稱節點組成。另外，一個稱為NameNode ID的新抽象與HA一起添加。群集中的每個不同的NameNode具有不同的NameNode ID來區分它。為了支持所有NameNodes的單個配置文件，相關配置參數后綴名稱服務ID以及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]? ?名稱服務中每個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 ?　　標識NameNodes ?JN組進程將寫/讀EditLog的URI

這是一個配置提供共享編輯存儲的JournalNodes的地址，由Active nameNode寫入并由Standby NameNode讀取，以保持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，因此除非您使用自定義的。例如：

<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處于活動狀態。重要的是，當使用Quorum Journal Manager時，只有一個NameNode將被允許寫入JournalNodes，所以不存在從裂腦場景中破壞文件系統元數據的可能性。但是，當發生故障切換時，以前的Active NameNode可能會向客戶端提供讀取請求，這可能是過期的，直到該NameNode在嘗試寫入JournalNodes時關閉。因此，即使使用Quorum Journal Manager，仍然需要配置一些防護方法。但是，為了提高系統在防護機制發生故障時的可用性，建議配置防護方法，保證將其作為列表中最后的防護方法返回成功。請注意，如果您選擇不使用實際的防護方法，您仍然必須為此設置配置一些東西，例如“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>

　　　　'（'and'）'之間的字符串直接傳遞給bash shell，可能不包括任何關閉括號。

　　　　shell命令將運行，環境設置為包含所有當前的Hadoop配置變量，'_'字符替換任何'。'。配置鍵中的字符。所使用的配置已經具有提升為其通用形式的任何特定于Namenode的配置 - 例如，dfs_namenode_rpc-address將包含目標節點的RPC地址，即使配置可以將該變量指定為dfs.namenode.rpc-address。ns1.nn1。

　　　　另外，還可以使用下列變量來指定要圍欄的目標節點：

$target_host	hostname of the node to be fenced
$target_port	IPC port of the node to be fenced
$target_address	the above two, combined as host:port
$target_nameserviceid	the nameservice ID of the NN to be fenced
$target_namenodeid	the namenode ID of the NN 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的退出代碼，則確定擊劍是成功的。如果返回任何其他退出代碼，則擊劍不成功，并且將嘗試列表中的下一個擊劍方法。
注意：此防護方法不會執行任何超時。如果超時是必要的，它們應該在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守護程序將存儲其本地狀態的路徑

這是日志節點計算機上絕對路徑，其中JN將使用編輯和其他本地狀態。您只能使用單一路徑進行此配置。通過運行多個獨立的JournalNodes或通過在本地連接的RAID陣列上配置此目錄來提供此數據的冗余。例如：

<property><name>dfs.journalnode.edits.dir</name><value>/path/to/journal/node/local/data</value>
</property>

?

部署細節

//TODO：

?

?

?

HA With NFS

目標

本指南概述了HDFS高可用性（HA）功能，以及如何配置和管理HA HDFS集群，使用NFS作為NameNodes所需的共享存儲。

本文檔假設讀者對HDFS集群中的一般組件和節點類型有一般的了解。有關詳細信息，請參閱HDFS架構指南。

架構

在典型的HA集群中，將兩臺獨立的計算機配置為NameNodes。在任何時間點，其中一個NameNodes處于活動狀態，另一個處于待機狀態。Active NameNode負責集群中的所有客戶端操作，而Standby僅作為從站，維護足夠的狀態以在必要時提供快速故障轉移。

為了使備用節點將其狀態與Active節點保持同步，當前實現要求兩個節點都可以訪問共享存儲設備上的目錄（例如，從NAS安裝NFS）。這種限制在將來的版本中可能會放寬。

當Active節點執行任何命名空間修改時，它可以將修改的記錄持久記錄到共享目錄中存儲的編輯日志文件中。待機節點一直在觀看此目錄以進行編輯，并且當它看到編輯時，它將其應用于其自己的命名空間。在故障切換的情況下，待機將確保已經從共享存儲中讀取所有編輯，然后再將其自身升級到活動狀態。這將確保名稱空間狀態在發生故障轉移之前完全同步。

為了提供快速故障切換，還需要備用節點具有有關集群中塊的位置的最新信息。為了實現這一點，DataNodes配置有兩個NameNodes的位置，并向兩者發送塊位置信息和心跳

對于HA群集的正確操作至關重要，因此一次只能有一個NameNodes處于活動狀態。否則，命名空間狀態將在兩者之間快速分離，冒著數據丟失或其他不正確的結果。為了確保這種屬性并防止所謂的“腦裂”，JournalNodes將只允許一個NameNode作為一個作者。在故障切換期間，要變為活動狀態的NameNode將簡單地接管寫入JournalNodes的角色，這將有效地防止其他NameNode繼續處于活動狀態，允許新的Active安全地進行故障轉移。

?

硬件資源

為了部署HA群集，您應該準備以下內容：

　　NameNode機器 - 運行Active和Standby NameNodes的機器應具有彼此的等效硬件，以及與非HA集群中使用的硬件相同的硬件。

　　共享存儲 - 您將需要一個共享目錄，這兩個NameNode機器可以具有讀/寫訪問權限。通常這是一個遠程文件管理器，它支持NFS并安裝在每個NameNode機器上。目前只支持單個共享編輯目錄。因此，系統的可用性受到該共享編輯目錄的可用性的限制，因此為了刪除共享編輯目錄需要冗余的所有單個故障點。具體來說，存儲的多個網絡路徑，以及存儲本身的冗余（磁盤，網絡和電源）。扼殺這一點，建議共享存儲服務器是高品質的專用NAS設備，而不是一個簡單的Linux服務器。

請注意，在HA群集中，Standby NameNode還執行命名空間狀態的檢查點，因此不需要在HA群集中運行Secondary NameNode，CheckpointNode或BackupNode。其實這樣做會是一個錯誤。這還允許正在重新配置不支持HA的HDFS集群的HA被啟用以重新使用先前專用于Secondary NameNode的硬件。

?