一、Hadoop 系統架構

1.1 Hadoop1.x和Hadoop2.x 架構

在介紹HA之前，我們先來看下Hadoop的系統架構，這對于理解HA是至關重要的。Hadoop?1.x之前，其官方架構如圖1所示:

?

?

[ 圖1.Hadoop 1.x架構圖 ]

從圖中可看出，1.x版本之前只有一個Namenode,所有元數據由惟一的Namenode負責管理,可想而之當這個NameNode掛掉時整個集群基本也就不可用。

Hadoop 2.x的架構與1.x有什么區別呢。我們來看下2.x的架構：

?

?

[ 圖2.Hadoop 2.x架構圖 ]

2.x版本中，HDFS架構解決了單點故障問題，即引入雙NameNode架構，同時借助共享存儲系統來進行元數據的同步，共享存儲系統類型一般有幾類，如：Shared NAS+NFS、BookKeeper、BackupNode 和 Quorum Journal Manager(QJM)，上圖中用的是QJM作為共享存儲組件，通過搭建奇數結點的JournalNode實現主備NameNode元數據操作信息同步。Hadoop的元數據包括哪些信息呢，下面介紹下關于元數據方面的知識。

1.2 Hadoop 2.x元數據

Hadoop的元數據主要作用是維護HDFS文件系統中文件和目錄相關信息。元數據的存儲形式主要有3類：內存鏡像、磁盤鏡像(FSImage)、日志(EditLog)。在Namenode啟動時，會加載磁盤鏡像到內存中以進行元數據的管理，存儲在NameNode內存;磁盤鏡像是某一時刻HDFS的元數據信息的快照，包含所有相關Datanode節點文件塊映射關系和命名空間(Namespace)信息，存儲在NameNode本地文件系統;日志文件記錄client發起的每一次操作信息，即保存所有對文件系統的修改操作，用于定期和磁盤鏡像合并成最新鏡像，保證NameNode元數據信息的完整，存儲在NameNode本地和共享存儲系統(QJM)中。

如下所示為NameNode本地的EditLog和FSImage文件格式，EditLog文件有兩種狀態： inprocess和finalized, inprocess表示正在寫的日志文件，文件名形式:editsinprocess[start-txid]，finalized表示已經寫完的日志文件,文件名形式：edits[start-txid][end-txid]; FSImage文件也有兩種狀態, finalized和checkpoint， finalized表示已經持久化磁盤的文件，文件名形式: fsimage_[end-txid], checkpoint表示合并中的fsimage, 2.x版本checkpoint過程在Standby Namenode(SNN)上進行，SNN會定期將本地FSImage和從QJM上拉回的ANN的EditLog進行合并，合并完后再通過RPC傳回ANN。

data/hbase/runtime/namespace
├── current
│ ├── VERSION
│ ├── edits_0000000003619794209-0000000003619813881
│ ├── edits_0000000003619813882-0000000003619831665
│ ├── edits_0000000003619831666-0000000003619852153
│ ├── edits_0000000003619852154-0000000003619871027
│ ├── edits_0000000003619871028-0000000003619880765
│ ├── edits_0000000003619880766-0000000003620060869
│ ├── edits_inprogress_0000000003620060870
│ ├── fsimage_0000000003618370058
│ ├── fsimage_0000000003618370058.md5
│ ├── fsimage_0000000003620060869
│ ├── fsimage_0000000003620060869.md5
│ └── seen_txid
└── in_use.lock

上面所示的還有一個很重要的文件就是seen_txid,保存的是一個事務ID，這個事務ID是EditLog最新的一個結束事務id，當NameNode重啟時，會順序遍歷從edits_0000000000000000001到seen_txid所記錄的txid所在的日志文件，進行元數據恢復，如果該文件丟失或記錄的事務ID有問題，會造成數據塊信息的丟失。

HA其本質上就是要保證主備NN元數據是保持一致的，即保證fsimage和editlog在備NN上也是完整的。元數據的同步很大程度取決于EditLog的同步，而這步驟的關鍵就是共享文件系統，下面開始介紹一下關于QJM共享存儲機制。

二、QJM原理

2.1 QJM背景

在QJM出現之前，為保障集群的HA，設計的是一種基于NAS的共享存儲機制，即主備NameNode間通過NAS進行元數據的同步。該方案有什么缺點呢，主要有以下幾點：

定制化硬件設備：必須是支持NAS的設備才能滿足需求

復雜化部署過程：在部署好NameNode后，還必須額外配置NFS掛載、定制隔離腳本，部署易出錯

簡陋化NFS客戶端：Bug多，部署配置易出錯，導致HA不可用

所以對于替代方案而言，也必須解決NAS相關缺陷才能讓HA更好服務。即設備無須定制化，普通設備即可配置HA，部署簡單，相關配置集成到系統本身，無需自己定制，同時元數據的同步也必須保證完全HA，不會因client問題而同步失敗。

2.2 QJM原理

2.2.1 QJM介紹

QJM全稱是Quorum Journal Manager, 由JournalNode(JN)組成，一般是奇數點結點組成。每個JournalNode對外有一個簡易的RPC接口，以供NameNode讀寫EditLog到JN本地磁盤。當寫EditLog時，NameNode會同時向所有JournalNode并行寫文件，只要有N/2+1結點寫成功則認為此次寫操作成功，遵循Paxos協議。其內部實現框架如下：

?

?

[ 圖3.QJM內部實現框架 ]

從圖中可看出，主要是涉及EditLog的不同管理對象和輸出流對象，每種對象發揮著各自不同作用：

FSEditLog：所有EditLog操作的入口
JournalSet: 集成本地磁盤和JournalNode集群上EditLog的相關操作
FileJournalManager: 實現本地磁盤上 EditLog 操作
QuorumJournalManager: 實現JournalNode 集群EditLog操作
AsyncLoggerSet: 實現JournalNode 集群 EditLog 的寫操作集合
AsyncLogger：發起RPC請求到JN，執行具體的日志同步功能
JournalNodeRpcServer：運行在 JournalNode 節點進程中的 RPC 服務，接收 NameNode 端的 AsyncLogger 的 RPC 請求。
JournalNodeHttpServer：運行在 JournalNode 節點進程中的 Http 服務，用于接收處于 Standby 狀態的 NameNode 和其它 JournalNode 的同步 EditLog 文件流的請求。

下面具體分析下QJM的讀寫過程。

2.2.2 QJM 寫過程分析

上面提到EditLog，NameNode會把EditLog同時寫到本地和JournalNode。寫本地由配置中參數dfs.namenode.name.dir控制，寫JN由參數dfs.namenode.shared.edits.dir控制，在寫EditLog時會由兩個不同的輸出流來控制日志的寫過程，分別為：EditLogFileOutputStream(本地輸出流)和QuorumOutputStream(JN輸出流)。寫EditLog也不是直接寫到磁盤中，為保證高吞吐，NameNode會分別為EditLogFileOutputStream和QuorumOutputStream定義兩個同等大小的Buffer，大小大概是512KB，一個寫Buffer(buffCurrent)，一個同步Buffer(buffReady)，這樣可以一邊寫一邊同步，所以EditLog是一個異步寫過程，同時也是一個批量同步的過程，避免每寫一筆就同步一次日志。

這個是怎么實現邊寫邊同步的呢，這中間其實是有一個緩沖區交換的過程，即bufferCurrent和buffReady在達到條件時會觸發交換，如bufferCurrent在達到閾值同時bufferReady的數據又同步完時，bufferReady數據會清空，同時會將bufferCurrent指針指向bufferReady以滿足繼續寫，另外會將bufferReady指針指向bufferCurrent以提供繼續同步EditLog。上面過程用流程圖就是表示如下：

?

?

[ 圖4.EditLog輸出流程圖 ]

這里有一個問題，既然EditLog是異步寫的，怎么保證緩存中的數據不丟呢,其實這里雖然是異步,但實際所有日志都需要通過logSync同步成功后才會給client返回成功碼，假設某一時刻NameNode不可用了，其內存中的數據其實是未同步成功的，所以client會認為這部分數據未寫成功。

第二個問題是，EditLog怎么在多個JN上保持一致的呢。下面展開介紹。

1.隔離雙寫：

在ANN每次同步EditLog到JN時，先要保證不會有兩個NN同時向JN同步日志。這個隔離是怎么做的。這里面涉及一個很重要的概念Epoch Numbers，很多分布式系統都會用到。Epoch有如下幾個特性：

當NN成為活動結點時，其會被賦予一個EpochNumber
每個EpochNumber是惟一的，不會有相同的EpochNumber出現
EpochNumber有嚴格順序保證，每次NN切換后其EpochNumber都會自增1，后面生成的EpochNumber都會大于前面的EpochNumber

QJM是怎么保證上面特性的呢，主要有以下幾點：

第一步，在對EditLog作任何修改前，QuorumJournalManager(NameNode上)必須被賦予一個EpochNumber
第二步， QJM把自己的EpochNumber通過newEpoch(N)的方式發送給所有JN結點
第三步， 當JN收到newEpoch請求后，會把QJM的EpochNumber保存到一個lastPromisedEpoch變量中并持久化到本地磁盤
第四步， ANN同步日志到JN的任何RPC請求(如logEdits(),startLogSegment()等)，都必須包含ANN的EpochNumber
第五步，JN在收到RPC請求后，會將之與lastPromisedEpoch對比，如果請求的EpochNumber小于lastPromisedEpoch,將會拒絕同步請求，反之，會接受同步請求并將請求的EpochNumber保存在lastPromisedEpoch

這樣就能保證主備NN發生切換時，就算同時向JN同步日志，也能保證日志不會寫亂，因為發生切換后，原ANN的EpochNumber肯定是小于新ANN的EpochNumber，所以原ANN向JN的發起的所有同步請求都會拒絕，實現隔離功能，防止了腦裂。

2. 恢復in-process日志

為什么要這步呢，如果在寫過程中寫失敗了，可能各個JN上的EditLog的長度都不一樣，需要在開始寫之前將不一致的部分恢復。恢復機制如下：

1 ANN先向所有JN發送getJournalState請求;

2 JN會向ANN返回一個Epoch(lastPromisedEpoch);

3 ANN收到大多數JN的Epoch后，選擇最大的一個并加1作為當前新的Epoch，然后向JN發送新的newEpoch請求，把新的Epoch下發給JN;

4 JN收到新的Epoch后，和lastPromisedEpoch對比，若更大則更新到本地并返回給ANN自己本地一個最新EditLogSegment起始事務Id,若小則返回NN錯誤;

5 ANN收到多數JN成功響應后認為Epoch生成成功，開始準備日志恢復;

6 ANN會選擇一個最大的EditLogSegment事務ID作為恢復依據，然后向JN發送prepareRecovery; RPC請求，對應Paxos協議2p階段的Phase1a，若多數JN響應prepareRecovery成功，則可認為Phase1a階段成功;

7 ANN選擇進行同步的數據源，向JN發送acceptRecovery RPC請求，并將數據源作為參數傳給JN。

8 JN收到acceptRecovery請求后，會從JournalNodeHttpServer下載EditLogSegment并替換到本地保存的EditLogSegment，對應Paxos協議2p階段的Phase1b，完成后返回ANN請求成功狀態。

9 ANN收到多數JN的響應成功請求后，向JN發送finalizeLogSegment請求，表示數據恢復完成，這樣之后所有JN上的日志就能保持一致。

數據恢復后，ANN上會將本地處于in-process狀態的日志更名為finalized狀態的日志，形式如edits[start-txid][stop-txid]。

3.日志同步

這個步驟上面有介紹到關于日志從ANN同步到JN的過程,具體如下：

1 執行logSync過程，將ANN上的日志數據放到緩存隊列中

2 將緩存中數據同步到JN，JN有相應線程來處理logEdits請求

3 JN收到數據后，先確認EpochNumber是否合法，再驗證日志事務ID是否正常，將日志刷到磁盤，返回ANN成功碼

4 ANN收到JN成功請求后返回client寫成功標識，若失敗則拋出異常

通過上面一些步驟，日志能保證成功同步到JN，同時保證JN日志的一致性，進而備NN上同步日志時也能保證數據是完整和一致的。

2.2.3 QJM讀過程分析

這個讀過程是面向備NN(SNN)的，SNN定期檢查JournalNode上EditLog的變化，然后將EditLog拉回本地。SNN上有一個線程StandbyCheckpointer，會定期將SNN上FSImage和EditLog合并，并將合并完的FSImage文件傳回主NN(ANN)上，就是所說的Checkpointing過程。下面我們來看下Checkpointing是怎么進行的。

在2.x版本中，已經將原來的由SecondaryNameNode主導的Checkpointing替換成由SNN主導的Checkpointing。下面是一個CheckPoint的流向圖:

?

?

[ 圖5.Checkpointing流向圖 ]

總的來說，就是在SNN上先檢查前置條件，前置條件包括兩個方面：距離上次Checkpointing的時間間隔和EditLog中事務條數限制。前置條件任何一個滿足都會觸發Checkpointing，然后SNN會將最新的NameSpace數據即SNN內存中當前狀態的元數據保存到一個臨時的fsimage文件( fsimage.ckpt)然后比對從JN上拉到的最新EditLog的事務ID，將fsimage.ckpt_中沒有，EditLog中有的所有元數據修改記錄合并一起并重命名成新的fsimage文件，同時生成一個md5文件。將最新的fsimage再通過HTTP請求傳回ANN。通過定期合并fsimage有什么好處呢，主要有以下幾個方面：

可以避免EditLog越來越大，合并成新fsimage后可以將老的EditLog刪除
可以避免主NN(ANN)壓力過大，合并是在SNN上進行的
可以保證fsimage保存的是一份最新的元數據，故障恢復時避免數據丟失

三、主備切換機制

要完成HA，除了元數據同步外，還得有一個完備的主備切換機制，Hadoop的主備選舉依賴于ZooKeeper。下面是主備切換的狀態圖：

?

?

[ 圖6.Failover流程圖 ]

從圖中可以看出，整個切換過程是由ZKFC來控制的，具體又可分為HealthMonitor、ZKFailoverController和ActiveStandbyElector三個組件。

ZKFailoverController: 是HealthMontior和ActiveStandbyElector的母體，執行具體的切換操作

HealthMonitor: 監控NameNode健康狀態，若狀態異常會觸發回調ZKFailoverController進行自動主備切換

ActiveStandbyElector: 通知ZK執行主備選舉，若ZK完成變更，會回調ZKFailoverController相應方法進行主備狀態切換

在故障切換期間，ZooKeeper主要是發揮什么作用呢，有以下幾點：

失敗保護：集群中每一個NameNode都會在ZooKeeper維護一個持久的session,機器一旦掛掉，session就會過期，故障遷移就會觸發

Active NameNode選擇：ZooKeeper有一個選擇ActiveNN的機制，一旦現有的ANN宕機，其他NameNode可以向ZooKeeper申請排他成為下一個Active節點

防腦裂： ZK本身是強一致和高可用的，可以用它來保證同一時刻只有一個活動節點

那在哪些場景會觸發自動切換呢，從HDFS-2185中歸納了以下幾個場景：

ActiveNN JVM奔潰：ANN上HealthMonitor狀態上報會有連接超時異常，HealthMonitor會觸發狀態遷移至SERVICE_NOT_RESPONDING, 然后ANN上的ZKFC會退出選舉，SNN上的ZKFC會獲得Active Lock, 作相應隔離后成為Active結點。

ActiveNN JVM凍結：這個是JVM沒奔潰，但也無法響應，同奔潰一樣，會觸發自動切換。

ActiveNN 機器宕機：此時ActiveStandbyElector會失去同ZK的心跳，會話超時，SNN上的ZKFC會通知ZK刪除ANN的活動鎖，作相應隔離后完成主備切換。

ActiveNN 健康狀態異常： 此時HealthMonitor會收到一個HealthCheckFailedException，并觸發自動切換。

Active ZKFC奔潰：雖然ZKFC是一個獨立的進程，但因設計簡單也容易出問題，一旦ZKFC進程掛掉，雖然此時NameNode是OK的，但系統也認為需要切換，此時SNN會發一個請求到ANN要求ANN放棄主結點位置，ANN收到請求后，會觸發完成自動切換。

ZooKeeper奔潰：如果ZK奔潰了，主備NN上的ZKFC都會感知斷連，此時主備NN會進入一個NeutralMode模式，同時不改變主備NN的狀態，繼續發揮作用，只不過此時，如果ANN也故障了，那集群無法發揮Failover, 也就不可用了，所以對于此種場景，ZK一般是不允許掛掉到多臺，至少要有N/2+1臺保持服務才算是安全的。

五、總結

上面介紹了下關于HadoopHA機制，歸納起來主要是兩塊：元數據同步和主備選舉。元數據同步依賴于QJM共享存儲，主備選舉依賴于ZKFC和Zookeeper。整個過程還是比較復雜的，如果能理解Paxos協議，那也能更好的理解這個。希望這篇文章能讓大家更深入了解關于HA方面的知識。

本文轉載自：http://www.raincent.com/content-85-9960-1.html

轉載于:https://www.cnblogs.com/zmanzi/p/10823374.html

總結

以上是生活随笔為你收集整理的Hadoop HA 机制学习：HA是怎么运作，QJM又是怎么发挥功效的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。