hadoop HA架构思想总结

Hadoop HA架构思想总结

架构图

在这里插入图片描述
![(https://img-blog.csdnimg.cn/f895f3c2d9dd4870827ffad73efd501c.png)

角色介绍

• NN节点，即NameNode节点，负责hadoop文件的元数据规划、存储和接收DN节点关于实际文件数据存储信息的汇报
• DN节点,即数据节点，负责具体文件数据的存储，存储文件块数据，hadoop中，文件是按指定块大小切割后，按块存储在DN节点中
• SNN节点，即SecondaryNameNode节点，在单NN节点部署模式下负责拉取NN节点上的fsimage和editlog,并合并生产新的fsimage，并推送到NN节点
• ZK集群,即Zookeeper集群，起分布式协调作用，这里支持FC完成NN的高可用功能
• ZKFC,即FailoverController进程，借助zk完成NN的高可用功能，包括NN节点的监控，ZK上节点的删除，NN角色转换和重启等
• JN,即JournalNode进程，作为NN集群之间数据同步的中间件，使得NN集群满足最终一致性，在可用性和一致性达到折中
• client,即使用hadoop的用户端程序

HA思想总结

NN集群部署方式

要使得Hadoop高可用，必须解决NN单点问题及存储压力问题。对于单点问题，使用集群部署，并采用主备方式，为高可用实现创造条件。

NN集群选主过程

类似数据库，NN集群本身提供复制机制，但是不提供高可用措施。在每个NN节点部署FC程序，监视当前节点上的NN状态，并通过在zk上抢锁实现选主，及通过删除zk上的锁，来通知其他从NN节点，也就是zk的watch机制，来选出新的主。主负责增删改查，从不负责提供服务。同时新的主会检查旧主是否存活，若dead，则将旧的主降级为standby,将自己提升为active状态。这些操作都是通过SSH免密或脚本操作实现的。

NN集群数据同步内容

1. client提交的文件操作涉及元数据
2. DD节点定时心跳传来的文件块存储信息

NN集群内数据同步

DD节点定时心跳传来的文件块存储信息的集群同步，由于DD会向所有的NN节点上报信息，所以这部分信息不要要额外的同步了。client提交的文件操作涉及元数据在集群存在数据同步，必然涉及可用性、一致性、分区容错性问题。分区容错一定存在，为了追求最终一致和基本可用，hadoop HA使用了中间件JournalNode，其相当于队列。当client向NN节点提交增删改数据时，NN节点自己存储editlog，同时将editlog数据提交改JournalNode主进程，JournalNode主向NN主回复OK,NN再向client返回OK。NN从节点则从JN节点同步editlog数据。

NN集群主存储压力过大问题

NN集群主节点之间数据分片存储，即每一个主节点上的数据是整个数据的一部分，分治思想，类似redis集群模式。而且在DN节点上复用存储空间。假如有100个DN,有两个NN主，则每一个NN主负责的文件，可以分别存储在这100个DN上，每个DN上都有NN对应的一个目录。

ZKFC和NN一起部署

ZKFC和NN节点一起部署在同一个节点上，避免分开部署产生的网络问题及延迟

JournalNode选举

要保证自身的高可用，也是主从部署方式，而存在集群内部数据同步问题。主down掉了，选主时，首先看从从节点中找出数据最新的节点，然后从其中，比如根据id大小选主。

JournalNode集群数据同步

JournalNode主收到NN节点数据后，自己存储，再把数据同步给其他从节点，过半JournalNode节点同步了数据后，向NN节点返回OK。

去掉SNN节点

因为NN集群是，主备结构，备只同步数据，不提供服务，NN备节点就把原来单节点NN部署结构时的SSN的作用承担起来

Hadoop HA问题

虽然这样的HA已经很完美了，但是还是有个小问题：就是当ZKFC与ZK发生网络问题，同时NN主和其他NN节点上的ZKFC发生网络问题，导致原来的NN主还是active,即使触发了原来的NN备节点去zk上抢到了锁，其也无法去探视原来的主存活与否，由于会反生网络不通，避免发生脑裂问题，就不就行Failover操作，就会导致集群一直报错。当然这个问题出现的概率很小，因为我们相信网络稳定，加上运维的网络高可用，应该不成问题。