HDFS原理分析（二）—— HA機制 avatarnode原理

1、問題描述

因爲namenode 是HDFS的大腦，而這個大腦又是單點，若是大腦出現故障，則整個分佈式存儲系統就癱瘓了。HA（High Available）機制就是用來解決這樣一個問題的。碰到這麼個問題，首先本能的想到的就是冗餘備份，備份的方式有不少種，前輩們設計的有元數據備份方案，secondary namenode以及avatarnode等方案。而這些方案中最有優點的天然是可以讓HDFS以最短的時間完成故障切換的方案。也就是咱們今天要討論的avatarnode。

2、基本結構

primary：負責正常業務namenode，也就是爲client提供元數據查詢和操做。

standby：熱備的namenode，徹底備份primary的元數據，並對primary作checkpoint（一種元數據持久化機制，後面會介紹到）。

NFS：網絡文件服務器，primary會將日誌實時同步一份到該服務器，來保證primary出故障時備份元數據的完整性。

3、數據持久化機制——checkpoint

primary管理着全部的元數據，一般元數據都保存在內存裏，這樣對元數據的訪問可以高效。可是有個隱患，就是若是primary節點宕機了，或者掉電了，那麼全部的元數據就一去不復返了。若是咱們可以把元數據在內存裏保存一份，同時在硬盤上也保存一份，那麼即便掉電也能將數據再恢復過來。

checkpoint機制就是將元數據實時在硬盤上保存一份的機制。

首先介紹幾個關鍵概念：

edits：日誌文件，記錄引起元數據改變的操做。

fsimage：元數據的鏡像文件，能夠理解爲元數據保存在磁盤上的一個副本。

問題1：fsimage表明的是某一時刻的元數據鏡像，元數據在不斷改變，那麼這個鏡像是如何實時更新的呢？

問題2：如何在保證primary namenode正常對外服務的狀況下生成fsimage？

checkpoint步驟以下：

第一步：secondary namenode請求namenode中止使用edits，暫時記錄在edits.new文件中

第二步：secondary namenode從namenode複製fsimage、edits到本地

第三步：secondary namenode合併fsimage、edits爲fsimage.ckpt

第四步：secondary namenode發送fsimage.ckpt到namenode

第五步：namenode用新的fsimage覆蓋舊的fsimage，用新的edits覆蓋舊的edits

第六步：更新checkpoint時間

到這裏fsimage更新完畢，即保證了primary正常服務，也完成了fsimage的更新

4、avatarnode元數據的一致性

checkpoint只是保證了元數據的持久化，可是若是primary出現故障，修復後仍是要花大量的時間來加載fsimage，如何讓standby在內存中就和primary保持元數據同步，就是一個高可用的HDFS須要解決的問題。

namenode的元數據其實包括兩個部分：

第一部分：目錄樹，目錄樹管理着HDFS中存儲的全部的文件信息。

第二部分：塊數據和datanode的對應關係

只要可以保證以上兩部分的數據一致了，那麼元數據的一致性問題就解決了。

第一部分：primary將日誌實時同步到NFS上，而standby能夠實時讀取NFS上的日誌，經過日誌回放，能夠解決目錄樹信息一致的問題。

第二部分：快數據和datanode的對應關係，是全部datanode想namenode彙報總結出來的，那麼讓全部的datanode向兩個namenode彙報，就能夠解決塊數據和datanode的對應關係一致性問題。

問題：新引入的NFS會帶來新的單點問題。據facebook工程師統計，這個單點故障率很是之低，他們在四年中之碰到一次。

 

到這裏avatarnode原理基本講完，可是實際應用中還存在幾個問題：

一、HDFS是如何快速檢測到primary出現故障的？

二、standby是如何迅速從備用機切換到primary的？