HDFS2.X提出的HA和Federation分別對應解決兩個問題
–解決單點故障
HDFS HA：通過主備NameNode解決，當主NameNode出現故障時，快速切換到備NameNode上。
–解決記憶體受限
HDFS Federation（聯邦），多個NameNode水平擴充套件，每一個分管一部分目錄，所有的NameNode共享所有DataNode儲存資源。

一、先說記憶體受限問題，這裡主要講的是元資料過大引起的記憶體受限，所以我們的第一反應就是加記憶體，但是，機器的可加記憶體是有上限的，所以行不通。那麼加機器呢？也不行，因為一個HDFS叢集只允許有一個NameNode節點。但是，通過加機器這個思路，我們想到了“加叢集”這個思路，即：多個HDFS叢集共同分擔資源，這就是HDFS Federation的思想。

二、對於單點故障問題，下圖是官網給出的HDFS2.X中HA的架構圖：

使用兩個NameNode：NN Active（活的）和NN Standby（死的），NameNode的兩個主要功能：獲取客戶端的讀寫服務和儲存元資料。而Active同時有這兩個功能，Stanby的唯一區別就是不接受客戶端的讀寫請求。當Active發生故障時，要立刻用Standby來接替工作，所以對於Standby的要求就是，要與Active的狀態（元資料）保持實時的一致，這樣它才能夠立刻接替，為了達到這一目的，該架構圖展示的策略如下：
1、對於fsimage，這個元資料檔案是在格式化時產生的，而在不同的機器中格式化的結果肯定不同，因為格式化是根據當前的系統環境來初始化fsimage的。所以，只需要在Active NN中格式化，之後將產生的fsimage檔案複製到Standby NN中即可，此時兩者的初始元資料一致。
2、元資料中的另一個重要檔案edits，用來實時合併更新fsimage，這個檔案需要從Active中提取出來儲存到JN叢集中，使得Active和Standby共享，以免Active故障時，Standby找不到edits從而無法進行最後一輪（從上一次更新時到發生故障時）的更新。更新合併的過程都是在JN叢集中完成的，兩者分別從JN叢集中取回合併後的fsimage檔案。（有些類似SecondaryNameNode的功能）
3、啟動時，DataNode會同時向Active和Standby彙報Block位置資訊

所以，整體的流程為：Active格式化後會在磁碟中產生fsimage檔案，將其複製到Standby的磁碟中，兩個NN在啟動時將分別從各自的磁碟中載入fsimage檔案到記憶體，這是元資料第一階段一致；在各個DataNode啟動後會同時向Active和Standby的記憶體中的元資料彙報Block的位置資訊，這是元資料第二階段一致；之後間隔一定的時間，Active和Standby會同時通過JN中的edits檔案更新一次fsimage檔案，這是元資料的第三階段一致。
當Active故障時，立刻開啟Standby的獲取客戶端讀寫服務的功能，並依舊按照之前的間隔從JN中更新fsimage，這樣以來，Standby平滑的接替了Active的工作。解決了HDFS1.X的單點故障問題。

至於Active NN與Standby NN，是通過Zookeeper叢集的選舉機制確定的。
每一個NN對應一個FailoverController,通過遠端命令切換NN的狀態，並對NN進行健康檢查，向Zookeeper彙報，若Active NN故障，則Zookeeper在其餘的Standby NN中選舉出一個新的Active NN。