圖文詳解HDFS的高可用和聯邦

Shockang 2021-08-15 21:13:31 阅读数:693

本文一共[544]字,预计阅读时长:1分钟~
hdfs 可用

這是我參與8月更文挑戰的第6天,活動詳情查看:8月更文挑戰

正文

HDFS HA是用來解决NameNode 單點故障問題的,
HDFS 聯邦是用來解决 NameNode 內存瓶頸問題的。
複制代碼

HDFS的高可用和聯邦是什麼?.png

NameNode單點故障

在 HDFS 中 NameNode 所處的比特置是非常重要的,絕對不允許出現故障。

因為整個HDFS文件系統的的元數據信息都是由 NameNode 來管理, NameNode 的可用性直接决定了整個 HDFS 的可用性。

在 Hadoop1.x時代, NameNode 存在單點故障, 且 NameNode 進程不能正常工作了,就會影響整個集群的正常使用,整個HDFS就無法使用,

Hive 或者HBase 等的數據都是存在HDFS之上的,所有 Hive 或者 HBase 等框架也就無法使用,這可能就會導致你的生產集群上很多框架都沒辦法正常使用。

如果通過重新啟動 NameNode 來進行數據恢複的過程也會比較耗時。

HDFS NameNode HA體系架構

在 Hadoop2.x中, HDFS NameNode 的單點問題都得到了解决。 HDFS NameNode 高可用整體架構如圖所示。 在這裏插入圖片描述

從上圖中,我們可以看出 NameNode的高可用架構主要分為下面幾個部分:

在典型的HA集群中,兩個獨立的機器作為 NameNode。

任何時刻,只有個 NameNode處於 Active狀態,另一個處於 Standby 狀態。 Active NameNode 負責所有的客戶端操作,而 Standby NameNode 只是簡單的充當 Slave,它負責維護狀態信息以便在需要時能快速切換。

主備切換控制器 ZKFailoverController

ZKFailoverController 作為獨立的進程運行,對 NameNode的主備切換進行總體控制。

ZKFailoverController 能及時檢測到NameNode的健康狀况,在主 NameNode故障時借助 Zookeeper實現自動的主備選舉和切換,當然 NameNode目前也支持不依賴於 Zookeeper的手動主備切換。

Zookeeper 集群的目的是為主備切換控制器提供主備選舉支持。

ZKFailoverController 的主要職責

健康監測

周期性的向它監控的 NameNode發送健康探測命令,從而來確定某個 NameNode是否處於健康狀態,如果機器宕機,心跳失敗,那麼 ZKFailoverController 就會標記它處於一個不健康的狀態

會話管理

如果 NameNode是健康的,ZKFailoverController 就會在 Zookeeper 中保持一個打開的會話.

如果 NameNode同時還是 Active狀態的,那麼kfc還會在Zookeeper中占有一個類型為短暫類型的 znode,當這個 Name Node掛掉時, 這個 znode將會被删除,然後備用的 NameNode將會得到這把鎖,昇級為主NN,同時標記狀態為 Active。

當宕機的 NameNode新啟動時,它會再次注册 Zookeeper ,發現已經有 znode 鎖了,便會自動變為 Standby狀態,如此往複循環,保證高可靠。

Hadoop2.x僅僅支持最多配置2個NameNode,Hadoop3.x支持多於2個的 NameNode。

master 選舉

如上所述,通過在 Zookeeper中維持一個短暫類型的 znode,來實現搶占式的鎖機制,從而判斷哪個 NameNode 為 Active 狀態

共享存儲系統 Quorum Journal Node

為了讓 Standby Node 與 Active Node 保持狀態的同步,它們兩個都要與稱為"JournalNodes"(JNs)的一組獨立的進程通信。

Active Node 所做的任何命名空間的修改,都將修改記錄的日志發送給大多數的 JNs。

Standby Node 能够從 JNs 讀取 edits ,並且時時監控它們對 EditLog 的修改。

Standby Node獲取 edits 後,將它們應用到自己的命名空間。

故障切換時, Standby 將確保在提昇它自己為 Active 狀態前已經從 JNs 讀完了所有的 edits ,這就確保了故障切換發生前(兩個 NameNode)命名空間狀態是完全同步的。

DataNode節點

除了通過共享存儲系統共享HDFS的元數據信息之外,主 NameNode和備 NameNode 還需要共享 HDFS 的數據塊和 DataNode之間的映射關系。

DataNode會同時向主 NameNode 和備 NameNode 上報數據塊的比特置信息。

聯邦(Federation)

Federation產生背景

通過閱讀專欄之前的內容我們知道 HDFS 集群的元數據信息是存放在 NameNode 的內存中的,

當集群擴大到一定的規模以後, NameNode 內存中存放的元數據信息可能會非常大,由於 HDFS 的所有的操作都會和 NameNode 進行交互, 當集群很大時, NameNode 會成為集群的瓶頸。

在 Hadoop2.x 誕生之前,HDFS 中只能有一個命名空間,對於 HDFS 中的文件沒有辦法完成隔離。

正因為如此,在 Hadoop2.x中引入了Federation的機制,可以解决如下場景的問題。

  1. HDFS集群擴展性。多個 NameNode 分管一部分目錄,使得一個集群可以擴展到更多節點,不再像 1.0 中由於內存的限制制約文件存儲數目。
  2. 性能更高效。多個 NameNode 管理不同的數據,且同時對外提供服務,將為用戶提供更高的讀寫吞吐率。
  3. 良好的隔離性。用戶可根據需要將不同業務數據交由不同 NameNode 管理這樣不同業務之間影響很小。

HDFS數據管理架構

數據存儲采取分層的結構。也就是說,所有關於存儲數據的信息和管理是放在 NameNode 這邊,而真實的數據則是存儲在各個 DataNode 下。

這些隸屬於同一個 NameNode所管理的數據都在同一個命名空間 namespace 下,而一個 namespace 對應一個 block pool。

Block Pool 是同一個 namespace 下的 block 的集合,當然這是我們最常見的單個 namespace 的情况,

也就是一個 Name Node 管理集群中所有元數據信息的時候,如果我們遇到了前面提到的 NameNode 內存使用過高的問題,這時候怎麼辦?

元數據空間依然還是在不斷增大,一味調高 NameNode 的jvm大小絕對不是一個持久的辦法。這時候就誕生了 HDFS Federation 的機制。

Federation架構

NameNode 內存過高問題,我們完全可以將大的文件目錄移到另外一個 NameNode 上做管理,更重要的一點在於,這些 NameNode 是共享集群中所有的 DataNode 的,

它們還是在同一個集群內的。 HDFS Federation 原理結構如圖所示。

在這裏插入圖片描述

HDFS Federation 是解决 NameNode 單點問題的水平橫向擴展方案。使得到多個獨立的 NameNode 和命名空間。

從而使得 HDFS 的命名服務能够水平擴張 HDFS Federation 中的 NameNode 相互獨立管理自己的命名空間。

這時候在 DataNode 上就不僅僅存儲一個 Block Pool 下的數據,而是多個。

在 HDFS Federation 的情况下,只有元數據的管理與存放被分隔開,而真實數據的存儲還是共用的。

文獻參考

《Hadoop & Spark大數據開發實戰》肖睿、雷剛躍主編

版权声明:本文为[Shockang]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815211248068C.html