1、HA產生背景
在企業中，大多數公司都是採用cdh來部署集羣，對於hadoop集羣都是採用的完全分佈式方式。在hadoop集羣中肯定會有NN（Name Node）節點和SNN（Secondary Name Node）節點，而真正提供集羣服務的則是NN節點，SNN節點會將NN的fsimage和editlog拷貝，然後合併成fsimage.ckpt。而且要說明的是:正常情況下，SNN會做一小時的備份。假如出現以下情況：
SNN在10點備份了NN的metadata,在10:30是NN出現故障（1、metadata出現損壞；2、某塊物理磁盤掛了。。。），無法恢復自己的元數據，需要通過SNN最新的備份數據進行恢復，這時只能恢復到10點及之前的數據，10點到10:30的元數據就丟了。所以便出現了單點故障問題single point of failure (SPOF)，那麼如如解決SPOF問題呢，HA便應運而生了。
Prior to Hadoop 2.0.0, the NameNode was a single point of failure (SPOF) in an HDFS cluster. Each cluster had a single NameNode, and if that machine or process became unavailable, the cluster as a whole would be unavailable until the NameNode was either restarted or brought up on a separate machine.
This impacted the total availability of the HDFS cluster in two major ways:
In the case of an unplanned event such as a machine crash, the cluster would be unavailable until an operator restarted the NameNode.
Planned maintenance events such as software or hardware upgrades on the NameNode machine would result in windows of cluster downtime.
The HDFS High Availability feature addresses the above problems by providing the option of running two (and as of 3.0.0 more than two) redundant NameNodes in the same cluster in an Active/Passive configuration with a hot standby. This allows a fast failover to a new NameNode in the case that a machine crashes, or a graceful administrator-initiated failover for the purpose of planned maintenance.
在Hadoop 2.0.0之前，NameNode是HDFS集羣中的單點故障（SPOF）。每個羣集只有一個NameNode，如果該機器或進程出現不可用，則整個羣集將不可用，直到NameNode重新啓動或在特定的機器上啓動。
這從兩個方面影響了HDFS羣集的總可用性：
在發生意外事件（例如機器崩潰）的情況下，集羣將不可用，直到執行重新啓動NameNode操作。
計劃的維護事件，例如NameNode機器上的軟件或硬件升級，將導致羣集停機時間的延長。
HDFS高可用性功能通過提供以下選項來解決上述問題：在具有熱備用的主動/被動配置中，可以在同一羣集中運行兩個（自3.0.0起，超過兩個）冗餘NameNode。這樣可以在機器崩潰的情況下快速故障轉移到新的NameNode，或者出於計劃維護的目的由管理員發起的正常故障轉移。
2、HA是什麼
HDFS HA主要提供了兩個NN節點，一個處於Active狀態，一個處於Stangby狀態。那麼與NN和SNN區別是什麼呢？簡單來說：
NN ：老大 SNN：老二
NN（Active）：孿生兄弟一 NN（StandBy）：孿生兄弟二
無部署HA情況下，NN節點掛了，就不能對外繼續提供讀寫服務了，所以需要兩個NN，當Active NN掛了，StandBy NN實時替換轉爲Active狀態，繼續對外提供服務，那麼對於外界來說，是無感知的，達到了平滑過渡的目的。
3、HA架構
1、Active NN:
接收client的rpc請求，同時自己的editlog文件寫一條記錄，也會同時向JN集羣共享存儲上寫一條。也同時接收DN的hearbeat 、blockreport、block location updates.
2、StandBy NN:
同時會接受到從JN集羣的這條記錄，使自己的NN的元數據和active NN的元數據一致(重演)，說白了就是 active nn的一個實時熱備份，一旦被切換爲active狀態，就能夠立即馬上對外提供服務。也同時接收DN的hearbeat blockreporBt block location updates.
3、jn Journal node:
用於active standby nn的同步數據的，本身由JN節點組成的集羣，至少3臺 2n+1 保證高可用
運行JournalNode的機器上，JournalNode守護程序相對較輕，因此可以合理地將這些守護程序與其他Hadoop守護程序（例如NameNode，JobTracker或YARN ResourceManager）並置在機器上。注意：必須至少有3個JournalNode守護程序，因爲必須將編輯日誌修改寫入大多數JN中。這將允許系統容忍單個機器的故障。您可能還會運行3個以上的JournalNode，但是爲了實際增加系統可以容忍的故障數量，您應該運行奇數個JN（即3、5、7等）。請注意，當與N個JournalNode一起運行時，系統最多可以容忍（N-1）/ 2個故障，並繼續正常運行。
4、ZooKeeper：
自動故障轉移爲HDFS部署添加了兩個新組件：ZooKeeper仲裁和ZKFailoverController進程（縮寫爲ZKFC）。
Apache ZooKeeper是一項高可用性服務，用於維護少量協調數據，將數據中的更改通知客戶端並監視客戶端的故障。HDFS自動故障轉移的實現依賴ZooKeeper進行以下操作：
1）故障檢測 -羣集中的每個NameNode計算機都在ZooKeeper中維護一個持久會話。如果計算機崩潰，則ZooKeeper會話將終止，通知其他NameNode應該觸發故障轉移。
2）活動的NameNode選舉 -ZooKeeper提供了一種簡單的機制來專門選舉一個節點爲活動的節點。如果當前活動的NameNode崩潰，則另一個節點可能會在ZooKeeper中採取特殊的排他鎖，指示它應成爲下一個活動的NameNode。
5、ZKFC:
監控NN的健康狀態；向ZK集羣定期發送心跳，讓自己被選舉上，當被ZK選舉爲主 active角色的時候，zkfc進程通過rpc調用 ，讓nn狀態轉換爲active狀態。ZKFailoverController（ZKFC）是一個新組件，它是一個ZooKeeper客戶端，還可以監視和管理NameNode的狀態。運行NameNode的每臺機器還運行ZKFC，該ZKFC負責：
1）運行狀況監視
ZKFC使用運行狀況檢查命令定期ping通其本地NameNode。只要NameNode以健康狀態及時響應，ZKFC就會認爲該節點健康。如果該節點已崩潰，凍結或以其他方式進入不正常狀態，則運行狀況監視器將其標記爲不正常。
2）ZooKeeper會話管理
當本地NameNode運行狀況良好時，ZKFC會在ZooKeeper中保持打開的會話。如果本地NameNode處於活動狀態，則它還將持有一個特殊的“鎖定” znode。該鎖使用ZooKeeper對“臨時”節點的支持。如果會話到期，則鎖定節點將被自動刪除。
3）基於ZooKeeper的選舉
如果本地NameNode運行狀況良好，並且ZKFC看到當前沒有其他節點持有鎖znode，則它本身將嘗試獲取該鎖。如果成功，則它“贏得了選舉”，並負責運行故障轉移以使其本地NameNode處於活動狀態。故障轉移過程類似於上述的手動故障轉移：首先，如有必要，將先前的活動節點圍起來，然後將本地NameNode轉換爲活動狀態。
一般企業中大多使用兩個NN，當然也可以配置多個，但是：
Note: The minimum number of NameNodes for HA is two, but you can configure more. Its suggested to not exceed 5 - with a recommended 3 NameNodes - due to communication overheads
