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等等。
使用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的資料流動。
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給出了一種更好的解決思路和方案。
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發送日志是并行的）。
單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
6. http://www.drbd.org/