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行。如下：
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
Defaultblock replication. The actual number of replicationscan bespecified when the file is created. The default isused ifreplicationis not specified in create time
参数说明：
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
参数说明：
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的原理是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
