在Hadoop 2.0.0之前，一個HDFS集群中只有一個單一的NameNode，如果NameNode所在的節點宕機了或者因服務器軟件升級導致NameNode進程不可用，則將導致整個集群無法訪問，直到NameNode被重新啟動。
HDFS高可用性（HDFS High Availability）解決了上述問題，它提供了一個選項，可以在同一個集群中運行兩個NameNode，其中一個處於活動狀態，另一個處於備用狀態。當活動狀態的NameNode崩潰時，HDFS集群可以快速切換到備用的NameNode，這樣也就實現了故障轉移功能。
為了使備用節點保持與活動節點同步的狀態，兩個節點都與一組稱為“日志節點”(JournalNodes)的獨立守護進程通信。當活動狀態的NameNode的命名空間有任何修改時，會告知大部分的JournalNodes進程。備份狀態的NameNode有能力讀取JournalNodes中的變更信息，並且一直監控edit log的變化，把變化應用於自己的命名空間。
本例中，各節點的角色分配如下表所示：
| 節點 | 角色 |
|---|---|
| centos01 | NameNode DataNode JournalNode |
| centos02 | NameNode DataNode JournalNode |
| centos03 | DataNode JournalNode |
配置之前最好將三個節點的$HADOOP_HOME/etc/hadoop文件夾與$HADOOP_HOME/tmp文件夾備份一下。備份命令如下：
[hadoop@centos01 etc]$ cp -r hadoop/ backup-hadoop
[hadoop@centos01 hadoop-2.7.1]$ cp -r tmp/ backup-tmp
注意：本例配置的總體思路是，先在centos01節點上配置完畢之后，再將改動的配置文件發送到centos02、centos03節點上。
6.1 hdfs-site.xml文件配置
要配置HA NameNodes，必須向hdfs-site.xml文件添加一些配置選項，設置這些配置的順序並不重要，但是需要為選項dfs.nameservice和dfs. namenodes (nameservice ID)設置一個值，這個值將被后面的選項所引用。因此，在設置其他配置選項之前，應該先設置這些值。
向hdfs-site.xml文件加入以下內容（在之前配置的基礎上追加）：
<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 ：
sbin/hadoop-daemon.sh start journalnode
（2）在centos01節點上執行namenode格式化，如果沒有啟動JournalNode，格式化將失敗。
bin/hdfs namenode -format
出現如下輸出代表格式化成功：
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
原創文章，轉載請注明出處！！