您的位置: 小王聊社会 > 房产

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

2019-07-19来源:小王聊社会

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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


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

 

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))集群”。

 

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

 

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

 

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

 

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

 

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

 

福利在这里,关注“程序员杂书馆”公众号,领取大数据经典书籍《Spark快速大数据分析》纸质书。还犹豫什么,抓紧点击关注吧。

本文由小王聊社会整理,内容仅供参考,未经书面授权禁止转载!图片来源图虫创意,版权归原作者所有。

相关阅读