Hadoop集羣安全性：Hadoop中Namenode單點故障的解決方案及詳介AvatarNode

時間 2019-11-15

標籤 hadoop 集羣安全性 namenode 單點故障解決方案 avatarnode 欄目 Hadoop 简体版

原文原文鏈接

正如你們所知，NameNode在Hadoop系統中存在單點故障問題，這個對於標榜高可用性的Hadoop來講一直是個軟肋。本文討論一下爲了解決這個問題而存在的幾個solution。java

1. Secondary NameNodenode

原理：Secondary NN會按期的從NN中讀取editlog，與本身存儲的Image進行合併造成新的metadata imagegit

優勢：Hadoop較早的版本都自帶，配置簡單，基本不須要額外資源（能夠與datanode共享機器）github

缺點：恢復時間慢，會有部分數據丟失web

2. Backup NameNodeshell

原理：backup NN實時獲得editlog，當NN宕掉後，手動切換到Backup NN；apache

優勢：從hadoop0.21開始提供這種方案，不會有數據的丟失服務器

缺點：由於須要從DataNode中獲得Block的location信息，在切換到Backup NN的時候比較慢（依賴於數據量）less

3. Avatar NameNodeide

原理：這是Facebook提供的一種HA方案，將client訪問hadoop的editlog放在NFS中，Standby NN可以實時拿到editlog；DataNode須要同時與Active NN和Standby NN report block信息；

優勢：信息不會丟失，恢復快（秒級）

缺點：Facebook基於Hadoop0.2開發的，部署起來稍微麻煩；須要額外的機器資源，NFS成爲又一個單點（不過故障率低）

4. Hadoop2.0直接支持StandBy NN，借鑑Facebook的Avatar，而後作了點改進

優勢：信息不會丟失，恢復快（秒級），部署簡單

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

詳細介紹Hadoop NameNode單點問題解決方案之一 AvatarNode

需求：

實現namenode元數據的備份，解決namenode單點宕機致使集羣不可用的問題。

方案描述：

當namenode所在服務器宕機的時候，咱們能夠利用namenode備份的元數據迅速重構新的namenode來投入使用。

1. Hadoop 自己提供了可利用secondarynamenode的備份數據來恢復namenode的元數據的方案，但由於checkpoint(在每次 checkpoint的時候secondarynamenode纔會合併並同步namenode的數據)的問題，secondarynamenode的備份數據並不能時刻保持與namenode同步，也就是說在namenode宕機的時候secondarynamenode可能會丟失一段時間的數據，這段時間取決於checkpoint的週期。咱們能夠減少checkpoint的週期來減小數據的丟失量，但因爲每次checkpoint很耗性能，並且這種方案也不能從根本上解決數據丟失的問題。因此若是需求上不容許這種數據的丟失，這種方案可直接不予考慮。

2. Hadoop 提供的另外一種方案就是NFS，一種即時備份namenode元數據的方案，設置多個data目錄（包括NFS目錄），讓namenode在持久化元數據的時候同時寫入多個目錄，這種方案較第一種方案的優點是能避免數據的丟失（這裏咱們暫時不討論NFS自己會丟失數據的可能性，畢竟這種概率很小很小）。既然能夠解決數據丟失的問題，說明這套方案在原理上是可行的

下載源碼

https://github.com/facebook/hadoop-20

部署環境

機器4臺

hadoop1-192.168.64.41 AvatarNode(primary)

hadoop2-192.168.64.42 AvataDataNode

hadoop3-192.168.64.43 AvataDataNode

hadoop4- 192.168.64.67 AvatarNode(standby)

相關資源及描述

如下是Avatar方案部署相關的簡單介紹。

1.首先關於Avatar方案對於Hadoop的備份是對Dfs的的單點備份，並不包括Mapred，由於Hadoop自己就不存在處理jobtracker單點故障的機制。

2.AvatarNode繼承自Namenode，而並不是對Namenode的修改，AvatarDataNode一樣亦如此。故Avatar的啓動機制是獨立於Hadoop自己的啓動機制。

3.在Avatar方案中，SecondaryNamenode的職責已包括在Standby節點中，故不須要再獨立啓動一個SecondaryNamenode。

4.AvatarNode必須有NFS的支持，用以實現兩個節點間事務日誌(editlog)的共享。

5.FB提供的Avatar源碼中暫時並不能實現Primary和Standby之間的自動切換，能夠藉助於Zookeeper的lease機制來實現自動切換。

6.Primary和Standby之間的切換隻包括從Standby切換到Primary，並不支持從Primary狀態切換到Standby狀態。

7.AvatarDataNode並不使用VIP和AvatarNode通訊，而是直接與Primary及Standby通訊，故須要使用VIP漂移方案來屏蔽兩個節點間切換過程當中的IP變換問題。有關與Zookeeper的整合，官方稱將在以後的版本發佈。

關於AvatarNode更詳細的介紹，請參考http://blog.csdn.net/rzhzhz/article/details/7235789，

3、編譯

1. 首先修改hadoop根目錄下build.xml，註釋掉996行和1000行。以下：

<targetname="forrest.check"unless="forrest.home"depends="java5.check">

</target>

</target>

2. 在根目錄下輸入ant jar（對於編譯package能夠參考build.xml的代碼）編譯hadoop，編譯後的jar包會在build目錄下（hadoop- 0.20.3-dev-core.jar），拷貝該jar包到hadoop根目錄下替換到原有的jar （囉嗦一句，hadoop啓動時會先加載build目錄下的class，因此當經過替換class修改jar包時請先把build目錄暫時移除掉）。

3. 進入src/contrib/highavailability目錄下編譯Avatar，編譯後的jar包會在build/contrib/highavailability目錄下(hadoop-${version}- highavailability.jar)，拷貝該jar包到lib目錄下。

4. 把2,3步中編譯好的jar包分發到集羣中全部機器的相應目錄。

4、配置

1. 配置hdfs-site.xml

<?xmlversion="1.0"?>

<?xml-stylesheettype="text/xsl"href="configuration.xsl"?>

<value>/data/hadoop/hdfs/name</value>

<description>Determineswhereon the local filesystem the DFS name node shouldstore the name table. Ifthis is a comma-delimited list ofdirectories then the name tableis replicated in all of thedirectories, for redundancy

</description>

</property>

<value>/data/hadoop/facebook_hadoop_data/hdfs/data</value>

</property>

<name>dfs.datanode.address</name>

<description>默認爲50010, 是datanode的監聽端口</description>

</property>

<name>dfs.datanode.http.address</name>

<description>默認爲50075，爲datanode的http server端口</description>

</property>

<name>dfs.datanode.ipc.address</name>

<description>默認爲50020, 爲datanode的ipc server端口</description>

</property>

<name>dfs.http.address0</name>

</property>

<name>dfs.http.address1</name>

</property>

<name>dfs.name.dir.shared0</name>

<value>/data/hadoop/share/shared0</value>

</property>

<name>dfs.name.dir.shared1</name>

<value>/data/hadoop/share/shared1</value>

</property>

<name>dfs.name.edits.dir.shared0</name>

<value>/data/hadoop/share/shared0</value>

</property>

<name>dfs.name.edits.dir.shared1</name>

<value>/data/hadoop/share/shared1</value>

</property>

<name>dfs.replication</name>

Defaultblock replication. The actual number of replicationscan bespecified when the file is created. The default isused ifreplicationis not specified in create time

</description>

</property>

</configuration>

參數說明：

1) dfs.name.dir.shared0

AvatarNode(Primary)元數據存儲目錄,注意不能和dfs.name.dir目錄相同

2) dfs.name.dir.shared1

AvatarNode(Standby)元數據存儲目錄,注意不能和dfs.name.dir目錄相同

3) dfs.name.edits.dir.shared0

AvatarNode(Primary) edits文件存儲目錄，默認與 dfs.name.dir.shared0一致

4) dfs.name.edits.dir.shared1

AvatarNode(Standby) edits文件存儲目錄，默認與 dfs.name.dir.shared1一致

5) dfs.http.address0

AvatarNode(Primary) HTTP的監控地址

6) dfs.http.address1

AvatarNode(Standby) HTTP的監控地址

7) dfs.namenode.dn-address0/dfs.namenode.dn-address1

雖然在Avatar源碼中有所涉及，但暫時並未用到

2. 配置core-site.xml

<?xmlversion="1.0"?>

<?xml-stylesheettype="text/xsl"href="configuration.xsl"?>

<name>hadoop.tmp.dir</name>

<value>/home/hadoop/tmp</value>

<description>A baseforother temporary directories.

</description>

</property>

<name>fs.default.name</name>

<description>The name ofthedefault file system. Eitherthe literal string"local" or a host:port for DFS.

</description>

</property>

<name>fs.default.name0</name>

<description>The name ofthedefault file system. Eitherthe literal string"local" or a host:port for DFS.

</description>

</property>

<name>fs.default.name1</name>

<description>The name ofthedefault file system. Eitherthe literal string"local" or a host:port for DFS.

</description>

</property>

</configuration>

參數說明：

1) fs.default.name

當前AvatarNode IP地址和端口號，即Primary和Standby的配置爲各自的IP地址和端口號。

2) fs.default.name0

AvatarNode(Primary) IP地址和端口號

3) fs.default.name1

AvatarNode(Standby) IP地址和端口號

3. 由於不涉及到mapred，故mapred-site.xml不用做修改，爲原有集羣配置便可。

4. 分發修改後的配置文件到集羣節點並在Primary和Standby節點上創建好配置文件中相應目錄。

5. 創建NFS，實現Primary與Standby shared0目錄的數據共享。有關NFS的配置請參考http://blog.csdn.net/rzhzhz/article/details/7056732

6. 格式化Primary與Standby，這裏能夠採用hadoop自己的格式化命令，也能夠採用AvatarNode的格式化命令（bin/hadooporg.apache.hadoop.hdfs.AvatarShell -format），但此時shared1目錄不能爲空，此處有點多餘。建議採用hadoop自己的格式化命令在Primary上格式化後，而且把name 目錄下的文件複製到shared0目錄下。而後再在Standby上覆制shared0目錄下的文件到shared1目錄下。

5、啓動

1. 因爲不涉及jobtracker的單點，在這裏咱們只啓動hdfs相關線程。Primary，Standby兩個namenode（此處Standby包括SecondaryNamenode的職責）和3個AvatarDataNode數據節點。

2. 在Primary節點hadoop根目錄下啓動AvatarNode（Primary）

bin/hadooporg.apache.hadoop.hdfs.server.namenode.AvatarNode–zero

3. 在Standby節點hadoop根目錄下啓動AvatarNode（Standby）

bin/hadooporg.apache.hadoop.hdfs.server.namenode.AvatarNode-one–standby

4. 依次在數據節點hadoop根目錄下啓動AvatarDataNode

bin/hadooporg.apache.hadoop.hdfs.server.datanode.AvatarDataNode

5. 其餘相關命令

bin/hadoop org.apache.hadoop.hdfs.server.namenode.AvatarNode，後面可選參數有

##查看當前AvatarNode的狀態

1) bin/hadoop org.apache.hadoop.hdfs.AvatarShell –showAvatar

##primary 把當前Standby節點升級Primary節點

2) bin/hadooporg.apache.hadoop.hdfs.AvatarShell -setAvatar

3) bin/hadooporg.apache.hadoop.hdfs.AvatarShell -setAvatar standby

集羣測試

1. 訪問集羣的web頁

(Primary)http://hadoop1-virtual-machine:50070

(Standby)http://hadoop5-virtual-machine:50070

可見全部的AvatarDataNode都已註冊到兩個namenode，Primary處於正常狀態，而Standby處於Safemode狀態，只可讀不可寫。可經過AvatarShell命令查看當前AvatarNode的狀態（Primary或Standby）。

2. 存儲相關數據到集羣，集羣正常工做。

3. Kill掉Primary節點的AvatartNode線程，在Standby把當前升級爲Prirmary,數據並未丟失，集羣正常工做（此時 web端不能正常訪問文件系統，經過shell命令可查看集羣數據）。但因爲Avatar有轉換限制，只能由Standby轉換成Primary，故一次故障後,由Standby上升爲Primary的節點並不能從新降級爲Standby，因此不能實現像Master/Slave那種自由切換。