一、HDFS的新特性HA

(一)HDFS的HA機制         

Hadoop 2.2.0 版本之前，NameNode是HDFS叢集的單點故障點，每一個叢集只有一個NameNode ，如果這個機器或者程序不可用，整個叢集就無法使用，直到重啟NameNode或者新重啟一個NameNode節點 。

影響HDFS叢集不可用主要包括以下兩種情況。

(1)類似機器跌宕這樣的意外情況將導致叢集不可用，只有重啟NameNode之後才可使用。

(2) 計劃內的軟體或硬體升級（NameNode節點）將導致叢集在短時間範圍內不可用。

HDFS的高可用性（HA ,High Availability）就可以解決上述問題，通過提供選擇執行在同一叢集中的一個熱備用的 "主/備"兩個冗餘NameNode，允許在機器宕機或系統維護的時候，快速轉移到另一個NameNode。

(二)典型的HA叢集

一個典型的HA叢集，兩個單獨的機器配置為NameNodes，在任何時候，一個NameNode處於活動狀態，另一個處於待機狀態，活動的NameNode負責處理叢集中所有客戶端的操作，待機時僅僅作為一個slave，保持足夠的狀態，如果有必要提供一個快速的故障轉移。

為了保持備用節點與活動節點狀態的同步，目前的實現需要兩個節點同時訪問一個共享儲存裝置（例如從NASNFS掛載）到一個目錄。將有可能在未來的版本中放寬此限制。

當活動節點對名稱空間進行任何修改，它將把修改記錄寫到共享目錄下的一個日誌檔案，備用節點會監聽這個目錄，當發現更改時，它會把修改內容同步到自己的名稱空間。備用節點在故障轉移時，它將保證已經讀取了所有共享目錄內的更改記錄，保證在發生故障前的狀態與活動節點保持完全一致。

為了提供快速的故障轉移，必須保證備用節點有最新的叢集中塊的位置資訊，為了達到這一點，Datanode節點需要配置兩個nameNode的位置，同時傳送塊的位置資訊和心跳資訊到兩個nameNode。

任何時候只有一個namenode處於活動狀態，對於HA叢集的操作是至關重要的，否則兩個節點之間的狀態就會產生衝突，資料丟失或其它不正確的結果，為了達到這個目的或者所謂的“裂腦場景”出現，管理員必須為共享儲存配置至少一個（fencing）方法。在宕機期間，如果不能確定之間的活動節點已經放棄活動狀態，fencing程序負責中斷以前的活動節點編輯儲存的共享訪問。這可以防止任何進一步的修改名稱空間，允許新的活動節點安全地進行故障轉移。

(三)HA架構 HA架構解釋如下：

1、只有一個NameNode是Active的，並且只有這個ActiveNameNode能提供服務，改變NameNode。以後可以考慮讓StandbyNameNode提供讀服務。

2、提供手動Failover，在升級過程中，Failover在NameNode-DataNode之間寫不變的情況下才能生效。

3、在之前的NameNode重新恢復之後，不能提供failback。

4、資料一致性比Failover更重要。

5、儘量少用特殊的硬體。

6、HA的設定和Failover都應該保證在兩者操作錯誤或者配置錯誤的時候，不得導致資料損壞。

7、NameNode的短期垃圾回收不應該觸發Failover。

8、DataNode會同時向NameNodeActive和NameNodeStandby彙報塊的資訊。NameNodeActive和NameNodeStandby通過NFS備份MetaData資訊到一個磁碟上面。

(四)為什麼會有HA機制

1、單點故障         

在Hadoop 2.0之前，也有若干技術試圖解決單點故障的問題，我們在這裡做個簡短的總結

A、Secondary NameNode。它不是HA，它只是階段性的合併edits和fsimage，以縮短叢集啟動的時間。當NameNode(以下簡稱NN)失效的時候，Secondary NN並無法立刻提供服務，Secondary NN甚至無法保證資料完整性：如果NN資料丟失的話，在上一次合併後的檔案系統的改動會丟失。

B、Backup NameNode (HADOOP-4539)。它在記憶體中複製了NN的當前狀態，算是Warm Standby，可也就僅限於此，並沒有failover等。它同樣是階段性的做checkpoint，也無法保證資料完整性。

C、手動把name.dir指向NFS。這是安全的Cold Standby，可以保證元資料不丟失，但叢集的恢復則完全靠手動。

D、Facebook AvatarNode。Facebook有強大的運維做後盾，所以Avatarnode只是Hot Standby，並沒有自動切換，當主NN失效的時候，需要管理員確認，然後手動把對外提供服務的虛擬IP對映到Standby NN，這樣做的好處是確保不會發生腦裂的場景。其某些設計思想和Hadoop 2.0裡的HA非常相似，從時間上來看，Hadoop 2.0應該是借鑑了Facebook的做法。

E、還有若干解決方案，基本都是依賴外部的HA機制，譬如DRBD，Linux HA，VMware的FT等等。

2、叢集容量和叢集效能         單NN的架構使得HDFS在叢集擴充套件性和效能上都有潛在的問題，當叢集大到一定程度後，NN程序使用的記憶體可能會達到上百G，常用的估算公式為1G對應1百萬個塊，按預設塊大小計算的話，大概是64T (這個估算比例是有比較大的富裕的，其實，即使是每個檔案只有一個塊，所有元資料資訊也不會有1KB/block)。同時，所有的元資料資訊的讀取和操作都需要與NN進行通訊，譬如客戶端的addBlock、getBlockLocations，還有DataNode的blockRecieved、sendHeartbeat、blockReport，在叢集規模變大後，NN成為了效能的瓶頸。Hadoop 2.0裡的HDFS Federation就是為了解決這兩個問題而開發的。

二、HDFS的新特性Federation (一)單個Namenode的HDFS架構的侷限性 1. Namespace（名稱空間）的限制

由於Namenode在記憶體中儲存所有的元資料（metadata），因此單個Namenode所能儲存的物件（檔案+塊）數目受到Namenode所在JVM的heap size的限制。50G的heap能夠儲存20億（200 million）個物件，這20億個物件支援4000個datanode，12PB的儲存（假設檔案平均大小為40MB）。隨著資料的飛速增長，儲存的需求也隨之增長。單個datanode從4T增長到36T，叢集的尺寸增長到8000個datanode。儲存的需求從12PB增長到大於100PB。

2. 效能的瓶頸

由於是單個Namenode的HDFS架構，因此整個HDFS檔案系統的吞吐量受限於單個Namenode的吞吐量。毫無疑問，這將成為下一代MapReduce的瓶頸。

3. 隔離問題

由於HDFS僅有一個Namenode，無法隔離各個程式，因此HDFS上的一個實驗程式就很有可能影響整個HDFS上執行的程式。那麼在HDFS Federation中，可以用不同的Namespace來隔離不同的使用者應用程式，使得不同Namespace Volume中的程式相互不影響。

4. 叢集的可用性

在只有一個Namenode的HDFS中，此Namenode的宕機無疑會導致整個叢集不可用。

5. Namespace和Block Management的緊密耦合

當前在Namenode中的Namespace和Block Management組合的緊密耦合關係會導致如果想要實現另外一套Namenode方案比較困難，而且也限制了其他想要直接使用塊儲存的應用。

6. 為什麼縱向擴充套件目前的Namenode不可行？比如將Namenode的Heap空間擴大到512GB。

這樣縱向擴充套件帶來的第一個問題就是啟動問題，啟動花費的時間太長。當前具有50GB Heap Namenode的HDFS啟動一次大概需要30分鐘到2小時，那512GB的需要多久？第二個潛在的問題就是Namenode在Full GC時，如果發生錯誤將會導致整個叢集宕機。第三個問題是對大JVM Heap進行除錯比較困難。優化Namenode的記憶體使用價效比比較低。

(二) 為什麼要引入Federation

引入Federation的最主要原因是簡單，其簡單性是與真正的分散式Namenode相比而言的。Federation能夠快速的解決了大部分單Namenode HDFS的問題。

Federation是簡單魯棒的設計，由於聯盟中各個Namenode之間是相互獨立的。Federation整個核心設計實現大概用了3.5個月。大部分改變是在Datanode、Config和Tools，而Namenode本身的改動非常少，這樣Namenode原先的魯棒性不會受到影響。比分散式的Namenode簡單，雖然這種實現的擴充套件性比起真正的分散式的Namenode要小些，但是可以迅速滿足需求。另外一個原因是Federation良好的向後相容性，已有的單Namenode的部署配置不需要任何改變就可以繼續工作。

因此Federation（聯盟）是未來可選的方案之一。在Federation架構中可以無縫的支援目前單Namenode架構中的配置。

(三)HDFS的Federation機制

HDFS Federation使用了多個獨立的Namenode/namespace來使得HDFS的命名服務能夠水平擴充套件。在HDFS Federation中的Namenode之間是聯盟關係，他們之間相互獨立且不需要相互協調。HDFS Federation中的Namenode提供了提供了名稱空間和塊管理功能。HDFS Federation中的datanode被所有的Namenode用作公共儲存塊的地方。每一個datanode都會向所在叢集中所有的Namenode註冊，並且會週期性的傳送心跳和塊資訊報告，同時處理來自Namenode的指令。

(四)Federation HDFS與當前HDFS的比較及改進

當前HDFS只有一個名稱空間（Namespace），它使用全部的塊。而Federation HDFS中有多個獨立的名稱空間（Namespace），並且每一個名稱空間使用一個塊池（block pool）。

當前HDFS中只有一組塊。而Federation HDFS中有多組獨立的塊。塊池（block pool）就是屬於同一個名稱空間的一組塊。

當前HDFS由一個Namenode和一組datanode組成。而Federation HDFS由多個Namenode和一組datanode，每一個datanode會為多個塊池（block pool）儲存塊。

1.Block Pool(塊池)

所謂Block pool(塊池)就是屬於單個名稱空間的一組block(塊)。每一個datanode為所有的block pool儲存塊。Datanode是一個物理概念，而block pool是一個重新將block劃分的邏輯概念。同一個datanode中可以存著屬於多個block pool的多個塊。Block pool允許一個名稱空間在不通知其他名稱空間的情況下為一個新的block建立Block ID。同時，一個Namenode失效不會影響其下的datanode為其他Namenode的服務。當datanode與Namenode建立聯絡並開始會話後自動建立Block pool。每個block都有一個唯一的標識，這個標識我們稱之為擴充套件的塊ID（Extended Block ID）= BlockID+BlockID。這個擴充套件的塊ID在HDFS叢集之間都是唯一的，這為以後叢集歸併創造了條件。

Datanode中的資料結構都通過塊池ID（BlockPoolID）索引，即datanode中的BlockMap，storage等都通過BPID索引。在HDFS中，所有的更新、回滾都是以Namenode和BlockPool為單元發生的。即同一HDFS Federation中不同的Namenode/BlockPool之間沒有什麼關係。Hadoop V0.23版本中Block Pool的管理功能依然放在了Namenode中，將來的版本中會將Block Pool的管理功能移動的新的功能節點中。

2.Datanode的改進

在datanode中，對應於每個Namnode都有一條相應的執行緒。每個datanode會去每一個Namenode註冊，並且週期性的給所有的Namenode傳送心跳及datanode的使用報告。Datanode還會給Namenode傳送其所在的block pool的block report（塊報告）。由於有多個Namenode同時存在，因此任何一個Namenode都可以隨時動態加入、刪除和更新。

3.Federation中的其他方面的改進

提供了工具，對於Namenode的初始化和退役的監控和管理。允許在datanode級別或者block pool級別的負載均衡。Datanode的後臺守護程序，為Federation所做的磁碟和目錄掃描。提供了顯示Namenode的Block pool的使用狀態的Web UI。還提供了對全部叢集儲存使用狀態的UI展示。在Web UI中列出了所有的Namenode及其細節，如Namenode-BlockPoolID和儲存的使用狀態，失去聯絡的、活的和死的塊資訊。還有前往各個Namenode Web UI的連結。Datanode退役狀態的展示。

4.多名稱空間的管理問題

在一個叢集中需要唯一的名稱空間還是多個名稱空間，核心問題名稱空間中資料的共享和訪問的問題。使用全域性唯一的名稱空間是解決資料共享和訪問的一種方法。在多名稱空間下，我們還可以使用Client Side Mount Table方式做到資料共享和訪問。

5.Namespace Volume（名稱空間卷）

一個Namespace和它的Block Pool合在一起稱作Namespace Volume。Namespace Volume是一個獨立完整的管理單元。當一個Namenode/Namespace被刪除，與之相對應的Block Pool也也被刪除。在升級時每一個Namespace Volume也會整體作為一個單元。

6.ClusterID

在HDFS Federation中添加了Cluster ID用來區分叢集中的每個節點。當格式化一個Namenode時，這個ClusterID會自動生成或者手動提供。在格式化同一叢集中其他Namenode時會用到這個ClusterID。

7.HDFS Federation對老版本的HDFS是相容的

這種相容性可以使得已有的Namenode配置不需要任何改變繼續工作。 --------------------- 作者：converoscar 來源：CSDN 原文：https://blog.csdn.net/converoscar/article/details/77666800 版權宣告：本文為博主原創文章，轉載請附上博文連結！