保證HDFS高可用是Hadoop被推廣以來很多技術人員一直關心的問題，通過搜索引擎搜索也可以得到很多的方案。恰逢HDFSFederation出爐，本文將一些涉及到有關NameNode、SecondaryNameNode、BackupNode的含義與區別，以及HDFSHA框架做一個總結。除此之外，文章的最後，將介紹Hadoop-0.23.0如何配置NameNode、SecondaryNameNode、以及BackupNode。
1、HDFS元數據服務器如何工作？
Namenode在第一次啓動時刻之前，進行格式化，$bin/hdfs namenode -format -clusteridyourid按照需求生成VERSION：例如我Hadoop0.23.0初探2中使用gb17作爲namenode，在format之後會在dfs.hadoop.name.dir目錄中生成如下的VERSION
$ cat /opt/jiangbing/hdfs23/current/VERSION
#Thu Dec 08 16:27:30 CST 2011
namespaceID=1787450988
clusterID=klose
cTime=0
storageType=NAME_NODE
blockpoolID=BP-950324238-10.10.102.17-1322483515854
layoutVersion=-38
可以看到比之前的Hadoop-0.21.0的HDFS中多了一個blockpoolID和clusteID，VERSION有點像NameNode的身份證。每次-format就代表NameNode出生了。
在-format同時，會生成fsimage_**和edits_**兩個文件。使用$bin/hdfsnamenode會按照正常的方式啓動NameNode。
fsimage：元數據的snapshot
editsLog：元數據的操作
當NameNode啓動時，會從鏡像文件 fsimage中讀取HDFS的狀態，並且把edits文件中記錄的操作應用到fsimage，也就是合併到fsimage中去。合併後更新fsimage的HDFS狀態，清空的edits文件來記錄文件系統的變化。因此在NameNode啓動過程中，namenode處於safemode模式，只能提供讀操作，不提供寫操作，等啓動完成會從safemode模式退出。因此，NameNode在正常情況下不會合並edits到fsimage上，作checkpoint的。這會造成系統edits文件越來越大。這樣當需要重啓NameNode時，你會發現啓動過程會非常長。
2、SecondaryNameNode不是NameNode熱備
SNN主要是備份NN的文件信息，不備份數據塊的信息。它從NN上獲取fsimage和edits文件，將fsimage與edits日誌合併成一個新的fsimage，再將新的fsimage上傳給NN,這樣使得NN中的edits不會一直是遞增的，可以使NN的重啓過程變得輕鬆。
SNN的主要工作在 doCheckpoint()方法中，每隔一段時間會啓動檢查點一次，是由兩個配置參數來控制的：
fs.checkpoint.period，指定連續兩次檢查點的最大時間間隔，默認值是1小時。
fs.checkpoint.size定義了edits日誌文件的最大值，一旦超過這個值會導致強制執行檢查點（即使沒到檢查點的最大時間間隔）。默認值是 64MB。
3、BackupNode強調實時同步
這個結點的模式有點像mysql中的主從結點複製功能，NN可以實時的將日誌傳送給BN，而SNN是每隔一段時間去NN下載fsimage和edits文件，而BN是實時的得到操作日誌，然後將操作合併到fsimage裏。
在NN裏提供了二個日誌流接口： EditLogOutputStream 和 EditLogInputStream。即當NN有日誌時，不僅會寫一份到本地edits的日誌文件，同時會向BN的網絡流中寫一份，當流緩衝達到閥值時，將會寫入到BN結點上，BN收到後就會進行合併操作，這樣來完成低延遲的日誌複製功能。
4、BN與SNN的區別
1）獲取NN中元數據的方式不同。
NN會把fsimage和edits更新flush到BN的機器，實時性好。這樣在NN宕機之後，BN擁有了基本一致的元數據。SNN是通過httpserver獲取fsimage和edits的內容，因此，數據完成程度受到了fetch文件頻率的影響。
2）對checkpoint結果的處理方式不同。
SNN會主動把checkpoint之後的fsimage發送給NN，而BN只在本地作checkpoint，存在本地的dfs.name.dir中，其實它就相當於一個NameNode的熱備，只是DataNode還沒有認識到它的存在，如果你是程序員的話，你應該知道怎麼辦。:-)
5、一些HDFS HA的方案
1）對於dfs.name.dir目錄設置RAID。
2）設置多個dfs.name.dir目錄，將其中的一個目錄設置爲其它節點通過NFS掛載到該機器的目錄。這樣會同時寫兩份同樣的數據。這樣綁定一個ZooKeeper來跟蹤NameNode的狀況，在主NameNode宕機之後，
StandbyNameNode切換成正常的NameNode，爲了簡單，standbyNameNode開始只需監聽Zookeeper的事件即可，在出錯之後，迅速正常啓動一個NameNode。DataNode在鏈接失效之後，要從Zookeeper獲得更新的NameNode的URL，這塊需要一點編碼。:-)，如果一點都不動，我們就找不到工作了...下圖是一個示意圖。
3）另外是一些做法稍微複雜一些。請參閱：
http://www.cloudera.com/blog/2009/07/hadoop-ha-configuration/
http://hadoopblog.blogspot.com/2010/02/hadoop-namenode-high-availability.html
6、Hadoop-0.23.0 HDFS中SNN、BN的配置
1）SNN的配置，這個非常簡單，修改所有機器下的conf/hdfs-site.xml文件：
${HDFS_CONF_DIR}/hdfs-site.xml
<configuration> <property> <name>dfs.namenode.name.dir</name> <value>file:///opt/jiangbing/hdfs23</value> </property> <property> <name>dfs.federation.nameservices</name> <value>ns1,ns2</value> </property> <property> <name>dfs.namenode.rpc-address.ns1</name> <value>gb17:9000</value> </property> <property> <name>dfs.namenode.http-address.ns1</name> <value>gb17:23001</value> </property> <property> <name>dfs.namenode.secondary.http-address.ns1</name> <value>gb17:23002</value> </property> <property> <name>dfs.namenode.rpc-address.ns2</name> <value>gb18:9000</value> </property> <property> <name>dfs.namenode.http-address.ns2</name> <value>gb18:23001</value> </property> <property> <name>dfs.namenode.secondary.http-address.ns2</name> <value>gb18:23002</value> </property> <property> <name>fs.checkpoint.period</name> <value>600</value> <description>The number of seconds between two periodic checkpoints. </description> </property> <property> <name>fs.checkpoint.size</name> <value>67108864</value> <description>The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fs.checkpoint.period hasn't expired. </description> </property> </configuration>如果需要的話，還可以設置dfs.name.checkpoint.dir的路徑，默認以hadoop.tmp.dir爲目錄建立對應的checkpoint目錄。
其餘配置與Hadoop0.23.0初探2闡述的內容相同，使用sbin/start-dfs.sh啓動即可。
2）sbin/start-dfs.sh不會從配置文件中讀取backupNode的信息，然後啓動它。因此，在設置dfs的內容處，需要在一個節點單獨的配置。請注意，設置backupNode時，它的配置文件conf/hdfs-site.xml有了一點差別，其實所有的節點的配置文件都設置成backupNode的節點的情況也沒有問題，因爲腳本不會獨立地啓動backupNode。
<configuration> <property>這裏設置gb22作爲ns1的namenode的backupNode，注意這裏backupNode與NameNode共有NameNode.dir的目錄，這也可以認爲BackupNode就是NameNode的孿生兄弟，這是這個兄弟不負責外面的哪些事兒（DataNode的rpc鏈接）。
<name>dfs.namenode.name.dir</name>
<value>file:///opt/jiangbing/hdfs23/backup</value>
</property>
<property>
<name>dfs.federation.nameservice.id</name>
<value>ns1</value>
</property> <property>
<name>dfs.namenode.backup.address.ns1</name>
<value>gb22:50100</value>
<description>
The backup node server address and port.
If the port is 0 then the server will start on a free port.
</description>
</property>
<property>
<name>dfs.namenode.backup.http-address.ns1</name>
<value>gb22:50105</value>
<description>
The backup node http server address and port.
If the port is 0 then the server will start on a free port.
</description>
</property> <property> <name>dfs.federation.nameservices</name> <value>ns1,ns2</value> </property> <property> <name>dfs.namenode.rpc-address.ns1</name> <value>gb17:9000</value> </property> <property> <name>dfs.namenode.http-address.ns1</name> <value>gb17:23001</value> </property> <property> <name>dfs.namenode.secondary.http-address.ns1</name> <value>gb18:23002</value> </property> <property> <name>dfs.namenode.rpc-address.ns2</name> <value>gb18:9000</value> </property> <property> <name>dfs.namenode.http-address.ns2</name> <value>gb18:23001</value> </property> <property> <name>fs.checkpoint.period</name> <value>60</value> <description>The number of seconds between two periodic checkpoints.</description> </property> <property> <name>fs.checkpoint.size</name> <value>67108864</value> <description>The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fs.checkpoint.period hasn't expired. </description> </property> <property> <name>dfs.namenode.secondary.http-address.ns2</name> <value>gb17:23002</value> </property> </configuration>
在gb22上啓動backupNode，$bin/hdfs namenode -backup
通過$bin/hadoop fs -ls hdfs://gb22:50100 可以獲得與$bin/hadoop fs -lshdfs://gb17:9000
一樣的內容，元數據內容在gb17，gb22完成了。這樣在gb17宕機之後，只需停掉gb22backupNode，重新配置一下ns1的位置，這樣服務就可以繼續了。其實這是一個不用任何代碼開發的方案。但是需要暫停一下服務。對於這樣的HA，你們可以接受嗎？:-)
文章來自於klose blog
本文是參閱了Hadoop-0.23.0的源碼而來，有這方面問題的朋友可以聯繫作者，作者的郵箱在文章的參考文獻之後給出。
參考文獻：
[1]http://blog.csdn.net/lance_123/article/details/6114270
[2]http://www.cloudera.com/blog/2009/07/hadoop-ha-configuration/
[3]http://hadoopblog.blogspot.com/2010/02/hadoop-namenode-high-availability.html