Hadoop高可用(高可用性)分为HDFS高可用和纱高可用,两者的实现基本类似,但HDFS NameNode对数据存储及其一致性的要求比纱ResourceManger高得多,所以它的实现也更加复杂,故下面先进行讲解:
<强> 1.1高可用整体架构
HDFS高可用架构如下:
图片引用自:https://www.edureka.co/blog/how-to-set-up-hadoop-cluster-with-hdfs-high-availability/
HDFS高可用架构主要由以下组件所构成:
活动NameNode和备用NameNode:两台NameNode形成互备,一台处于活跃的状态,为主NameNode,另外一台处于待机状态,为备NameNode,只有主NameNode才能对外提供读写服务。
-
<李>主备切换控制器ZKFailoverController: ZKFailoverController作为独立的进程运行,对NameNode的主备切换进行总体控制.ZKFailoverController能及时检测到NameNode的健康状况,在主NameNode故障时借助饲养员实现自动的主备选举和切换,当然NameNode目前也支持不依赖于管理员的手动主备切换。
<李>管理员集群:为主备切换控制器提供主备选举支持。共享存储系统:共享存储系统是实现NameNode的高可用最为关键的部分,共享存储系统保存了NameNode在运行过程中所产生的HDFS的元数据。
<李>主NameNode和NameNode通过共享存储系统实现元数据同步。在进行主备切换的时候,新的主NameNode在确认元数据完全同步之后才能继续对外提供服务。
<李> DataNode节点:除了通过共享存储系统共享HDFS的元数据信息之外,主NameNode和备NameNode还需要共享HDFS的数据块和DataNode之间的映射关系。
<李> DataNode会同时向主NameNode和备NameNode上报数据块的位置信息。
<强> 1.2基于QJM的共享存储系统的数据同步机制分析
目前Hadoop支持使用群体经理(QJM)杂志或网络文件系统(NFS)作为共享的存储系统,这里以QJM集群为例进行说明:活跃NameNode首先把EditLog提交到JournalNode集群,然后待机NameNode再从JournalNode集群定时同EditLog步,当活跃NameNode宕机后,备用NameNode在确认元数据完全同步之后就可以对外提供服务。
需要说明的是向JournalNode集群写入EditLog是遵循“过半写入则成功”的策略,所以你至少要有3个JournalNode节点,当然你也可以继续增加节点数量,但是应该保证节点总数是奇数。同时如果有2 N + 1台JournalNode,那么根据过半写的原则,最多可以容忍有N台JournalNode节点挂掉。
<强> 1.3 NameNode主备切换
NameNode实现主备切换的流程下图所示:
HealthMonitor初始化完成之后会启动内部的线程来定时调用对应NameNode的HAServiceProtocol RPC接口的方法,对NameNode的健康状态进行检测。
HealthMonitor如果检测到NameNode的健康状态发生变化,会回调ZKFailoverController注册的相应方法进行处理。
如果ZKFailoverController判断需要进行主备切换,会首先使用ActiveStandbyElector来进行自动的主备选举。
ActiveStandbyElector与管理员进行交互完成自动的主备选举。
ActiveStandbyElector在主备选举完成后,会回调ZKFailoverController的相应方法来通知当前的NameNode成为主NameNode或备NameNode。
然后ZKFailoverController调用对应的HAServiceProtocol RPC接口的方法将NameNode转换为活跃状态或待机状态。
<强> 1.4纱高可用
纱ResourceManager的高可用与HDFS NameNode的高可用类似,但是ResourceManager不像NameNode,没有那么多的元数据信息需要维护,所以它的状态信息可以直接写到动物园管理员上,并依赖饲养员来进行主备选举。
<强>二,集群规划
按照高可用的设计目标:需要保证至少有两个NameNode(一主一备)和两个ResourceManager(一主一备),同时为满足”过半写入则成功”的原则,需要至少要有3个JournalNode节点。这里使用三台主机进行搭建,集群规划如下:
