Hadoop中Namenode單點故障的解決方案及AvatarNode的原理是什么

這篇文章給大家介紹Hadoop中Namenode單點故障的解決方案及AvatarNode的原理是什么，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

正如大家所知，NameNode在Hadoop系統中存在單點故障問題，這個對于標榜高可用性的Hadoop來說一直是個軟肋。小編討論一下為了解決這個問題而存在的幾個solution。

1. Secondary NameNode

原理：Secondary NN會定期的從NN中讀取editlog，與自己存儲的Image進行合并形成新的metadata image

優點：Hadoop較早的版本都自帶，配置簡單，基本不需要額外資源（可以與datanode共享機器）

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

2. Backup NameNode

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

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

缺點：因為需要從DataNode中得到Block的location信息，在切換到Backup NN的時候比較慢（依賴于數據量）

3. Avatar NameNode

原理：這是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，

三、編譯

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

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

<!--fail message="'forrest.home' is not defined. Pleasepass-Dforrest.home=<base of Apache Forrest installation> to Antonthe command-line." /-->

</target>

<target name="java5.check" unless="java5.home">

<!--fail message="'java5.home' is not defined.  Forrest requires Java 5. Please pass -Djava5.home=<base of Java5 distribution> to Ant onthe command-line." /-->

</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包分發到集群中所有機器的相應目錄。

四、配置

1.     配置hdfs-site.xml

<?xmlversion="1.0"?>

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

<!-- Put site-specificproperty overrides in thisfile. -->

<configuration>

       <property>

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

               <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>

<property>

               <name>dfs.data.dir</name>

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

</property>

<property>

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

  <value>0.0.0.0:50011</value>

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

</property>

<property>

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

  <value>0.0.0.0:50076</value>

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

</property>

<property>

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

  <value>0.0.0.0:50021</value>

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

</property>

       <property>

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

               <value>192.168.64.41:50070</value>

       </property>

       <property>

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

               <value>192.168.64.67:50070 </value>

       </property>

       <property>

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

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

       </property>

       <property>

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

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

       </property>

       <property>

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

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

       </property>

       <property>

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

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

       </property>

       <property>

           <name>dfs.replication</name>

               <value>2</value>

   <description>

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"?>

<!-- Putsite-specificproperty overrides in this file. -->

<configuration>

       <property>

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

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

               <description>A baseforother temporary directories.

               </description>

       </property>

       <property>

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

               <value>hdfs://192.168.64.41:9600</value>

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

               </description>

       </property>

       <property>

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

               <value>hdfs://192.168.64.41:9600</value>

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

               </description>

       </property>

       <property>

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

               <value>hdfs://192.168.64.67:9600</value>

               <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目錄下。

五、啟動

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，后面可    選參數有

[-standby] | [-sync] |[-zero] | [-one] | [-format] |  [-upgrade]   | [-rollback] |[-finalize] | [-importCheckpoint]

  ##查看當前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那種自由切換。

關于Hadoop中Namenode單點故障的解決方案及AvatarNode的原理是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。