Hadoop集群安全性：Hadoop中Namenode单点故障的解决方案及详细介绍AvatarNode
正如大家所知，NameNode在Hadoop系统中存在单点故障问题，这个对于标榜高可用性的Hadoop来说一直是个软肋。本文讨论一下为了解决这个问题而存在的几个solution。
1.SecondaryNameNode
原理：SecondaryNN会定期的从NN中读取editlog，与自己存储的Image进行合并形成新的metadataimage
优点：Hadoop较早的版本都自带，配置简单，基本不需要额外资源（可以与datanode共享机器）
缺点：恢复时间慢，会有部分数据丢失
2.BackupNameNode
原理：backupNN实时得到editlog，当NN宕掉后，手动切换到BackupNN；
优点：从hadoop0.21开始提供这种方案，不会有数据的丢失
缺点：因为需要从DataNode中得到Block的location信息，在切换到BackupNN的时候比较慢（依赖于数据量）
3.AvatarNameNode
原理：这是Facebook提供的一种HA方案，将client访问hadoop的editlog放在NFS中，StandbyNN能够实时拿到editlog；DataNode需要同时与ActiveNN和StandbyNNreportblock信息；
http://www.aboutyun.com/data/attachment/forum/201402/04/161823kj071bn07b7g14kj.jpg
优点：信息不会丢失，恢复快（秒级）
缺点：Facebook基于Hadoop0.2开发的，部署起来稍微麻烦；需要额外的机器资源，NFS成为又一个单点（不过故障率低）
4.Hadoop2.0直接支持StandByNN，借鉴Facebook的Avatar，然后做了点改进
http://www.aboutyun.com/data/attachment/forum/201402/04/161825sk9n33nujm93dmnm.png
优点：信息不会丢失，恢复快（秒级），部署简单
详细介绍HadoopNameNode单点问题解决方案之一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.41AvatarNode(primary)
hadoop2-192.168.64.42AvataDataNode
hadoop3-192.168.64.43AvataDataNode
hadoop4-192.168.64.67AvatarNode(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">
<!--failmessage="'forrest.home'isnotdefined.Pleasepass-Dforrest.home=<baseofApacheForrestinstallation>toAntonthecommand-line."/-->
</target>
<targetname="java5.check"unless="java5.home">
<!--failmessage="'java5.home'isnotdefined.ForrestrequiresJava5.Pleasepass-Djava5.home=<baseofJava5distribution>toAntonthecommand-line."/-->
</target>
2.在根目录下输入antjar（对于编译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"?>
<!--Putsite-specificpropertyoverridesinthisfile.-->
<configuration>
<property>
<name>dfs.name.dir</name>
<value>/data/hadoop/hdfs/name</value>
<description>DetermineswhereonthelocalfilesystemtheDFSnamenodeshouldstorethenametable.Ifthisisacomma-delimitedlistofdirectoriesthenthenametableisreplicatedinallofthedirectories,forredundancy
</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的httpserver端口</description>
</property>
<property>
<name>dfs.datanode.ipc.address</name>
<value>0.0.0.0:50021</value>
<description>默认为50020,为datanode的ipcserver端口</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>
Defaultblockreplication.Theactualnumberofreplicationscanbespecifiedwhenthefileiscreated.Thedefaultisusedifreplicationisnotspecifiedincreatetime
</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-specificpropertyoverridesinthisfile.-->
<configuration>
<property>
<name>hadoop.tmp.dir</name>
<value>/home/hadoop/tmp</value>
<description>Abaseforothertemporarydirectories.
</description>
</property>
<property>
<name>fs.default.name</name>
<value>hdfs://192.168.64.41:9600</value>
<description>Thenameofthedefaultfilesystem.Eithertheliteralstring"local"orahost:portforDFS.
</description>
</property>
<property>
<name>fs.default.name0</name>
<value>hdfs://192.168.64.41:9600</value>
<description>Thenameofthedefaultfilesystem.Eithertheliteralstring"local"orahost:portforDFS.
</description>
</property>
<property>
<name>fs.default.name1</name>
<value>hdfs://192.168.64.67:9600</value>
<description>Thenameofthedefaultfilesystem.Eithertheliteralstring"local"orahost:portforDFS.
</description>
</property>
</configuration>
参数说明：
1)fs.default.name
当前AvatarNodeIP地址和端口号，即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与Standbyshared0目录的数据共享。有关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/hadooporg.apache.hadoop.hdfs.server.namenode.AvatarNode，后面可选参数有
[-standby]|[-sync]|[-zero]|[-one]|[-format]|[-upgrade]|[-rollback]|[-finalize]|[-importCheckpoint]
##查看当前AvatarNode的状态
1)bin/hadooporg.apache.hadoop.hdfs.AvatarShell–showAvatar
##primary把当前Standby节点升级Primary节点
2)bin/hadooporg.apache.hadoop.hdfs.AvatarShell-setAvatar
3)bin/hadooporg.apache.hadoop.hdfs.AvatarShell-setAvatarstandby
集群测试
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那种自由切换。