HDFS HA: 高可靠性分布式存儲(chǔ)系統(tǒng)解決方案的歷史演進(jìn)

作者：anzhsoft 2015-05-27 14:25:08

HDFS HA的解決方案可謂百花齊放，Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等等。目前普遍采用的是shared NAS+NFS，因?yàn)楹唵我子茫切枰峁┮粋€(gè)HA的共享存儲(chǔ)設(shè)備。而社區(qū)已經(jīng)把基于QJM/Quorum Journal Manager的方案merge到trunk了，clouderea提供的發(fā)行版中也包含了這個(gè)feature，這種方案也是社區(qū)在未來發(fā)行版中默認(rèn)的 HA方案。

1. HDFS 簡介

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

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

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

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

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

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

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

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

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

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

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

2. HA基礎(chǔ)

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

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

在Hadoop 2.0之前，也有若干技術(shù)試圖解決單點(diǎn)故障的問題，我們?cè)谶@里做個(gè)簡短的總結(jié)

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

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

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

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

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

#p#

3. 具體實(shí)現(xiàn)

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

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

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

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

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

3.2 Facebook AvatarNode

DataNode同時(shí)向主備NN匯報(bào)block信息。這種方案以Facebook AvatarNode為代表。

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

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

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

3.3 QJM/Qurom Journal Manager

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

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

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

#p#

4. HDFS Federation

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

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

圖片作者： Sanjay Radia, Suresh Srinivas）

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

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

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