hadoop的ha如何实现?

2020-09-01 08:26发布

hadoop的ha如何实现?

hadoop的ha如何实现?

3条回答
猫的想法不敢猜
2022-02-16 09:32

在hadoop 1.x版本中,是没有ha的实现方式的,它只有可以看做是冷备份的Secondary NameNode来起到冷备份的作用的,当NameNode挂掉的时候,我们需要手工启动Secondary NameNode。


   那么为什么Secondary NameNode能够这样做,是因为SNN能够帮助NN做一些检查点的工作,会同步编辑日志和镜像文件,所以可以起到冷备的作用。在1.x版本中,当NN挂掉后,是没有办法立即启动起来继续为集群服务的。


    到了hadoop 2.x版本,基本都有了hdfs ha的功能(即热备功能),当主NN挂掉后,备NN会立即启动进而接管主NN为集群不间断的提供服务,保证集群对外是没有任何宕机的情况。

 接下来,我们根据上图来了解HA的方案是如何实现的?

 在2.0版本中,Namenode可以部署两个:Active NN和Standly NN。在同一时间永远都是只有一个NN对外提供服务的,即Active NN。Active NN并不永远都是一个固定的状态,当Active NN出现故障后,Standly NN就会切换成Active NN提供服务,而之前的Active NN就会变成Standly NN停止位集群服务。Standly NN负责同步Active NN中的元数据信息,也会接收Active NN的块报告,所有的DN上的Block Pool块报告的信息会同时发送到Active NN和Standly NN,这样他们的信息就能够达到同步。Edits日志只有Active状态的NameNode节点可以做写操作;两个NameNode都可以读取Edits;


元数据共享存储方案:


在NN中,最关键的元数据(镜像文件和编辑日志)是需要共享才能使ANN和SNN实现数据的同步,元数据共享有几种方案: NFS(Linux自带的网络文件系统)、QJM(Quorum Journal Manager)、zookeeper。


QJM的详细介绍请参考:https://blog.csdn.net/czz1141979570/article/details/86735695 


zookeeper:


    上图中也显示使用了zookeeper的方案来实现HA的高可用,在zookeeper中会有两个FailoverControlller进程,一个负责监控ANN状态,另一个负责监控SNN状态,FailoverControlller从ANN和SNN中获取监控状态,并将监控状态通过Heartbeat保存在zookeeper中的znode中,会占用一个znode保存这些监控信息。


   当ANN出现故障后,zookeeper会通过FailoverControlller感知到,这时候FailoverControlller Standly会让SNN占用znode,使SNN切换成ANN。


  所有zookeeper是实现HA自动切换的关键组成部分。如果没有zk,我们就没有办法实现HA的故障自动切换。


基于ZK的自动切换模式配置

HA的自动故障转移依赖于ZooKeeper的以下功能:


1)故障检测:集群中的每个NameNode在ZooKeeper中维护了一个持久会话,如果机器崩溃,ZooKeeper中的会话将终止,ZooKeeper通知另一个NameNode需要触发故障转移。


2)现役NameNode选择:ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。如果目前现役NameNode崩溃,另一个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。


ZKFC是自动故障转移中的另一个新组件,是ZooKeeper的客户端,也监视和管理NameNode的状态。每个运行NameNode的主机也运行了一个ZKFC进程,ZKFC负责:


1)健康监测:ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode,只要该NameNode及时地回复健康状态,ZKFC认为该节点是健康的。如果该节点崩溃,冻结或进入不健康状态,健康监测器标识该节点为非健康的。


2)ZooKeeper会话管理:当本地NameNode是健康的,ZKFC保持一个在ZooKeeper中打开的会话。如果本地NameNode处于active状态,ZKFC也保持一个特殊的znode锁,该锁使用了ZooKeeper对短暂节点的支持,如果会话终止,锁节点将自动删除。


3)基于ZooKeeper的选择:如果本地NameNode是健康的,且ZKFC发现没有其它的节点当前持有znode锁,它将为自己获取该锁。如果成功,则它已经赢得了选择,并负责运行故障转移进程以使它的本地NameNode为Active。故障转移进程与前面描述的手动故障转移相似,首先如果必要保护之前的现役NameNode,然后本地NameNode转换为Active状态。

————————————————

版权声明:本文为CSDN博主「流一恩典」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/czz1141979570/article/details/86738013

————————————————

版权声明:本文为CSDN博主「流一恩典」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/czz1141979570/article/details/86738013


一周热门 更多>