这里是大数据小白系列,这是本系列的第三篇,介绍HDFS中NameNode选举,JournalNode等概念。
上一期我们说到了为解决NameNode(下称NN)单点失败问题,HDFS中使用了双NN的机制,一个Active NN,一个Standby NN。
现实常常是,解决一个问题的同时,免不了又引入了另外的问题。
谁来担任Active,谁来担任Standby?
两个NN谁也说服不了谁,这个时候需要引入一个外部角色:一个Zookeeper(下称ZK)集群。
ZK也是个很有趣的东西,大数据小白系列后续会专门介绍。
这里,ZK集群扮演了类似裁判的角色,如果两个NN同时申请成为Active,由ZK决定谁将获胜。
两台NN机器上都分别存在一个ZKCF(Zookeeper Failover 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(Quorum Journal Manager)进程将Edit Log写入某JN节点,该JN节点需要将数据写入其他JN节点,直到数据被写入集群中的“多数节点”,本次操作才算成功。
例如,JN集群中共有3个节点,需要写入到其中2个节点,即所谓的“多数”(majority)。
通常,JN集群总是包含奇数个节点,至于为什么,我准备在介绍ZK的时候再来说明,因为二者比较类似。
需要注意,虽然QJM的工作机制类似于ZK,但本身并没有用到ZK,同时它也比ZK来的轻量级,它可以跑在集群现有的机器上,而不需要单独为它准备机器。
好了,这期就先到这,下期我们将介绍现实世界中的HDFS集群,以及Federation等概念。Cheers!
喜欢本文的朋友们,欢迎长按下图关注订阅号程序员杂书馆,提前获得更多更新内容,更可获赠大数据纸质书籍。