HDFS-2.0社區版的HA+Federation的實現解析

    在Hadoop的1.x版本中,NN的單點處理能力成爲HDFS的主要(容量擴展/性能/可用性)瓶頸,主要表現在:一.NN在管理大規模的命名空間時,所消耗的內存堆必定在10GB/100GB級別,無論是觸發的Full Gc(32GB需要2min)還是重啓時(元數據加載/操作日誌回放/數據塊彙報)時間消耗對高可用性來說都是無可忍受的;二是NN在內部用一把全局鎖擼遍所有的元數據操作來保證數據的一致性;三是被人一直詬病的NN單點故障問題; 所以從Hadoop的2.x開始,社區試圖使用Federation+HA的方案來解決hadoop-1.x中的容量擴展及可用性的問題.本文將主要介紹這種方案的設計與實現,至於優劣並不做任何評價.

   Federation方案的基本思路就是使用多個獨立的NameSpace(NameNode節點管理)來滿足HDFS命名空間的水平擴展,NameSpace之間在邏輯上是完全相互獨立的(即任意兩個NameSpace可以有完全相同的文件名),而在物理上可以完全獨立(NameNode節點管理不同的DataNode)也可以有聯繫(共享存儲節點DataNode)很顯然,任何一個NameNode節點只能管理一個Namespace.這種在邏輯上無法統一命名空間的設計對於初學者來說,可能會常常踩到文件名衝突或文件不存在的陷阱中.很顯然,任何一個NameNode節點只能管理一個Namespace.

HDFS-2.0 HA+Federation的總體設計

1.NameNode的HA

    要實現NameNode的HA方案,最重要的部分就是需要一個共享式的存儲系統來實時存儲NameNode的操作日誌,而這種共享式的存儲系統必須要滿足兩個基本條件:一是自身必須要高可用,二是保證強一致性.目前,Hadoop-2.x使用Quorum Journal Manager(QJM)來實現操作日誌的共享,QJM是一個比ZooKeeper要輕量級的分佈式存儲系統,所使用的一致性約束條件遠遠不如paxos,raft等高可用的一致性算法.HDFS抽象出了一個日誌接口JournalManager來屏蔽底層對操作日誌存儲的實現細節,目前主要有三種實現:

+ JournalManager
  -FileJournalManager
  -QuorumJournalManager
  -BackupJournalManager

FileJournalManager將操作日誌寫入本地文件系統中,QuorumJournalManager將操作日誌寫入QJM中來實現主/備NameNode之間的操作日誌共享,BackupJournalManager將操作日誌實時的推送給backup的NameNode節點.QuorumJournalManager爲了保證性能,採用了異步併發的方式將操作日誌刷入所有的JournalNode節點

配置的HA的HDFS,所有NameSpace的NameNode節點在啓動加載完元數據之後都處於Standby狀態,之後被手動或自動的選擇一個NameNode節點作爲Active節點而開始正常工作.HA的自動方式是通過在每一個NameNode的本地啓動一個守護進程ZKFailoverController來競爭Active NameNode的,ZKFailoverController除了爲本地的NameNode爭取Active角色之外,還負責監控本地的NN節點當前是否正常的,一旦它發現本地的NN不正常,要麼主動替當前的Active NN退出Active角色或退出Active的競爭.

2.DataNode的Block Pool

     一個DataNode既可以服務於一個NameSpace,也可以服務於多個NameSpace,它對HA+Federation方案的支持主要是通過BlockPoolManager來完成的.BlockPoolManager會給配置的所有NameSpace下的主/備NameNode節點都彙報塊信息.

3.DistributedFileSystem的容錯Proxy

     HDFS的HA方案並不只是保證NameNode節點的高可用,還得保證客戶端能夠對用戶透明的容忍主/備NameNode節點之間的切換.目前客戶端對HA方案的實現方式主要是通過重試的機制來完成的.