HDFS HA架構

HA背景

對於HDFS、YARN的每一個角色都是一個進程，

好比HDFS：NN/SNN/DN   老大是NN

YARN：RM/NM   老大是RM

對於上面，都會存在單點故障的問題，假如老大NN或者RM掛了，那麼就不能提供對外服務了，會致使整個集羣都不能使用。

大數據幾乎全部的組建都是主從架構（master-slave）。好比hdfs的讀寫請求都是先通過NN節點。（可是hbase的讀寫請求不是通過老大的master）。

hdfs：由NN/SNN/DN組成，SNN每小時會作一次checkpoint的操做，若是NN掛了，只能恢復到上次checkpoint的那一刻，不能實時。如今若是把SNN的角色再提高一個等級，讓它和NN同樣，若是NN掛了，SNN能當即切換過來就行了。

HDFS HA 架構 有兩個NN節點，一個是active活躍狀態，一個是standby準備狀態，Active NameNode對外提供服務，好比處理來自客戶端的RPC請求，而Standby NameNode則不對外提供服務，僅同步Active NameNode的狀態，對Active NameNode進行實時備份，以便可以在它失敗時快速進行切換。

HA介紹

HDFS High Availability (HA) 

假定：

NN1 active       ip1

NN2 standby    ip2

假如說在咱們代碼或者shell腳本里，寫了：hdfs dfs -ls hdfs://ip1:9000/   ，那麼若是NN1掛了，NN2切換到active狀態了，可是在腳本里仍是ip1，這個時候不可能手動去修改。確定有問題。那麼該怎麼解決？

用命名空間來解決。命名空間不是進程。好比：命名空間的名稱爲：ruozeclusterg7

腳本里能夠這樣寫：hdfs dfs -ls hdfs://ruozeclusterg7/

當代碼執行到這一行時，它會去core-site.xml、hdfs-site.xml裏面查找。在這兩個配置文件裏面，配置了ruozeclusterg7命名空間下掛了NN1和NN2。當它找到NN1，它會嘗試着鏈接第一個機器NN1，若是發現它不是active狀態，它會嘗試着鏈接第二個機器NN2，若是發現NN1是active狀態，就直接用了。

 

HA 進程：(假定咱們如今有三臺機器)

hadoop001:ZK    NN  ZKFC  JN    DN

hadoop002:ZK    NN  ZKFC  JN    DN

hadoop003:ZK                       JN    DN

NN節點有fsimage、editlog(讀和寫請求的記錄)兩個文件,有專門的進程去管理的，這個進程是JN（journalnode）日誌節點，要保證NN1和NN2能實時同步，須要JN這個角色。

若是NN1掛了，須要把NN2從standby狀態切換到active狀態，那它是怎麼切換的呢？須要ZKFC。

ZKFC: 是單獨的進程，它監控NN健康狀態，向zk集羣按期發送心跳，使得本身能夠被選舉；當本身被zk選舉爲active的時候，zkfc進程經過RPC協議調用使NN節點的狀態變爲active。對外提供實時服務，是無感知的。

因此在上面，須要在三臺機器上都部署一下zookeeper，做爲一個集羣，ZK集羣，是用於作選舉的。選舉誰來作老大（active），誰作standby。集羣中ZK的個數是2n+1，這樣能投票保證最後有一個勝出。

生產上zookeeper部署的個數經驗：若是集羣中有20臺節點，那麼能夠在5臺上部署zk。若是總共有七八臺，也部署5臺zk。若是總共有20~100臺節點，能夠部署7臺/9臺/11臺 zk。若是大於100臺，能夠部署11臺zk。若是有不少，好比上萬臺那看狀況能夠多部署幾臺。可是，不是說zk節點越多越好。由於作投票選舉動做的時候，投票誰作active，誰作standby是須要時間的，時間間隔太長會影響對外服務，對外服務會很慢，對於即時性 的服務來講，這是不容許的。

他們的集羣有不少臺，好比幾百臺幾千臺，zk部署的機器上就它一個進程，不部署其它進程了。在這裏是學習或者機器不多，因此一臺機器上部署多個進程。若是幾百臺節點，任務很重，若是部署zk的機器上有其它進程，那麼它會消耗不少機器上的資源（無外乎cpu、內存、文件數、進程數），這都會影響zk響應的速度，因此通常都會把它獨立出來。可是若是機器是256G內存，可是zk只用到32G，那其餘的就浪費了，那麼買機器的時候，能夠單獨給zk買32G內存的機器就能夠了。

zk是最底層的，若是zk太繁忙，就可能致使standby狀態不能切換到active狀態，這個時候機器可能就會夯住。因此當機器夯住，standby不能切換到active的時候，有可能就是zk出問題了。

HDFS HA 架構圖

關於HA 架構的官方文檔https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

Architecture
In a typical HA cluster, two or more separate machines are configured as NameNodes. At any point in time, exactly one of the NameNodes is in an Active state, and the others are in a Standby state. The Active NameNode is responsible for all client operations in the cluster, while the Standbys are simply acting as workers, maintaining enough state to provide a fast failover if necessary.
In order for the Standby node to keep its state synchronized with the Active node, both nodes communicate with a group of separate daemons called 「JournalNodes」 (JNs). When any namespace modification is performed by the Active node, it durably logs a record of the modification to a majority of these JNs. The Standby node is capable of reading the edits from the JNs, and is constantly watching them for changes to the edit log. As the Standby Node sees the edits, it applies them to its own namespace. In the event of a failover, the Standby will ensure that it has read all of the edits from the JournalNodes before promoting itself to the Active state. This ensures that the namespace state is fully synchronized before a failover occurs.
In order to provide a fast failover, it is also necessary that the Standby node have up-to-date information regarding the location of blocks in the cluster. In order to achieve this, the DataNodes are configured with the location of all NameNodes, and send block location information and heartbeats to all.
It is vital for the correct operation of an HA cluster that only one of the NameNodes be Active at a time. Otherwise, the namespace state would quickly diverge between the two, risking data loss or other incorrect results. In order to ensure this property and prevent the so-called 「split-brain scenario,」 the JournalNodes will only ever allow a single NameNode to be a writer at a time. During a failover, the NameNode which is to become active will simply take over the role of writing to the JournalNodes, which will effectively prevent the other NameNode from continuing in the Active state, allowing the new Active to safely proceed with failover.

翻譯：

一個典型的HA集羣，NameNode會被配置在2臺或更多 獨立的機器上，在任什麼時候間上，一個NameNode處於活動狀態，而另外一個NameNode處於備份狀態，活動狀態的NameNode會響應集羣中全部的客戶端，備份狀態的NameNode只是做爲一個副本，保證在必要的時候提供一個快速的轉移。

爲了讓Standby Node與Active Node保持同步，這兩個Node都與一組稱爲JNS的互相獨立的進程保持通訊(Journal Nodes)。當Active Node上更新了namespace，它將記錄修改日誌發送給JNS的多數派。Standby noes將會從JNS中讀取這些edits，並持續關注它們對日誌的變動。Standby Node將日誌變動應用在本身的namespace中，當failover發生時，Standby將會在提高本身爲Active以前，確保可以從JNS中讀取全部的edits，即在failover發生以前Standy持有的namespace應該與Active保持徹底同步。

爲了支持快速failover，Standby node持有集羣中blocks的最新位置是很是必要的。爲了達到這一目的，DataNodes上須要同時配置這兩個Namenode的地址，同時和它們都創建心跳連接，並把block位置發送給它們。

任什麼時候刻，只有一個Active NameNode是很是重要的，不然將會致使集羣操做的混亂，那麼兩個NameNode將會分別有兩種不一樣的數據狀態，可能會致使數據丟失，或者狀態異常，這種狀況一般稱爲「split-brain」（腦裂，三節點通信阻斷，即集羣中不一樣的Datanodes卻看到了兩個Active NameNodes）。對於JNS而言，任什麼時候候只容許一個NameNode做爲writer；在failover期間，原來的Standby Node將會接管Active的全部職能，並負責向JNS寫入日誌記錄，這就阻止了其餘NameNode基於處於Active狀態的問題。

首先要部署三臺zk，而後要兩臺NN節點，而後三臺DN節點。兩個NN節點之間的編輯日誌須要jn來維護，作共享數據存儲。

journalnode(jn): 部署多少合適？取決於HDFS請求量及數據量，好比說BT級的數據量，或者小文件不少，讀寫請求很頻繁，那麼journalnode就部署多一點，若是HDFS很清閒，那就部署少一點，好比7個、9個這樣，能夠大體和zk部署的保持一致（見上面）。具體要看實際狀況。（也是2n+1，能夠看官網上介紹）

ZKFC：zookeeperfailovercontrol

客戶端或者程序代碼在提交的時候，去namespace找，找NN節點，若是第一次找的NN節點就是active，那麼就用這個節點，若是發現它是standby，就到另一臺機器。

好比說客戶端如今執行put、get、ls、cat命令，這些操做命令的記錄，active NN節點會寫到本身的edit log日誌裏面。這些操做記錄，NN本身會寫一份，同時，它會把這些操做記錄，寫給journalnode的node集羣。

而另外的，standby NN節點，會實時的讀journalnode的node集羣，讀了以後會把這些記錄應用到本身的自己。這個大數據的專業名詞叫作：重演。 至關於standby NN節點把active NN節點的active狀態的操做記錄在本身身上重演一遍。

journalnode：它是一個集羣，就是用於active NN節點和standby NN節點之間同步數據的。它是單獨的進程。

NN和ZKFC在同一臺機器上面。

整個過程描述：當經過client端提交請求的時候，不管讀和寫，咱們是經過命名空間RUOZEG6，去找誰是active狀態，找到了就在那臺機器上面，提交請求，而後就是HDFS的讀寫流程，讀和寫的操做記錄，edit log，它本身會寫一份，同時會把讀寫請求的操做記錄，寫一份到journalnode集羣日誌，進行同步以後，另一個節點，standby 節點會把它拿過來實時的應用到本身的自己。專業的名稱叫重演。同時每一個DataNode會向NameNode節點發送心跳的塊報告（心跳的間隔時間3600s，就是1小時，參數是什麼（面試））。當active NN節點掛了，經過zk集羣選舉（它存儲了NN節點的狀態），通知ZKFC，把standby NN節點切換到active狀態。ZKFC會按期的發送心跳。

ps：

HA是爲了解決單點故障問題。

經過journalnode集羣共享狀態，也就是共享hdfs讀和寫的操做記錄。

經過ZKFC集羣選舉誰是active。

監控狀態，自動備援。

DN: 同時向NN1 NN2發送心跳和塊報告。

ACTIVE NN: 讀寫的操做記錄寫到本身的editlog

                     同時寫一份到JN集羣

                     接收DN的心跳和塊報告

STANDBY NN: 同時接收JN集羣的日誌，顯示讀取執行log操做(重演)，使得本身的元數據和active nn節點保持一致。

                        接收DN的心跳和塊報告

JounalNode: 用於active nn和 standby nn節點的數據同步， 通常部署2n+1

ZKFC: 單獨的進程

           監控NN監控健康狀態

           向zk集羣按期發送心跳，使得本身能夠被選舉；

           當本身被zk選舉爲active的時候，zkfc進程經過RPC協議調用使NN節點的狀態變爲active，只有是

active狀態才能對外提供服務。

           對外提供實時服務，是無感知的，用戶是感受不到的。

總結

HDFS HA架構圖 以三臺機器 爲例

HA使用active NN，standby NN兩個節點解決單點問題。

兩個NN節點經過JN集羣，共享狀態，

經過ZKFC選舉active，監控狀態，自動備援。

DN會同時向兩個NN節點發送心跳

active nn：

接收client的rpc請求並處理，同時本身editlog寫一份，也向JN的共享存儲上的editlog寫一份。

也同時接收DN的block report，block location updates 和 heartbeat

standby nn:

一樣會接受到從JN的editlog上讀取並執行這些log操做，使本身的NN的元數據和activenn的元數據是同步的，

使用說standby是active nn的一個熱備。一旦切換爲active狀態，就可以當即立刻對外提供NN角色的服務。

也同時接收DN的block report，block location updates 和 heartbeat

jn:

用於active nn,standby nn 的同步數據，自己由一組JN節點組成的集羣，奇數，CDH3臺起步，是支持Paxos協議。

保證高可用

ZKFC做用：

1.監控NameNode狀態，ZKFC會按期向ZK發送心跳，使本身被選舉，當本身被ZK選舉爲主時，咱們的ZKFC進程經過rpc調用，讓nn轉換爲active狀態。