淺析SNN，CN,BN,HA,Federation

1、SecondaryNameNode

Secondary NameNode不是NameNode的備份。它的做用是：按期合併fsimage與edits文件，並推送給NameNode，以及輔助恢復NameNode。 
SNN的做用如今（Hadoop2.x）能夠被兩個節點替換CheckpointNode和BackupNode。 
CheckpointNode能夠理解爲與Secondary NameNode的做用一致。 
BackupNode：NameNode的徹底備份。 
配置文件：core-site.xml 
fs.checkpoint.period、fs.checkpoint,size、 
fs.checkpoint.dir、fs.checkpoint.edits.dir

Secondary NameNode按期合併流程，以下圖所示。 

[root@master current]# more VERSION#Mon May 04 15:06:37 CST 2015namespaceID=1967523381clusterID=CID-bdf70043-346a-439b-87de-cee402d13fa4cTime=0storageType=NAME_NODEblockpoolID=BP-510666760-172.23.253.20-1430213820023layoutVersion=-47

VERSION文件保存了HDFS的版本號 
layoutVersion是一個負整數，保存了HDFS的持續化在硬盤上的數據 
結構的格式版本號 
namespaceID是文件系統的惟一標識符，在文件系統初次格式化時生成的。 
cTime此處爲0 
storageType表示此文件夾中保存的是元數據節點的數據結構

NameNode進程死了，而且存放NameNode元數據信息目錄下的數據丟失了，怎麼恢復？

一、刪除SNN存放數據目錄下in_use.lock文件 
二、執行恢復命令hadoop namenode -importCheckpoint 
三、啓動namenode hadoop-daemon.sh start namenode 
四、進行校驗檢查根目錄是否健康hadoop fsck / 
五、查看數據 hadoop fs -lsr / 
至此，NameNode元數據恢復成功。

2、CheckpointNode

CheckpointNode和SecondaryNameNode的做用以及配置徹底相同。 
啓動命令:hdfs namenode -checkpoint

配置文件：core-site.xml 
fs.checkpoint.period、fs.checkpoint,size、 
fs.checkpoint.dir、fs.checkpoint.edits.dir

3、BackupNode

提供了一個真正意義上的備用節點。 
BackupNode在內存中維護了一份從NameNode同步過來的fsimage，同時它還從namenode接收edits文件的日誌流，並把它們持久化硬盤。 
BackupNode在內存中維護與NameNode同樣的Matadata數據。 
啓動命令:hdfs namenode -backup

配置文件：hdfs-site.xml 
dfs.backup.address、dfs.backup.http.address

[root@master current]# hdfs namenode --helpUsage: java NameNode [-backup] | [-checkpoint] | [-format [-clusterid cid ] [-force] [-nonInteractive] ] | [-upgrade] | [-rollback] | [-finalize] | [-importCheckpoint] | [-initializeSharedEdits] | bootstrapStandby] | [-recover [ -force ] ]

4、HDFS HA的自動failover

 
HDFS的HA，指的是在一個集羣中存在兩個NameNode， 分別運行在獨立的物理節點上。在任什麼時候間點， 只有一個NameNodes是處於Active狀態，另外一種是在Standby狀態。

Active NameNode負責全部的客戶端的操做，而Standby NameNode用來同步Active NameNode的狀態信息，以提供快速的故障恢復能力。

爲了保證Active NN與Standby NN節點狀態同步，即元數據保持一致。除了DataNode須要向兩個NN發送block位置信息外，還構建了一組獨立的守護進程」JournalNodes」 ，用來同步FsEdits信息。當Active NN執行任何有關命名空間的修改，它須要持久化到一半以上的JournalNodes上。而Standby NN負責觀察JNs的變化，讀取從Active NN發送過來的FsEdits信息，並更新其內部的命名空間。

一旦Active NN遇到錯誤， Standby NN須要保證從JNs中讀出了所有的 
FsEdits， 而後切換成Active狀態。

在這個圖裏，咱們能夠看出HA的大體架構，其設計上的考慮包括： 
利用共享存儲來在兩個NN間同步edits信息。 
之前的HDFS是share nothing but NN，如今NN又share storage，這樣實際上是轉移了單點故障的位置，但中高端的存儲設備內部都有各類RAID以及冗餘硬件包括電源以及網卡等，比服務器的可靠性仍是略有提升。 
經過NN內部每次元數據變更後的flush操做，加上NFS的close-to-open，數據的一致性獲得了保證。社區如今也試圖把元數據存儲放到BookKeeper上，以去除對共享存儲的依賴， Cloudera也提供了Quorum Journal Manager（QJM）的實現和代碼。 
DataNode同時向兩個NN彙報塊信息。這是讓Standby NN保持集羣最新狀態的必需步驟。 
用於監視和控制NN進程的FailoverController進程，顯然，咱們不能在NN進程內進行心跳等信息同步，最簡單的緣由，一次FullGC就可讓NN掛起 
十幾分鍾，因此，必需要有一個獨立的短小精悍的watchdog來專門負責監控。這也是一個鬆耦合的設計，便於擴展或更改，目前版本里是用ZooKeeper(如下簡稱ZK)來作同步鎖，但用戶能夠方便的把這個ZooKeeper FailoverController(如下簡稱ZKFC)替換爲其餘的HA方案或leader選舉 
方案。 
隔離(Fencing)，防止腦裂，就是保證在任什麼時候候只有一個主NN，包括三個方面： 
共享存儲fencing，確保只有一個NN能夠寫入edits。 
客戶端fencing，確保只有一個NN能夠響應客戶端的請求。 
DataNode fencing，確保只有一個NN能夠向DN下發命令，譬如刪除塊，複製塊等等。

5、HDFS2的Federation

HDFS Federation設計可解決單一命名空間存在的如下幾個問題： 
1 、HDFS集羣擴展性。多個NameNode分管一部分目錄，使得一個集羣能夠擴展到更多節點，再也不像Hadoop1.x中那樣因爲內存的限制制約文件存儲數目。 
二、性能更高效。多個NameNode管理不一樣的數據，且同時對外提供服務，將爲用戶提供更高的讀寫吞吐率。 
三、良好的隔離性。用戶可根據須要將不一樣業務數據交由不一樣NameNode管理，這樣不一樣業務之間影響很小。

由上圖，咱們能夠看到多個NN共用一個集羣裏DN上的存儲資源，每一個NN均可以單獨對外提供服務每一個NN都會定義一個存儲池，有單獨的id，每一個DN都爲全部存儲池提供存儲。 
DN會按照存儲池id向其對應的NN彙報塊信息，同時， DN會向全部NN彙報本地存儲可用資源狀況 
若是須要在客戶端方便的訪問若干個NN上的資源，可使用客戶端掛載表，把不一樣的目錄映射到不一樣的NN，但NN上必須存在相應的目錄。 
這樣設計的好處有： 改動最小，向前兼容。 現有的NN無需任何配置改動。 若是現有的客戶端只連某臺NN的話，代碼和配置也無需改動。 分離命名空間管理和塊存儲管理。 提供良好擴展性的同時容許其餘文件系統或應用直接使用塊存儲池。 統一的塊存儲管理保證了資源利用率。 能夠只經過防火牆配置達到必定的文件訪問隔離，而無需使用複雜的Kerberos認證 客戶端掛載表經過路徑自動對應NN使Federation的配置改動對應用透明。