第6章 HDFS HA配置

時間  2020-05-08
標籤 hdfs 配置 欄目 Hadoop 简体版
原文   原文鏈接

[TOC] 在Hadoop 2.0.0以前，一個HDFS集羣中只有一個單一的NameNode，若是NameNode所在的節點宕機了或者因服務器軟件升級致使NameNode進程不可用，則將致使整個集羣沒法訪問，直到NameNode被從新啓動。 HDFS高可用性（HDFS High Availability）解決了上述問題，它提供了一個選項，能夠在同一個集羣中運行兩個NameNode，其中一個處於活動狀態，另外一個處於備用狀態。當活動狀態的NameNode崩潰時，HDFS集羣能夠快速切換到備用的NameNode，這樣也就實現了故障轉移功能。node

爲了使備用節點保持與活動節點同步的狀態，兩個節點都與一組稱爲「日誌節點」(JournalNodes)的獨立守護進程通訊。當活動狀態的NameNode的命名空間有任何修改時，會告知大部分的JournalNodes進程。備份狀態的NameNode有能力讀取JournalNodes中的變動信息，而且一直監控edit log的變化，把變化應用於本身的命名空間。 本例中，各節點的角色分配以下表所示：apache

節點 角色
centos01 NameNode DataNode JournalNode
centos02 NameNode DataNode JournalNode
centos03 DataNode JournalNode

配置以前最好將三個節點的$HADOOP_HOME/etc/hadoop文件夾與$HADOOP_HOME/tmp文件夾備份一下。備份命令以下：bootstrap

[hadoop@centos01 etc]$ cp -r hadoop/ backup-hadoop
[hadoop@centos01 hadoop-2.7.1]$ cp -r tmp/ backup-tmp

注意：本例配置的整體思路是，先在centos01節點上配置完畢以後，再將改動的配置文件發送到centos0二、centos03節點上。 #6.1 hdfs-site.xml文件配置 要配置HA NameNodes，必須向hdfs-site.xml文件添加一些配置選項，設置這些配置的順序並不重要，可是須要爲選項dfs.nameservice和dfs. namenodes (nameservice ID)設置一個值，這個值將被後面的選項所引用。所以，在設置其餘配置選項以前，應該先設置這些值。 向hdfs-site.xml文件加入如下內容（在以前配置的基礎上追加）：centos

<property>
  <name>dfs.nameservices</name>
  <value>mycluster</value><!--mycluster爲自定義的值，下方配置要使用該值-->
</property>
<property>
  <name>dfs.ha.namenodes.mycluster</name>
  <value>nn1,nn2</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn1</name>
  <value>centos01:8020</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn2</name>
  <value>centos02:8020</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn1</name>
  <value>centos01:50070</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn2</name>
  <value>centos02:50070</value>
</property>
<property>
  <name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://centos01:8485;centos02:8485;centos03:8485/mycluster</value>
</property>
<property>
  <name>dfs.journalnode.edits.dir</name>
  <value>/opt/modules/hadoop-2.7.1/tmp/dfs/jn</value>
</property>
<property>
  <name>dfs.client.failover.proxy.provider.mycluster</name>
 <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
 <property>
      <name>dfs.ha.fencing.methods</name>
      <value>sshfence</value>
    </property>
    <property>
      <name>dfs.ha.fencing.ssh.private-key-files</name>
      <value>/home/hadoop/.ssh/id_rsa</value><!--hadoop爲當前用戶名-->
</property>

上述參數解析以下： dfs.nameservices：爲nameservice設置一個邏輯名稱ID（nameservice ID），名稱ID能夠自定義，例如mycluster。並使用這個邏輯名稱ID做爲配置選項的值。後續配置選項將引用該ID。 dfs.ha.namenodes.mycluster：nameservice中每一個NameNode的惟一標識符。選項值是一個以逗號分隔的NameNode id列表。這將被DataNodes用於肯定集羣中的全部NameNodes。例如，本例中使用「mycluster」做爲nameservice ID，而且使用「nn1」和「nn2」做爲NameNodes的單個ID。須要注意的是，當前每一個nameservice只能配置最多兩個NameNodes。 dfs.namenode.rpc-address.mycluster.nn1：設置NameNode的RPC監聽地址，須要設置NameNode進程的完整地址和RPC端口。 dfs.namenode.rpc-address.mycluster.nn2：設置另外一個NameNode的RPC監聽地址，須要設置NameNode進程的完整地址和RPC端口。 dfs.namenode.http-address.mycluster.nn1：設置NameNode的HTTP Web端監聽地址，相似於上面的RPC地址，能夠經過瀏覽器端訪問NameNode。 dfs.namenode.http-address.mycluster.nn2：設置另外一個NameNode的HTTP Web端監聽地址，相似於上面的RPC地址，能夠經過瀏覽器端訪問NameNode。 dfs.namenode.shared.edits.dir：設置一組 JournalNode 的 URI 地址，活動狀態的NameNode將 edit log 寫入這些JournalNode，而備份狀態的 NameNode 則讀取這些 edit log，並做用在內存的目錄樹中。若是JournalNode有多個節點則使用分號分割。該屬性值應符合如下格式：qjournal://host1:port1;host2:port2;host3:port3/nameservice ID。 dfs.journalnode.edits.dir: JournalNode所在節點上的一個目錄，用於存放 edit log和其餘狀態信息。 dfs.client.failover.proxy.provider.mycluster：客戶端與活動狀態的NameNode 進行交互的 Java 實現類，DFS 客戶端經過該類尋找當前的活動NameNode。目前Hadoop的惟一實現是ConfiguredFailoverProxyProvider類，除非咱們本身對其定製，不然應該使用這個類。 dfs.ha.fencing.methods：解決HA集羣腦裂問題（即出現兩個 master 同時對外提供服務，致使系統處於不一致狀態）。在 HDFS HA中，JournalNode只容許一個 NameNode 寫數據，不會出現兩個活動NameNode 的問題，可是，當主備切換時，以前的 活動 NameNode 可能仍在處理客戶端的 RPC 請求，爲此，須要增長隔離機制（fencing）將以前的活動NameNode 殺死。經常使用的fence方法是sshfence，使用ssh須要指定ssh通信使用的密鑰文件。 dfs.ha.fencing.ssh.private-key-files：指定上述選項ssh通信使用的密鑰文件在系統中的位置。 #6.2 core-site.xml文件配置 修改core-site.xml文件中的fs.defaultFS屬性值，爲Hadoop客戶端配置默認的訪問路徑，以使用新的支持HA的邏輯URI。將以前配置的hdfs://centos01:9000改成hdfs://mycluster，其中的mycluster爲hdfs-site.xml中定義的nameservice ID值。內容以下：瀏覽器

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

文件hdfs-site.xml與core-site.xml都配置完成後，須要將這兩個文件從新發送到集羣其它的節點中，並覆蓋原來的文件。 進入Hadoop安裝目錄，執行如下命令：服務器

scp etc/hadoop/hdfs-site.xml hadoop@centos02:/opt/modules/hadoop-2.7.1/etc/hadoop/
scp etc/hadoop/hdfs-site.xml hadoop@centos03:/opt/modules/hadoop-2.7.1/etc/hadoop/
scp etc/hadoop/core-site.xml hadoop@centos02:/opt/modules/hadoop-2.7.1/etc/hadoop/  
scp etc/hadoop/core-site.xml hadoop@centos03:/opt/modules/hadoop-2.7.1/etc/hadoop/

#6.3 啓動與測試 HDFS HA配置完成後，下面咱們將集羣啓動，進行測試： （1）刪除各個節點的$HADOOP_HOME/tmp目錄下的全部文件。在各個節點分別執行下面命令，啓動三臺JournalNode ：ssh

sbin/hadoop-daemon.sh start journalnode

（2）在centos01節點上執行namenode格式化，若是沒有啓動JournalNode，格式化將失敗。ide

bin/hdfs namenode -format

出現以下輸出表明格式化成功：oop

18/03/15 14:14:45 INFO common.Storage: Storage directory /opt/modules/hadoop-2.7.1/tmp/dfs/name has been successfully formatted.

（3）在centos01節點上執行以下命令，啓動namenode：測試

sbin/hadoop-daemon.sh start namenode

啓動namenode後會生成images元數據。 （4）在centos02上執行如下命令，將centos01上的NameNode元數據拷貝到centos02上（也能夠直接將centos01上的$HADOOP_HOME/tmp目錄拷貝到centos02上）：

bin/hdfs namenode -bootstrapStandby

輸出如下信息表明拷貝成功：

18/03/15 14:28:01 INFO common.Storage: Storage directory /opt/modules/hadoop-2.7.1/tmp/dfs/name has been successfully formatted.

（5）在centos02上執行如下命令，啓動namenode2（備份的NameNode）：

sbin/hadoop-daemon.sh start namenode

啓動後，在瀏覽器中輸入網址http://centos01:50070 查看namenode1（活動的NameNode）的狀態。namenode1的狀態顯示，以下圖所示。 在瀏覽器中輸入網址http://centos02:50070 查看namenode2的狀態。Namenode2的狀態顯示，以下圖所示。 能夠看到，此時兩個namenode的狀態都爲standby。接下來咱們須要將namenode1的狀態設置爲active。 （6）在centos01上執行以下命令，將namenode1的狀態置爲active：

bin/hdfs haadmin -transitionToActive nn1

上述代碼中，nn1爲hdfs-site.xml中設置的節點centos01上的namenode的ID標識符。 上述代碼執行完畢後，刷新瀏覽器，能夠看到namenode1的狀態已經變爲了active，以下圖所示： （7）從新啓動HDFS 中止HDFS：

sbin/stop-dfs.sh

啓動HDFS：

sbin/start-dfs.sh

（8）重啓之後，NameNode、DataNode等進程都已經啓動了，但兩個NameNode的狀態仍然都爲standby，須要再次執行步驟（6）的命令，將namenode1的狀態置爲active。 （9）在各節點中執行jps命令，查看各節點啓動的Java進程： centos01節點上的Java進程：

[hadoop@centos01 hadoop-2.7.1]$ jps
8996 DataNode
9221 JournalNode
9959 Jps
8877 NameNode

centos02節點上的Java進程：

[hadoop@centos02 hadoop-2.7.1]$ jps
8162 NameNode
8355 JournalNode
8565 Jps
8247 DataNode

centos03節點上的Java進程：

[hadoop@centos03 hadoop-2.7.1]$ jps
7144 DataNode
7256 JournalNode
7371 Jps

（10）上傳一個文件到HDFS，測試HDFS是否正常運行。若一切正常，接下來測試NameNode故障轉移功能，首先將namenode1進程殺掉：

[hadoop@centos01 hadoop-2.7.1]$ jps
8996 DataNode
10452 Jps
9221 JournalNode
8877 NameNode
[hadoop@centos01 hadoop-2.7.1]$ kill -9 8877

而後查看namenode2的狀態，發現仍然是standby，沒有自動切換到active，此時須要手動執行步驟（6）的命令，將namenode2的狀態切換爲active。再次進行HDFS文件系統的測試，發現一切正常。

以上描述瞭如何配置手動故障轉移。在該模式下，即便活動節點失敗，系統也不會自動觸發從active到備用NameNode的故障轉移。這樣手動切換NameNode雖然能解決故障問題，可是仍是比較麻煩，可不能夠自動切換呢？答案是確定的。下一節講解HDFS結合ZooKeeper進行自動故障轉移。 #6.4 結合ZooKeeper進行自動故障轉移 自動故障轉移爲HDFS部署添加了兩個新組件：一個ZooKeeper quorum和ZKFailoverController流程(縮寫爲ZKFC)。 Apache ZooKeeper是一種高度可用的服務，用於維護少許的協調數據，通知客戶數據的變化，並監控客戶的失敗。自動HDFS故障轉移的實現主要依賴於ZooKeeper的以下功能：

*	故障檢測——集羣中的每一個NameNode機器都在ZooKeeper中維護一個持久會話。若是機器崩潰，ZooKeeper會話將過時，通知另外一個NameNode，它將觸發故障轉移。
*	活動的NameNode選舉——ZooKeeper提供了一個簡單的機制來專門選擇一個活動的節點。若是當前活動的NameNode崩潰，另外一個節點可能會在ZooKeeper中使用一個特殊的獨佔鎖，這代表它應該成爲下一個活            動。
*	ZKFailoverController (ZKFC)是一個新的組件，它是一個ZooKeeper客戶端，它也監視和管理NameNode的狀態。每一個運行NameNode的機器都運行一個ZKFC。
*	健康監測——ZKFC以健康檢查命令按期對本地的NameNode進行檢測。只要NameNode能及時地以健康的狀態作出反應，ZKFC就認爲該節點是健康的。若是該節點崩潰、凍結或進入不健康狀態，健康監控器將標記爲不健康狀態。

有關自動故障轉移設計的更多細節，請參考Apache HDFS JIRA上的HDFS-2185的設計文檔。 本例中，各節點的角色分配以下表：

節點 角色
centos01 NameNode DataNode JournalNode ZKFC QuorumPeerMain
centos02 NameNode DataNode JournalNode ZKFC QuorumPeerMain
centos03 DataNode JournalNode QuorumPeerMain

HDFS集成ZooKeeper來實現NameNode的自動故障轉移，操做步驟以下： （1）修改hdfs-site.xml文件，加入如下內容：

<!--開啓自動故障轉移,mycluster爲自定義配置的nameservice ID值-->
	<property>
	   <name>dfs.ha.automatic-failover.enabled.mycluster</name>
	   <value>true</value>
	 </property>

（2）修改core-site.xml文件，加入如下內容，指定ZooKeeper集羣：

<property>
	   <name>ha.zookeeper.quorum</name>
	   <value>centos01:2181,centos02:2181,centos03:2181</value>
	 </property>

（3）發送修改好的hdfs-site.xml、core-site.xml文件到集羣其它節點，覆蓋原來的文件（這一步容易被忽略）。 （4）中止HDFS集羣：

sbin/stop-dfs.sh

（5）啓動ZooKeeper集羣： 分別進入每一個節點的安裝目錄，執行以下命令：

bin/zkServer.sh start

（6）初始化HA在ZooKeeper中的狀態： 在centos01節點上執行以下命令，將在ZooKeeper中建立一個znode，存儲自動故障轉移系統的數據：

bin/hdfs zkfc -formatZK

（7）啓動HDFS集羣：

sbin/start-dfs.sh

（8）因爲咱們是手動管理集羣上的服務，因此須要手動啓動運行NameNode的每一個機器上的zkfc守護進程。分別在centos01和centos02上執行如下命令，啓動zkfc進程（先在哪一個節點上啓動，哪一個節點的namenode狀態就是active）：

sbin/hadoop-daemon.sh start zkfc

(或者執行bin/hdfs start zkfc也能夠，兩種啓動方式。) （9）上傳文件到HDFS進行測試。 在centos01中上傳一個文件，而後中止namenode1，讀取剛纔上傳的文件內容。相關命令及輸出以下：

[hadoop@centos01 hadoop-2.7.1]$ jps
13105 QuorumPeerMain
13523 DataNode
13396 NameNode
13753 JournalNode
13882 DFSZKFailoverController
14045 Jps
[hadoop@centos01 hadoop-2.7.1]$ kill -9 13396
[hadoop@centos01 hadoop-2.7.1]$ jps
13105 QuorumPeerMain
14066 Jps
13523 DataNode
13753 JournalNode
13882 DFSZKFailoverController
[hadoop@centos01 hadoop-2.7.1]$ hdfs dfs -cat /input/*

若是仍能成功讀取文件內容，說明自動故障轉移配置成功。此時咱們在瀏覽器中訪問namenode2，能夠看到namenode2的狀態變爲了active。 查看各節點的Java進程，命令及輸出結果以下：

[hadoop@centos01 hadoop-2.7.1]$ jps
3360 QuorumPeerMain
4080 DFSZKFailoverController
3908 JournalNode
3702 DataNode
4155 Jps
3582 NameNode

[hadoop@centos02 hadoop-2.7.1]$ jps
3815 DFSZKFailoverController
3863 Jps
3480 NameNode
3353 QuorumPeerMain
3657 JournalNode
3563 DataNode

[hadoop@centos03 zookeeper-3.4.9]$ jps
3496 JournalNode
3293 QuorumPeerMain
3390 DataNode
3583 Jps

<font color=red size=5>原創文章，轉載請註明出處！！</font>

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程