Hadoop2.0中HDFS高可用性的实现原理

在Hadoop1.0中,NameNode在HDFS集群中存在单点故障问题,每一个集群中只存在一个NameNode,如果NameNode所在的机器出现故障,那么整个集群就无法利用,直到NameNode重启或在另一台主机上启动NameNode守护进程。因此,有两个因素影响了HDFS的高可用性:
(1)、在不可预知的情况下,如果NameNode所在的机器崩溃了,整个集群将无法利用,直到NameNode被重启。
(2)、在可预知的情况下,比如NameNode所在的机器硬件或软件需要升级,将导致整个集群宕机。

在Hadoop2.0中,通过在一个集群中运行两个NameNode(active NN,standbyNN),解决了上面的两个问题:如果active NN所在机器崩溃或需要维护,可以快速的启动standby NN来恢复正常。

在典型的HA集群中,通常有两台不同的机器作为NameNode,不过只有一台处于Active状态,另一台则处于Standby状态,Active NN负责集群中所有客户端的操作,而Standby NN用于备用。

为了让Standby NN和Active NN保持同步(元数据保持一致),它们都将会和JournalNodes守护进程通信。当Active NN执行任何有关命名空间的修改的 操作时,它需要持久化到一半以上的JournalNodes上(通过edits log持久化存储),而Standby NN负责观察edits log的变化,它能够从JournalNodes中读取edits的信息,并更新自己的命名空间。一旦Active NN出现故障,Standby NN将会保证从JournalNodes读取了全部的edits(保证和Active NN拥有完全同步的命名空间状态),并切换为Active状态。

在这里插入图片描述
namenode想要做HA,一个namenode挂掉以后,另一个namenode想要快速接替,就必须同步数据。 数据由两部分产生,一部分来自客户端,另一部分来自
DataNode,DataNode的数据由datanode同时向两台namenode发送数据,同时做心跳连接,是一致保持一致的。另外一部分原数据(即客户端原数据)
想要保持一致只需借助一个组件(journalnode),当客户端发送来数据的时候,由组件记录数据,并异步同步到另一台namenode上即可。

1)namenode总共两种数据,动态的和静态的,由客户端产生的动态数据和由data产生的静态数据

2)datanode同时向两个namenode发送心跳,同步block的位置信息

3)journalnode是HDFS自己带的一个角色。每个journalnode是一个进程,journalnode使用集群可避免单点故障,journalnode技术类似于linux系统的NFS(挂载network FileSystem)。

4)同步客户端源数据的原理:假设有三台journalnode,客户端发送来数据,会向三台journalnode上面写数据,当有过半的journalnode写成功就默认写成功了(过半机制)。之后会把数据同步到
另一台namenode上,这样两台namenode上的数据就会保持一致了,一台挂掉,另一台可以迅速的接替。

5)完成这个已经是HA,一个namenode是active,一个namenode是standy,只是还不是自动的,当其中一个namenode挂掉后,要手动的把另一个启动起来变成active。一般企业都会使用zookeeper
集群做成自动的

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值