请选择 进入手机版 | 继续访问电脑版

[其它综合] 详细 讲解HDFS的高可用机制

[复制链接]
查看99 | 回复18 | 2021-9-12 16:59:20 | 显示全部楼层 |阅读模式
目次

在Hadoop2.X之前,Namenode是HDFS集群中大概 发生单点故障的节点,每个HDFS集群只有一个namenode,一旦这个节点不可用,则整个HDFS集群将处于不可用状态。
HDFS高可用(HA)方案就是为相识 决上述标题 而产生的,在HA HDFS集群中会同时运行两个Namenode,一个作为活动的Namenode(Active),一个作为备份的Namenode(Standby)。备份的Namenode的定名 空间与活动的Namenode是及时 同步的,以是 当活动的Namenode发生故障而制止 服务时,备份Namenode可以立刻 切换为活动状态,而不影响HDFS集群服务。

这里写图片形貌
 

在一个HA集群中,会设置 两个独立的Namenode。在恣意 时间 ,只有一个节点作为活动的节点,另一个节点则处于备份状态。活动的Namenode负责实行 全部 修改定名 空间以及删除备份数据块的操作,而备份的Namenode则实行 同步操作,以保持与活动节点定名 空间的同等 性。
为了使备份节点与活动节点的状态可以或许 同步同等 ,两个节点都必要 同一组独立运行的节点(JournalNodes,JNS)通讯 。当Active Namenode实行 了修改定名 空间的操作时,它会定期将实行 的操作记录在editlog中,并写入JNS的多数节点中。而Standby Namenode会不停 监听JNS上editlog的变化,假如 发现editlog有改动,Standby Namenode就会读取editlog并与当前的定名 空间合并。当发生了错误切换时,Standby节点会保证已经从JNS上读取了全部 editlog并与定名 空间合并,然后才会从Standby状态切换为Active状态。通过这种机制,保证了Active Namenode与Standby Namenode之间定名 空间状态的同等 性,也就是第一关系链的同等 性。
为了使错误切换可以或许 很快的实行 完毕,就要保证Standby节点也保存了及时 的数据快的存储信息,也就是第二关系链。如许 发生错误切换时,Standby节点就不必要 等待全部 的数据节点举行 全量数据块汇报,而直接可以切换到Active状态。为了实现这个机制,Datanode会同时向这两个Namenode发送心跳以及块汇报信息。如许 就实现了Active Namenode 和standby Namenode 的元数据就完全同等 ,一旦发生故障,就可以立刻 切换,也就是热备。
这里必要 注意 的是 Standby Namenode只会更新数据块的存储信息,并不会向namenode 发送复制或者删除数据块的指令,这些指令只能由Active namenode发送。
在HA架构中有一个非常重非要的标题 ,就是必要 保证同一时间 只有一个处于Active状态的Namenode,否则机会出现两个Namenode同时修改定名 空间的问,也就是脑裂(Split-brain)。脑裂的HDFS集群很大概 造成数据块的丢失,以及向Datanode下发错误的指令等非常 环境 。为了防备 脑裂的环境 ,HDFS提供了三个级别的隔离机制(fencing):

  • 1.共享存储隔离:同一时间只答应 一个Namenode向JournalNodes写入editlog数据。
  • 2.客户端隔离:同一时间只答应 一个Namenode相应 客户端的哀求 。
  • 3.Datanode隔离:同一时间只答应 一个Namenode向Datanode下发名字节点指令,李如删除、复制数据块指令等等。

在HA实现中还有一个非常告急 的部分就是Active Namenode和Standby Namenode之间怎样 共享editlog日志 文件。Active Namenode会将日志 文件写到共享存储上。Standby Namenode会及时 的从共享存储读取edetlog文件,然后合并到Standby Namenode的定名 空间中。如许 一旦Active Namenode发生错误,Standby Namenode可以立刻 切换到Active状态。在Hadoop2.6中,提供了QJM(Quorum Journal Manager)方案来办理 HA共享存储标题 。

全部 的HA实现方案都依赖 于一个保存editlog的共享存储,这个存储必须是高可用的,并且可以或许 被集群中全部 的Namenode同时访问。Quorum Journa是一个基于paxos算法的HA计划 方案。

这里写图片形貌

Quorum Journal方案中有两个告急 的组件。

  • 1.JournalNoe(JN):运行在N台独立的物理机器上,它将editlog文件保存在JournalNode的本地磁盘上,同时JournalNode还对外提供RPC接口QJournalProtocol以实行 长途 读写editlog文件的功能。
  • 2.QuorumJournalManager(QJM):运行在NmaeNode上,(现在 HA集群只有两个Namenode),通过调用RPC接口QJournalProtocol中的方法向JournalNode发送写入、倾轧 、同步editlog。

Quorum Journal方案依赖 于如许 一个概念:HDFS集群中有2N+1个JN存储editlog文件,这些editlog 文件是保存在JN的本地磁盘上的。每个JN对QJM暴露QJM接口QJournalProtocol,答应 Namenode读写editlog文件。当Namenode向共享存储写入editlog文件时,它会通过QJM向集群中全部 的JN发送写editlog文件哀求 ,当有一半以上的JN返回写操作成功时,即以为 写成功。这个原理是基于Paxos算法的。

利用 Quorum Journal实现的HA方案有一下长处 :

  • 1.JN进程 可以运行在平凡 的PC上,而无需设置 专业的共享存储硬件。
  • 2.不必要 单独实现fencing机制,Quorum Journal模式中内置了fencing功能。
  • 3. Quorum Journa不存在单点故障,集群中有2N+1个Journal,可以答应 有N个Journal Node殒命 。
  • 4. JN不会由于 此中 一个机器的耽误 而影响团体 的耽误 ,而且也不会由于 JN数目 的增多而影响性能(由于 Namenode向JournalNode发送日志 是并行的)

互斥机制

当HA集群中发生Namenode非常 切换时,必要 在共享存储上fencing上一个活动的节点以保证该节点不能再向共享存储写入editlog。基于Quorum Journal模式的HA提供了epoch number来办理 互斥标题 ,这个概念可以在分布式文件体系 中找到。epoch number具有以下几个性子 。
1.当一个Namenode变为活动状态时,会分配给他一个epoch number。
2.每个epoch number都是唯一的,没有恣意 两个Namenode有雷同 的epoch number。
3.epoch number 定义了Namenode写editlog文件的次序 。对于恣意 两个namenode ,拥有更大epoch number的Namenode被以为 是活动节点。

当一个Namenode切换为活动状态时,它的QJM会向全部 的JN发送死 令,以获取该JN的末了 一个promise epoch变量值。当QJM担当 到了集群中多于一半的JN回复后,它会将所汲取 到的最大值加一,并保存到myepoch 中,之后QJM会将该值发送给全部 的JN并提出更新哀求 。每个JN会将该值与自身的epoch值相互比较,假如 新的myepoch比较大,则JN更新,并返回更新成功;假如 小,则返回更新失败。假如 QJM汲取 到超过一半的JN返回成功,则设置它的epoch number为myepoch;,否则它制止 尝试为一个活动的Namenode,并抛出非常 。

当活动的NameNode成功获取并更新了epoch number后,调用任何修改editlog的RPC哀求 都必须携带epoch number。当RPC哀求 到达JN后,JN会将哀求 者的epoch与自身保存的epoch相互对比,若哀求 者的epoch更大,JN就会更新本身 的epoch,并实行 相应的操作,假如 哀求 者的epoch小,就会拒绝相应的哀求 。当集群中大多数的JN拒绝了哀求 时,这次操作就失败了。
当HDFS集群发生Namenode错误切换后,原来的standby Namenode将集群的epoch number加一后更新。如许 原来的Active namenode的epoch number肯定小于这个值,当这个节点实行 写editlog操作时,由于JN节点不汲取 epoch number小于自身的promise epoch的写哀求 ,以是 这次写哀求 会失败,也就达到了fencing的目标 。

写流程

  • 1.将editlog输出流中缓存的数据写入JN,对于集群中的每一个JN都存在一个独立的线程调用RPC 接口中的方法向JN写入数据。
  • 2.当JN收到哀求 之后,JN会实行 以下操作:

1)验证epoch number是否正确

2)确认写入数据对应的txid是否连续

3)将数据持久化到JN的本地磁盘

4)向QJM发送正确 的相应

  • 3.QJM等待集群JN的相应 ,假如 多数JN返回成功,则写操作成功;否则写操作失败,QJM会抛出非常 。

Namenode会调用FSEditlogLog下面的方法初始化editlog文件的输出流,然后利用 输出流对象向editlog文件写入数据。
获取了QuorumOutputStream输出流对象之后,Namenode会调用write方法向editlog文件中写入数据,QuorumOutputStream的底层也调用了EditsDoubleBuffer双缓存区。数据回先写入此中 一个缓冲区中,然后调用flush方法时,将缓冲区中的数据发送给JN。

读流程

Standby Namenode会从JN读取editlog,然后与Sdtandby Namenode的定名 空间合并,以保持和Active Namenode定名 空间的同步。当Sdtandby Namenode从JN读取editlog时,它会起首 发送RPC哀求 到集群中全部 的JN上。JN汲取 到这个哀求 后会将JN本地存储上保存的全部 FINALIZED状态的editlog段落文件信息返回,之后QJM会为全部 JN返回的editlog段落文件构造输入流对象,并将这些输入流对象合并到一个新的输入流对象中,如许 Standby namenode就可以从任一个JN读取每个editlog段落了。假如 此中 一个JN失败了输入流对象会自动 切换到另一个保存了该edirlog段落的JN上。

这里写图片形貌

恢复流程

当Namenode发生主从切换时,原来的Standby namenode会接受 共享存储并实行 写editlog的操作。在切换之前,对于共享存储会实行 以下操作:
1.fencing原来的Active Namenode。这部分在互斥部分已经讲述。
2.恢复正在处理的editlog。由于Namenode发生了主从切换,集群中JN上正在实行 写入操作的editlog数据大概 不同等 。比方 ,大概 出现某些JN上的editlog正在写入,但是当前Active Namenode发生错误,这时该JN上的editlog文件就与已完成写入的JN不同等 。在这种环境 下,必要 对JN上全部 状态不同等 的editlog文件实行 恢复操作,将他们的数据同步同等 ,并且将editlog文件转化为FINALIZED状态。
3.当不同等 的editlog文件完成恢复之后,这时原来的Standby Namenode就可以切换为Active Namenode并实行 写editlog的操作。
4.写editlog。在前面已经先容 了。

日志 恢复操作可以分为以下几个阶段:

1.确定必要 实行 恢复操作的editlog段落:在实行 恢复操作之前,QJM会实行 newEpoch()调用以产生新的epoch number,JN汲取 到这个哀求 后除了实行 更新epoch number外,还会将该JN上保存的最新的editlog段落的txid返回。当集群中的大多数JN都发回了这个相应 后,QJM就可以确定出集群中最新的一个正在处理editlog段落的txid,然后QJM就会对这个txid对应的editlog段落实行 恢复操作了。

2.预备 恢复:QJM向集群中的全部 JN发送RPC哀求 ,查询实行 恢复操作的editlog段落文件在全部 JN上的状态,这里的状态包括editlog文件是in-propress还是FINALIZED状态,以及editlog文件的长度。

3.担当 恢复:QJM汲取 到JN发回的JN发回的相应 后,会根据恢复算法选择实行 恢复操作的源节点。然后QJM会发送RPC哀求 给每一个JN,这个哀求 会包含两部分信息:源editlog段落文件信息,以及供JN下载这个源editlog段落的url。
汲取 到这个RPC哀求 之后,JN会实行 以下操作:

1)同步editlog段落文件,假如 JN磁盘上的editlog段落文件与哀求 中的段落文件状态不同,则JN会从当前哀求 中的url上下载段落文件,并更换 磁盘上的editlog段落文件。
2)持久化恢复元数据,JN会将实行 恢复操作的editlog段落文件的状态、触发恢复操作的QJM的epoch number等信息(恢复的元数据信息)持久化到磁盘上。
3)当这些操作都实行 成功后,JN会返回成功相应 给QJM,假如 集群中的大多数JN都返回了成功,则此次恢复操作实行 成功。

4.完成editlog段落文件:到这步操作时,QJM 就能确定集群中大多数的JN保存的editlog文件的状态已经同等 了,并且JN持久化了恢复信息。QJM就会向JN发送指令,将这个editlog段落文件的状态转化为FINALIZED状态,,并且JN会删除持久化的恢复元数据,由于 磁盘上保存的editlog文件信息已经是正确 的了,不必要 保存恢复的元数据。

到此这篇关于详细 讲解HDFS的高可用机制的文章就先容 到这了,更多相干 HDFS的高可用机制内容请搜刮 脚本之家从前 的文章或继续欣赏 下面的相干 文章盼望 大家以后多多支持脚本之家!


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

avatar 玲嘉婕嘉n | 2021-9-12 19:29:48 | 显示全部楼层
世界末日我都挺过去了,看到admin楼主我才知道为什么上帝留我到现在!
回复

使用道具 举报

avatar 润唇膏贡 | 2021-9-20 00:24:17 | 显示全部楼层
不错哦,admin楼主这是要火的节奏啊!
回复

使用道具 举报

avatar 123457278 | 2021-9-20 17:00:19 | 显示全部楼层
有机会找admin楼主好好聊聊!
回复

使用道具 举报

avatar 蓝胖子685 | 2021-9-22 15:29:49 | 显示全部楼层
看帖不回帖都是耍流氓!
回复

使用道具 举报

avatar 知足常乐77 | 2021-9-26 21:32:07 | 显示全部楼层
读了admin楼主的帖子,顿时马桶就通了。。。
回复

使用道具 举报

avatar 山东美家环保 | 2021-10-4 09:43:35 | 显示全部楼层
admin楼主的帖子提神醒脑啊!
回复

使用道具 举报

avatar 123456881 | 2021-10-5 14:03:54 | 显示全部楼层
支持一下!
回复

使用道具 举报

avatar 么斯汀 | 2021-10-7 03:31:54 | 显示全部楼层
admin楼主,我告诉你一个你不知道的的秘密,有一个牛逼的网站,他卖的服务器是永久的,我们的网站用 服务器都是在这家买的,你可以去试试。访问地址:http://fwq.mxswl.com
回复

使用道具 举报

avatar 123456809 | 2021-10-9 12:50:57 | 显示全部楼层
看了这么多帖子,第一次看到这么有深度了!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则