Quorum Journal Manager QJM实现高可用HA文件同步原理

序

since： 2021年5月23日 16:13

auth： Hadi

参考：

https://blog.csdn.net/breakout_alex/article/details/88171114

https://blog.csdn.net/weixin_42782897/article/details/89335674

https://blog.csdn.net/zuotengseven/article/details/108216736

前言

上次我们讲了Hadoop 高可用原理主要是分为两大块，1.数据文件的同步共享；2.热备切换机制。详细可以参考这里。在数据文件同步共享中，我们讲解了再Hadoop2.X的版本中使用了QJM进行文件的数据同步，那么为什么选择了QJM，那么QJM到底是什么，怎么进行的文件同步，怎么保证文件的一致性呢？

 

历程

在HDFS-1623 和其他相关的JIRA在现有HDFS的NameNode基础上增加了HA的支持，但是还是需要一个存放EditLog文件的共享存储目录，这个共享存目录的要求也必须是高可用的，可以被集群中所有的NameNodes同时访问。

目前对于共享的EditLog存储目录，一个推荐的做法是通过NAS （Network-attached storege，网络关联的存储）设备，然后挂载到NFS上。那么这个挂在好的目录允许Active NameNode写EditLog到上面，同时Standby NameNode可以通过tail的方式去读这些文件。

 

但以上的假设在某些场合下是不满足要求的：

1. 需要定制硬件，一个NAS设备和远程控制单元PDU的价格是很昂贵的。
2. 复杂的部署。需要额外的步骤来配置NFS挂载目录，自定义的fencing限制脚本等等，导致HA的复杂化。
3. NFS Client实现简陋，不够健壮。

 

那么对此新生的方案有以下的追求：

1. 不需要对特定的硬件有什么要求。
2. 没有对fencing限制脚本的要求。所有需要fencing的操作应该只需要发生在软件层面，封装到系统中实现。
3. 没有单节点故障问题。

 

QJM

Quorum Journal Manager由 Cloudera工程师 ToddLipcon主导设计。最初的思想来源于