HA工作机制及namenode向QJM写数据流程
Posted zhqin
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HA工作机制及namenode向QJM写数据流程相关的知识,希望对你有一定的参考价值。
HA工作机制
(配置HA高可用传送门:https://www.cnblogs.com/zhqin/p/11904317.html)
HA:高可用(7*24小时不中断服务)
主要的HA是针对集群的master节点的,即namenode和resourcemanager,毕竟DataNode挂掉之后影响 不是特别大,重启就好了。
HDFS的HA
HDFS HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障,如机器崩溃或机器需要升级维护,这时可通过此种方式将NameNode很快的切换到另外一台机器。
两个namenode,暂且将其标记为active和standby,active为当前工作的机器,standby为替补,直接让二者之间直接通过网络通讯同步数据不太稳定,因为网络一旦断了,另一边节点就数据不完整。因此找到一个可靠的第三方,两个namenode都可以访问,因此效率高。
这样Active一直往这个第三方写数据,standby从这个第三方读数据就可以了。
我们想要实现的就是,如果active挂掉了,自动通知standby来顶替ative去运行。那么这个时候又需要一个可靠的第三方来负责通知,即ZooKeeper。
首先active在ZooKeeper中注册一个临时节点,另一个名称节点(standby)在ZooKeeper中看到ZooKeeper中有active的这个临时节点后,知道自己不能再是active节点了,所以现在他自己的角色就是standby,但是它会在ZooKeeper中注册监听,它会时刻监听着active这个节点,一旦active节点挂掉,ZooKeeper中注册的active就会消失,由于standby注册了监听,所以ZooKeeper会在第一时间通知standby节点,“告知”其active节点挂掉了。然后standby节点就“上位”成为active主namenode节点。
其中active其实并不是直接和ZooKeeper沟通,而是通过一个新进程——ZooKeeper客户端:ZooKeeper Failover controller(Zkfc)来进行沟通。Zkfc负责把主节点namenode的数据(状态信息)写入到ZooKeeper中。
那直接让namenode和ZooKeeper直接通信就好,为什么要加个Zkfc来负责namenode与ZooKeeper的通信呢?
因为HA高可用是在hadoop2.x之后出现的,这个时候Hadoop代码经过多年的迭代,有着较高的健壮性,而如果让namenode直接和ZooKeeper通信,需要去修改hadoop的代码,这样会降低hadoop代码的健壮性,所以为了不破坏hadoop代码的健壮性,在hadoop2.x的时代,就单独写了个进程:ZooKeeper Failover controller(Zkfc),但是这个进程本质上就是把原来打算让namenode自己完成的事情单独写成了一个进程,所以Zkfc这个进程是和namenode绑定的,换句话说就是,有namenode的地方就有Zkfc。Zkfc维持着active这个namenode和ZooKeeper之间的会话。另一边standby同理,也是通过另一个Zkfc来维持着standby和ZooKeeper之间的通信。
具体工作过程为:
如果Zkfc检测到active挂掉,Zkfc会把ZooKeeper中的临时节点释放掉,另外一边standby的Zkfc进程从ZooKeeper服务端接收到active挂掉的通知后,首先强行杀死之前的active节点(ssh kill -9 namenode节点号
或者调用用户自定义的脚本),以防脑裂,然后将standby节点变为active节点。
说完ZooKeeper的通知机制之后,那么,active和standby读写数据的第三方是什么呢?
Quorum Journal Manager
大多数日志管理
其管理的就是hadoop的元数据,即edits.log
QJM也是一个集群,该集群也是单数台机器,写数据的时候也进行投票,其管理的是edits.log这个元数据。
和ZooKeeper集群类似,QJM集群中只要有一半以上的机器就不会挂。
namenode向QJM写数据的流程:
来一条写请求,然后写到edits里面,然后active会把edits写到
QJM集群里面,QJM这边同意写入,active才会将edits写入,(这里注意:QJM为了提高效率,只要超过半数的机器同意即可写入,这样以来QJM集群中不必所有机器都要求同步。)如果没有HA的时候,hadoop集群中2nn帮助namenode整合Fsimage,如果有了HA之后,就不需要2nn了,standby节点在监听active节点的同时,standby实时将active写入QJM集群中的edits读出到自己的内存中,这样保证了active一旦挂掉,standby这个节点可以随时顶上去接替active继续工作,然后standby定期把内存中的edits合成Fsimage,然后发送给active,所以说standby这个节点比2nn功能更强大,可以代替2nn。
以上是关于HA工作机制及namenode向QJM写数据流程的主要内容,如果未能解决你的问题,请参考以下文章
Hadoop namenode高可用性分析:QJM核心源代码解读