大数据小白系列——HDFS(3)

这里是大数据小白系列,这是本系列的第三篇,介绍HDFS中NameNode选举,JournalNode等概念。

上一期我们说到了为解决NameNode(下称NN)单点失败问题,HDFS中使用了双NN的机制,一个Active NN,一个Standby NN。

大数据小白系列——HDFS(3)

现实常常是,解决一个问题的同时,免不了又引入了另外的问题。

谁来担任Active,谁来担任Standby?

两个NN谁也说服不了谁,这个时候需要引入一个外部角色:一个Zookeeper(下称ZK)集群。

大数据小白系列——HDFS(3)

ZK也是个很有趣的东西,大数据小白系列后续会专门介绍。

这里,ZK集群扮演了类似裁判的角色,如果两个NN同时申请成为Active,由ZK决定谁将获胜。

大数据小白系列——HDFS(3)

两台NN机器上都分别存在一个ZKCF(Zookeeper Failover Controller)进程,该进程相当于ZK的一个客户端。

ZKFC定期检查NN进程的状态,如状态正常,并且目前没有其他NN在持有ZK集群上的锁,则加入选举,并且申请锁。(注:所谓的锁,实际上是ZK集群上的一种特殊目录)

若ZKFC检查NN进程不正常,则退出选举,并放弃ZK上的锁(如持有)。

大数据小白系列——HDFS(3)

大数据小白系列——HDFS(3)

Q:如果不是NN进程死了,而是整个NN机器掉电了呢?

A:当集群与ZKFC进程的连接断开超过一定时间,锁将自动过期,以便其他NN可以申请重新选举。

Q:如果Active、Standby都死了呢?

A:不好意思,那就死透了。


上一期提到的另外一个内容,Active NN负责将Edit Log写入某个“共享存储”,而Standby NN负责从该位置读取以保持同步。

最简单的,可以使用NFS(Network File System)来担任共享存储。

但是NFS本身成为了单点失败,即,如果NFS系统坏了,导致Edit Log无法读写,整个HDFS系统也就无法工作。

因此,HDFS推荐使用的是专为Edit Log高可用性所设计的“JournalNode(下称JN))集群”。

大数据小白系列——HDFS(3)

NN通过QJM(Quorum Journal Manager)进程将Edit Log写入某JN节点,该JN节点需要将数据写入其他JN节点,直到数据被写入集群中的“多数节点”,本次操作才算成功。

例如,JN集群*有3个节点,需要写入到其中2个节点,即所谓的“多数”(majority)。

通常,JN集群总是包含奇数个节点,至于为什么,我准备在介绍ZK的时候再来说明,因为二者比较类似。

需要注意,虽然QJM的工作机制类似于ZK,但本身并没有用到ZK,同时它也比ZK来的轻量级,它可以跑在集群现有的机器上,而不需要单独为它准备机器。

好了,这期就先到这,下期我们将介绍现实世界中的HDFS集群,以及Federation等概念。Cheers!

作者公众号“程序员杂书馆”,专注大数据,欢迎关注,每位关注者将获赠《Spark快速大数据分析》纸质书一本

大数据小白系列——HDFS(3)

上一篇:如何在word文档中添加mathtype加载项


下一篇:double型转换成string型