HDFS HA: 高可靠性分佈式存儲系統解決方案的歷史演進
1. HDFS 簡介
HDFS，爲Hadoop這個分佈式計算框架提供高性能、高可靠、高可擴展的存儲服務。HDFS的系統架構是典型的主/從架構，早期的架構包括一個主節點NameNode和多個從節點DataNode。NameNode是整個文件系統的管理節點，也是HDFS中最複雜的一個實體，它維護着HDFS文件系統中最重要的兩個關係：
- HDFS文件系統中的文件目錄樹，以及文件的數據塊索引，即每個文件對應的數據塊列表。
- 數據塊和數據節點的對應關係，即某一塊數據塊保存在哪些數據節點的信息。
其中，第一個關係即目錄樹、元數據和數據塊的索引信息會持久化到物理存儲中，實現是保存在命名空間的鏡像fsimage和編輯日誌edits中。而第二個關係是在NameNode啓動後，有DataNode主動上報它所存儲的數據塊，動態建立對應關係。
在上述關係的基礎上，NameNode管理着DataNode，通過接收DataNode的註冊、心跳、數據塊提交等信息的上報，並且在心跳中發送數據塊複製、刪除、恢復等指令；同時，NameNode還爲客戶端對文件系統目錄樹的操作和對文件數據讀寫、對HDFS系統進行管理提供支持。
DataNode提供真實文件數據的存儲服務。它以數據塊的方式在本地的Linux文件系統上保存了HDFS文件的內容，並且對外提供文件數據的訪問功能。客戶端在讀寫文件時，必須通過NameNode提供的信息，進一步和DataNode進行交互；同時，DataNode還必須接NameNode的管理，執行NameNode的指令，並且上報NameNode感興趣的事件，以保證文件系統穩定，可靠，高效的運行。架構圖如下：
在HDFS集羣中NameNode存在單點故障（SPOF）。對於只有一個NameNode的集羣，如果NameNode機器出現故障，那麼整個集羣將無法使用，直到NameNode重新啓動。
NameNode主要在以下兩個方面影響HDFS集羣:
-
NameNode機器發生意外，比如宕機，集羣將無法使用，直到管理員重啓NameNode
-
NameNode機器需要升級，包括軟件、硬件升級，此時集羣也將無法使用
HDFS的HA功能通過配置Active/Standby兩個NameNodes實現在集羣中對NameNode的熱備來解決上述問題。如果出現故障，如機器崩潰或機器需要升級維護，這時可通過此種方式將NameNode很快的切換到另外一臺機器。
2. HA基礎
HDFS HA的解決方案可謂百花齊放，Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等等。目前普遍採用的是shared NAS+NFS，因爲簡單易用，但是需要提供一個HA的共享存儲設備。而社區已經把基於QJM/Quorum Journal Manager的方案merge到trunk了，clouderea提供的發行版中也包含了這個feature，這種方案也是社區在未來發行版中默認的HA方案。
在HA具體實現方法不同的情況下，HA框架的流程是一致的。不一致的就是如何存儲和管理日誌。在Active NN和Standby NN之間要有個共享的存儲日誌的地方，Active NN把EditLog寫到這個共享的存儲日誌的地方，Standby NN去讀取日誌然後執行，這樣Active和Standby NN內存中的HDFS元數據保持着同步。一旦發生主從切換Standby NN可以儘快接管Active NN的工作（雖然要經歷一小段時間讓原來Standby追上原來的Active，但是時間很短）。
說到這個共享的存儲日誌的地方，目前採用最多的就是用共享存儲NAS+NFS。缺點有：1）這個存儲設備要求是HA的，不能down；2）主從切換時需要fencing方法讓原來的Active不再寫EditLog，否則的話會發生brain-split，因爲如果不阻止原來的Active停止向共享存儲寫EditLog，那麼就有兩個Active NN了，這樣就會破壞HDFS的元數據了。對於防止brain-split問題，在QJM出現之前，常見的方法就是在發生主從切換的時候，把共享存儲上存放EditLog的文件夾對原來的Active的寫權限拿掉，那麼就可以保證同時至多隻有一個Active NN，防止了破壞HDFS元數據。
在Hadoop 2.0之前，也有若干技術試圖解決單點故障的問題，我們在這裏做個簡短的總結
- Secondary NameNode。它不是HA，它只是階段性的合併edits和fsimage，以縮短集羣啓動的時間。當NameNode(以下簡稱NN)失效的時候，Secondary NN並無法立刻提供服務，Secondary NN甚至無法保證數據完整性：如果NN數據丟失的話，在上一次合併後的文件系統的改動會丟失。
- Backup NameNode (HADOOP-4539)。它在內存中複製了NN的當前狀態，算是Warm Standby，可也就僅限於此，並沒有failover等。它同樣是階段性的做checkpoint，也無法保證數據完整性。
- 手動把name.dir指向NFS。這是安全的Cold Standby，可以保證元數據不丟失，但集羣的恢復則完全靠手動。
- Facebook AvatarNode。Facebook有強大的運維做後盾，所以Avatarnode只是Hot Standby，並沒有自動切換，當主NN失效的時候，需要管理員確認，然後手動把對外提供服務的虛擬IP映射到Standby NN，這樣做的好處是確保不會發生腦裂的場景。其某些設計思想和Hadoop 2.0裏的HA非常相似，從時間上來看，Hadoop 2.0應該是借鑑了Facebook的做法。
- 還有若干解決方案，基本都是依賴外部的HA機制，譬如DRBD，Linux HA，VMware的FT等等。
3. 具體實現
3.1 藉助DRBD、HeartbeatHA實現主備切換。
使用DRBD實現兩臺物理機器之間塊設備的同步，即通過網絡實現Raid1，輔以Heartbeat HA實現兩臺機器動態角色切換，對外(DataNode、DFSClient)使用虛IP來統一配置。這種策略，可以很好地規避因爲物理機器損壞造成的hdfs元數據丟失，(這裏的元數據簡單地說，就是目錄樹，以及每個文件有哪些block組成以及它們之間的順序)，但block與機器位置的對應關係僅會存儲在NameNode的內存中，需要DataNode定期向NameNode做block report來構建。因此，在數據量較大的情況下，blockMap的重建過程也需要等待一段時間，對服務會有一定的影響。
接着看一下什麼是DRBD：Distributed Replicated Block Device是一個用軟件實現的、無共享的、服務器之間鏡像塊設備內容的存儲複製解決方案。可以理解成一個基於網絡的RAID-1。
在上述的示意圖中有兩個Server。每個Server含有一個Linux的內核，包含文件系統，buffer cache，硬盤管理和物理硬盤，TCP/IP的調用棧，NIC(network interface card)的驅動。
黑色的箭頭代表在這些模塊中的數據流動。橘色的箭頭表示了從集羣的active node到standby node的數據流動。
3.2 Facebook AvatarNode
DataNode同時向主備NN彙報block信息。這種方案以Facebook AvatarNode爲代表。
PrimaryNN與StandbyNN之間通過NFS來共享FsEdits、FsImage文件，這樣主備NN之間就擁有了一致的目錄樹和block信息；而block的位置信息，可以根據DN向兩個NN上報的信息過程中構建起來。這樣再輔以虛IP，可以較好達到主備NN快速熱切的目的。但是顯然，這裏的NFS又引入了新的SPOF。
在主備NN共享元數據的過程中，也有方案通過主NN將FsEdits的內容通過與備NN建立的網絡IO流，實時寫入備NN，並且保證整個過程的原子性。這種方案，解決了NFS共享元數據引入的SPOF，但是主備NN之間的網絡連接又會成爲新的問題。
總結：在開源技術的推動下，針對HDFS NameNode的單點問題，技術發展經歷以上階段，雖然，在一定程度上緩解了hdfs的安全性和穩定性的問題，但仍然存在一定的問題。直到hadoop2.0.*之後，Quorum Journal Manager給出了一種更好的解決思路和方案。
3.3 QJM/Qurom Journal Manager
Clouera提出了QJM/Qurom Journal Manager，這是一個基於Paxos算法實現的HDFS HA方案。QJM的結構圖如下所示：
QJM的基本原理就是用2N+1臺JournalNode存儲EditLog，每次寫數據操作有大多數（>=N+1）返回成功時即認爲該次寫成功，數據不會丟失了。當然這個算法所能容忍的是最多有N臺機器掛掉，如果多於N臺掛掉，這個算法就失效了。這個原理是基於Paxos算法的，可以參考http://en.wikipedia.org/wiki/Paxos_(computer_science)。
用QJM的方式來實現HA的主要好處有：1）不需要配置額外的高共享存儲，這樣對於基於commodityhardware的雲計算數據中心來說，降低了複雜度和維護成本；2）不在需要單獨配置fencing實現，因爲QJM本身內置了fencing的功能；3）不存在Single Point Of Failure；4）系統魯棒性的程度是可配置的（QJM基於Paxos算法，所以如果配置2N+1臺JournalNode組成的集羣，能容忍最多N臺機器掛掉）；5）QJM中存儲日誌的JournalNode不會因爲其中一臺的延遲而影響整體的延遲，而且也不會因爲JournalNode的數量增多而影響性能（因爲NN向JournalNode發送日誌是並行的）。
4. HDFS
Federation
單NN的架構使得HDFS在集羣擴展性和性能上都有潛在的問題，當集羣大到一定程度後，NN進程使用的內存可能會達到上百G，常用的估算公式爲1G對應1百萬個塊，按缺省塊大小計算的話，大概是64T (這個估算比例是有比較大的富裕的，其實，即使是每個文件只有一個塊，所有元數據信息也不會有1KB/block)。同時，所有的元數據信息的讀取和操作都需要與NN進行通信，譬如客戶端的addBlock、getBlockLocations，還有DataNode的blockRecieved、sendHeartbeat、blockReport，在集羣規模變大後，NN成爲了性能的瓶頸。Hadoop
2.0裏的HDFS Federation就是爲了解決這兩個問題而開發的。
圖片來源：
HDFS-1052 設計文檔
圖片作者： Sanjay Radia, Suresh Srinivas
這個圖過於簡明，許多設計上的考慮並不那麼直觀，我們稍微總結一下:
- 多個NN共用一個集羣裏DN上的存儲資源，每個NN都可以單獨對外提供服務
- 每個NN都會定義一個存儲池，有單獨的id，每個DN都爲所有存儲池提供存儲
- DN會按照存儲池id向其對應的NN彙報塊信息，同時，DN會向所有NN彙報本地存儲可用資源情況
- 如果需要在客戶端方便的訪問若干個NN上的資源，可以使用客戶端掛載表，把不同的目錄映射到不同的NN，但NN上必須存在相應的目錄
這樣設計的好處大致有：
- 改動最小，向前兼容
- 現有的NN無需任何配置改動.
- 如果現有的客戶端只連某臺NN的話，代碼和配置也無需改動。
- 分離命名空間管理和塊存儲管理
- 提供良好擴展性的同時允許其他文件系統或應用直接使用塊存儲池
- 統一的塊存儲管理保證了資源利用率
- 可以只通過防火牆配置達到一定的文件訪問隔離，而無需使用複雜的Kerberos認證
- 客戶端掛載表
- 通過路徑自動對應NN
- 使Federation的配置改動對應用透明
轉載註明出處：http://blog.csdn.net/anzhsoft/article/details/23279027； http://www.anzhan.me
參考資料：
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