目錄

一、Hadoop  2.0產生背景

二、Hadoop  1.x與Hadoop  2.x

三、HDFS  2.x

四、HDFS  2.0  HA（高可用）

解決方法

五、HDFS  2.x  Federation（聯邦）

---

一、Hadoop  2.0產生背景

–Hadoop 1.0中HDFS和MapReduce在高可用、擴充套件性等方面存在問題

–HDFS存在的問題

•NameNode單點故障，難以應用於線上場景    HA（高可用）

•NameNode壓力過大，且記憶體受限，影擴充套件性   F（聯邦）

–MapReduce存在的問題響系統

•JobTracker訪問壓力大，影響系統擴充套件性

•難以支援除MapReduce之外的計算框架，比如Spark、Storm等

二、Hadoop  1.x與Hadoop  2.x

–Hadoop 2.x由HDFS、MapReduce和YARN三個分支構成；

•HDFS：NN Federation（聯邦）、HA；

–2.X:只支援2個節點HA，3.0實現了一主多從

•MapReduce：執行在YARN上的MR；

–離線計算，基於磁碟I/O計算

•YARN：資源管理系統

三、HDFS  2.x

–解決HDFS 1.0中單點故障和記憶體受限問題。

–解決單點故障

1. •HDFS HA：通過主備NameNode解決
2. •如果主NameNode發生故障，則切換到備NameNode上

–解決記憶體受限問題

1. •HDFS Federation(聯邦)
2. •水平擴充套件，支援多個NameNode；
3. •（2）每個NameNode分管一部分目錄；
4. •（1）所有NameNode共享所有DataNode儲存資源

–2.x僅是架構上發生了變化，使用方式不變

–對HDFS使用者透明

–HDFS 1.x中的命令和API仍可以使用

四、HDFS  2.0  HA（高可用）

1. ZKFC（藍色背景的大圈）：自動故障轉移，jvm程式
2. ZK （藍色背景的小圈）：分散式協調

       ZKFC（與之對應的NN在同一物理作業系統）監控硬體、軟體、NN、作業系統，看其是否還健康。

當叢集第一次開機時有一個NN是Active 另外一個是Standby,那麼誰是Active呢，要看ZK來分散式協調，兩個ZKFC去ZK

中爭搶建立，誰建立上就是Active。

        ZK的事件監聽和回撥，當一個NN1掛掉，對應的ZKFC1知道後去ZK把自己建立的東西刪掉，刪掉這個事件回撥一個事件，在另一個ZKFC把自己對應的NN升為Active

   

       若ZKFC1掛掉，NN1還活著，ZK把對應的節點刪掉，另一個ZKFC會把NN1降為Standby，自己的NN升為Active

 

解決方法

–主備NameNode

–解決單點故障（屬性，位置）

•主NameNode對外提供服務，備NameNode同步主NameNode後設資料，以待切換

•所有DataNode同時向兩個NameNode彙報資料塊資訊（位置）

•JNN:叢集（屬性）

•standby：備，完成了edits.log檔案的合併產生新的image，推送回ANN

–兩種切換選擇

•手動切換：通過命令實現主備之間的切換，可以用HDFS升級等場合

•自動切換：基於Zookeeper實現

–基於Zookeeper自動切換方案

•ZooKeeper Failover Controller：監控NameNode健康狀態，

•並向Zookeeper註冊NameNode

•NameNode掛掉後，ZKFC為NameNode競爭鎖，獲得ZKFC 鎖的NameNode變為active

 

五、HDFS  2.x  Federation（聯邦）

–

–通過多個namenode/namespace把後設資料的儲存和管理分散到多個節點中，使到namenode/namespace可以通過增加機器來進行水平擴充套件。

–能把單個namenode的負載分散到多個節點中，在HDFS資料規模較大的時候不會也降低HDFS的效能。可以通過多個namespace來隔離不同型別的應用，把不同型別應用的HDFS後設資料的儲存和管理分派到不同的namenode中。