一、完全分布式存在的问题
NameNode单点故障,难以应用于在线场景
NameNode压力过大,且内存受限,影响系统扩展性
二、高可用结构图
![](https://img.haomeiwen.com/i17777430/0be5af565640b86f.png)
![](https://img.haomeiwen.com/i17777430/d8ac0b718e0d0d11.png)
三、图例详解
1、JN实现主备NN 间的数据共享(解决单点故障)
主NameNode对外提供服务,备NameNode同步主NameNode元数据,以待切换,所有DataNode同时向两个NameNode汇报数据块信息(位置)
standby:备用namenode,完成了edits.log文件的合并产生新的fsimage,推送回ActiveNN
2、基于Zookeeper自动切换方案
ZooKeeper Failover Controller(zkfc):监控NameNode健康状态,并向Zookeeper注册NameNode,当主NameNode挂掉后,ZKFC(备)为NameNode竞争锁,获得ZKFC(备)锁的NameNode(备)变为active。
3、ZKFC的作用
健康检测:zkfc会周期性的向它监控的namenode(只有namenode才有zkfc进程,并且每个namenode各一个)发生健康探测命令,从而鉴定某个namenode是否处于正常工作状态,如果机器宕机,心跳失败,那么zkfc就会标记它处于不健康的状态;
会话管理:如果namenode是健康的,zkfc机会保持在zookeeper中保持一个打开的会话,如果namenode是active状态的,那么zkfc还会在zookeeper中占有一个类型为短暂类型的znode,当这个namenode挂掉时,这个znode将会被删除,然后备用的namenode得到这把锁,升级为主的namenode,同时标记状态为active,当宕机的namenode,重新启动,他会再次注册zookeeper,发现已经有znode了,就自动变为standby状态,如此往复循环,保证高可靠性,但是目前仅支持最多配置两个namenode.
master选举:如上所述,通过在zookeeper中维持一个短暂类型的znode,来实现抢占式的锁机制,从而判断哪个namenode为active状态。
网友评论