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狀態才能對外提供服務。

           對外提供實時服務，是無感知的，使用者是感覺不到的。

http://www.renrendoc.com/p-21933469.html

總結

 

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

鄭州哪裡看不孕不育好：http://www.xbzztj.com/

jn:

用於active nn,standby nn 的同步資料，本身由一組JN節點組成的叢集，奇數，CDH3臺起步，是支援Paxos協議。

保證高可用

 

ZKFC作用：

1.監控NameNode狀態，ZKFC會定期向ZK傳送心跳，使自己被選舉，當自己被ZK選舉為主時，我們的ZKFC程序通過rpc呼叫，讓nn轉