1. HDFS 簡介

HDFS，為Hadoop這個分布式計算框架提供高性能、高可靠、高可擴展的存儲服務(wù)。HDFS的系統(tǒng)架構(gòu)是典型的主/從架構(gòu)，早期的架構(gòu)包括一個主節(jié)點NameNode和多個從節(jié)點DataNode。NameNode是整個文件系統(tǒng)的管理節(jié)點，也是HDFS中最復雜的一個實體，它維護著HDFS文件系統(tǒng)中最重要的兩個關(guān)系：

HDFS文件系統(tǒng)中的文件目錄樹，以及文件的數(shù)據(jù)塊索引，即每個文件對應(yīng)的數(shù)據(jù)塊列表。

數(shù)據(jù)塊和數(shù)據(jù)節(jié)點的對應(yīng)關(guān)系，即某一塊數(shù)據(jù)塊保存在哪些數(shù)據(jù)節(jié)點的信息。

其中，第一個關(guān)系即目錄樹、元數(shù)據(jù)和數(shù)據(jù)塊的索引信息會持久化到物理存儲中，實現(xiàn)是保存在命名空間的鏡像fsimage和編輯日志edits中。而第二個關(guān)系是在NameNode啟動后，有DataNode主動上報它所存儲的數(shù)據(jù)塊，動態(tài)建立對應(yīng)關(guān)系。

在上述關(guān)系的基礎(chǔ)上，NameNode管理著DataNode，通過接收DataNode的注冊、心跳、數(shù)據(jù)塊提交等信息的上報，并且在心跳中發(fā)送數(shù)據(jù)塊復制、刪除、恢復等指令;同時，NameNode還為客戶端對文件系統(tǒng)目錄樹的操作和對文件數(shù)據(jù)讀寫、對HDFS系統(tǒng)進行管理提供支持。

DataNode提供真實文件數(shù)據(jù)的存儲服務(wù)。它以數(shù)據(jù)塊的方式在本地的Linux文件系統(tǒng)上保存了HDFS文件的內(nèi)容，并且對外提供文件數(shù)據(jù)的訪問功能。客戶端在讀寫文件時，必須通過NameNode提供的信息，進一步和DataNode進行交互;同時，DataNode還必須接NameNode的管理，執(zhí)行NameNode的指令，并且上報NameNode感興趣的事件，以保證文件系統(tǒng)穩(wěn)定，可靠，高效的運行。架構(gòu)圖如下：

在HDFS集群中NameNode存在單點故障(SPOF)。對于只有一個NameNode的集群，如果NameNode機器出現(xiàn)故障，那么整個集群將無法使用，直到NameNode重新啟動。

NameNode主要在以下兩個方面影響HDFS集群:

NameNode機器發(fā)生意外，比如宕機，集群將無法使用，直到管理員重啟NameNode

NameNode機器需要升級，包括軟件、硬件升級，此時集群也將無法使用

HDFS的HA功能通過配置Active/Standby兩個NameNodes實現(xiàn)在集群中對NameNode的熱備來解決上述問題。如果出現(xiàn)故障，如機器崩潰或機器需要升級維護，這時可通過此種方式將NameNode很快的切換到另外一臺機器。

2. HA基礎(chǔ)

HDFS HA的解決方案可謂百花齊放，Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等等。目前普遍采用的是shared NAS+NFS，因為簡單易用，但是需要提供一個HA的共享存儲設(shè)備。而社區(qū)已經(jīng)把基于QJM/Quorum Journal Manager的方案merge到trunk了，clouderea提供的發(fā)行版中也包含了這個feature，這種方案也是社區(qū)在未來發(fā)行版中默認的 HA方案。

在HA具體實現(xiàn)方法不同的情況下，HA框架的流程是一致的。不一致的就是如何存儲和管理日志。在Active NN和Standby NN之間要有個共享的存儲日志的地方，Active NN把EditLog寫到這個共享的存儲日志的地方，Standby NN去讀取日志然后執(zhí)行，這樣Active和Standby NN內(nèi)存中的HDFS元數(shù)據(jù)保持著同步。一旦發(fā)生主從切換Standby NN可以盡快接管Active NN的工作(雖然要經(jīng)歷一小段時間讓原來Standby追上原來的Active，但是時間很短)。

說到這個共享的存儲日志的地方，目前采用最多的就是用共享存儲NAS+NFS。缺點有：1)這個存儲設(shè)備要求是HA的，不能down;2)主從切換時需要 fencing方法讓原來的Active不再寫EditLog，否則的話會發(fā)生brain-split，因為如果不阻止原來的Active停止向共享存儲寫EditLog，那么就有兩個Active NN了，這樣就會破壞HDFS的元數(shù)據(jù)了。對于防止brain-split問題，在QJM出現(xiàn)之前，常見的方法就是在發(fā)生主從切換的時候，把共享存儲上存放EditLog的文件夾對原來的Active的寫權(quán)限拿掉，那么就可以保證同時至多只有一個Active NN，防止了破壞HDFS元數(shù)據(jù)。

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

Secondary NameNode。它不是HA，它只是階段性的合并edits和fsimage，以縮短集群啟動的時間。當NameNode(以下簡稱NN)失效的時候，Secondary NN并無法立刻提供服務(wù)，Secondary NN甚至無法保證數(shù)據(jù)完整性：如果NN數(shù)據(jù)丟失的話，在上一次合并后的文件系統(tǒng)的改動會丟失。

Backup NameNode (HADOOP-4539)。它在內(nèi)存中復制了NN的當前狀態(tài)，算是Warm Standby，可也就僅限于此，并沒有failover等。它同樣是階段性的做checkpoint，也無法保證數(shù)據(jù)完整性。

手動把name.dir指向NFS。這是安全的Cold Standby，可以保證元數(shù)據(jù)不丟失，但集群的恢復則完全靠手動。

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

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

#p#

3. 具體實現(xiàn)

3.1 借助DRBD、HeartbeatHA實現(xiàn)主備切換。

使用DRBD實現(xiàn)兩臺物理機器之間塊設(shè)備的同步，即通過網(wǎng)絡(luò)實現(xiàn)Raid1，輔以Heartbeat HA實現(xiàn)兩臺機器動態(tài)角色切換，對外(DataNode、DFSClient)使用虛IP來統(tǒng)一配置。這種策略，可以很好地規(guī)避因為物理機器損壞造成的 hdfs元數(shù)據(jù)丟失，(這里的元數(shù)據(jù)簡單地說，就是目錄樹，以及每個文件有哪些block組成以及它們之間的順序)，但block與機器位置的對應(yīng)關(guān)系僅會存儲在NameNode的內(nèi)存中，需要DataNode定期向NameNode做block report來構(gòu)建。因此，在數(shù)據(jù)量較大的情況下，blockMap的重建過程也需要等待一段時間，對服務(wù)會有一定的影響。

接著看一下什么是DRBD：Distributed Replicated Block Device是一個用軟件實現(xiàn)的、無共享的、服務(wù)器之間鏡像塊設(shè)備內(nèi)容的存儲復制解決方案。可以理解成一個基于網(wǎng)絡(luò)的RAID-1。

在上述的示意圖中有兩個Server。每個Server含有一個Linux的內(nèi)核，包含文件系統(tǒng)，buffer cache，硬盤管理和物理硬盤，TCP/IP的調(diào)用棧，NIC(network interface card)的驅(qū)動。

黑色的箭頭代表在這些模塊中的數(shù)據(jù)流動。橘色的箭頭表示了從集群的active node到standby node的數(shù)據(jù)流動。

3.2 Facebook AvatarNode

DataNode同時向主備NN匯報block信息。這種方案以Facebook AvatarNode為代表。

PrimaryNN與StandbyNN之間通過NFS來共享FsEdits、FsImage文件，這樣主備NN之間就擁有了一致的目錄樹和block信息;而block的位置信息，可以根據(jù)DN向兩個NN上報的信息過程中構(gòu)建起來。這樣再輔以虛IP，可以較好達到主備NN快速熱切的目的。但是顯然，這里的NFS又引入了新的SPOF。

在主備NN共享元數(shù)據(jù)的過程中，也有方案通過主NN將FsEdits的內(nèi)容通過與備NN建立的網(wǎng)絡(luò)IO流，實時寫入備NN，并且保證整個過程的原子性。這種方案，解決了NFS共享元數(shù)據(jù)引入的SPOF，但是主備NN之間的網(wǎng)絡(luò)連接又會成為新的問題。

總結(jié)：在開源技術(shù)的推動下，針對HDFS NameNode的單點問題，技術(shù)發(fā)展經(jīng)歷以上階段，雖然，在一定程度上緩解了hdfs的安全性和穩(wěn)定性的問題，但仍然存在一定的問題。直到 hadoop2.0.*之后，Quorum Journal Manager給出了一種更好的解決思路和方案。

3.3 QJM/Qurom Journal Manager

Clouera提出了QJM/Qurom Journal Manager，這是一個基于Paxos算法實現(xiàn)的HDFS HA方案。QJM的結(jié)構(gòu)圖如下所示：

QJM的基本原理就是用2N+1臺JournalNode存儲EditLog，每次寫數(shù)據(jù)操作有大多數(shù)(>=N+1)返回成功時即認為該次寫成功，數(shù)據(jù)不會丟失了。當然這個算法所能容忍的是最多有N臺機器掛掉，如果多于N臺掛掉，這個算法就失效了。這個原理是基于Paxos算法的，可以參考http://en.wikipedia.org/wiki/Paxos_(computer_science)。

用QJM的方式來實現(xiàn)HA的主要好處有：1)不需要配置額外的高共享存儲，這樣對于基于commodityhardware的云計算數(shù)據(jù)中心來說，降低了復雜度和維護成本;2)不在需要單獨配置fencing實現(xiàn)，因為QJM本身內(nèi)置了fencing的功能;3)不存在Single Point Of Failure;4)系統(tǒng)魯棒性的程度是可配置的(QJM基于Paxos算法，所以如果配置2N+1臺JournalNode組成的集群，能容忍最多N臺機器掛掉);5)QJM中存儲日志的JournalNode不會因為其中一臺的延遲而影響整體的延遲，而且也不會因為JournalNode的數(shù)量增多而影響性能(因為NN向JournalNode發(fā)送日志是并行的)。

#p#

4. HDFS Federation

單NN的架構(gòu)使得HDFS在集群擴展性和性能上都有潛在的問題，當集群大到一定程度后，NN進程使用的內(nèi)存可能會達到上百G，常用的估算公式為1G對應(yīng)1 百萬個塊，按缺省塊大小計算的話，大概是64T (這個估算比例是有比較大的富裕的，其實，即使是每個文件只有一個塊，所有元數(shù)據(jù)信息也不會有1KB/block)。同時，所有的元數(shù)據(jù)信息的讀取和操作都需要與NN進行通信，譬如客戶端的addBlock、getBlockLocations，還有DataNode的blockRecieved、 sendHeartbeat、blockReport，在集群規(guī)模變大后，NN成為了性能的瓶頸。Hadoop 2.0里的HDFS Federation就是為了解決這兩個問題而開發(fā)的。

（圖片來源： HDFS-1052 設(shè)計文檔

圖片作者： Sanjay Radia, Suresh Srinivas）

這個圖過于簡明，許多設(shè)計上的考慮并不那么直觀，我們稍微總結(jié)一下:

• 多個NN共用一個集群里DN上的存儲資源，每個NN都可以單獨對外提供服務(wù)
• 每個NN都會定義一個存儲池，有單獨的id，每個DN都為所有存儲池提供存儲
• DN會按照存儲池id向其對應(yīng)的NN匯報塊信息，同時，DN會向所有NN匯報本地存儲可用資源情況
• 如果需要在客戶端方便的訪問若干個NN上的資源，可以使用客戶端掛載表，把不同的目錄映射到不同的NN，但NN上必須存在相應(yīng)的目錄

這樣設(shè)計的好處大致有：

• 改動最小，向前兼容
• 現(xiàn)有的NN無需任何配置改動.
• 如果現(xiàn)有的客戶端只連某臺NN的話，代碼和配置也無需改動。
• 分離命名空間管理和塊存儲管理
• 提供良好擴展性的同時允許其他文件系統(tǒng)或應(yīng)用直接使用塊存儲池
• 統(tǒng)一的塊存儲管理保證了資源利用率
• 可以只通過防火墻配置達到一定的文件訪問隔離，而無需使用復雜的Kerberos認證
• 客戶端掛載表
• 通過路徑自動對應(yīng)NN
• 使Federation的配置改動對應(yīng)用透明

參考資料：

1. http://www.binospace.com/index.php/hdfs-ha-quorum-journal-manager/

2. http://www.binospace.com/index.php/hadoop0-23-0_3_hdfs_nn_snn_bn_ha/

3. http://www.sizeofvoid.net/hadoop-2-0-namenode-ha-federation-practice-zh/

4. http://www.blogjava.net/shenh062326/archive/2012/03/24/yuling111.html

5. http://blog.csdn.net/dangyifei/article/details/8920164

6. http://www.drbd.org/

原文鏈接：http://blog.csdn.net/anzhsoft/article/details/23279027