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的硬件。