Hadoop--HA架构详解

一、HA架构工作背景

HDFS集群中的nameNode存在单点故障因素。对于只有一个nameNode工作的集群来说,一旦nameNode出现意外情况,会导致整个集群无法工作,直到nameNode重新启动。
为了解决上述问题,Hadoop给出了高容错,高可用的HA方案:一个HDFS集群至少存在两个nameNode,一个nameNode处在active(主)状态,其他nameNode处在standby(备)状态。一旦处于activate状态的nameNode发生意外,其他处于standby状态的nameNode立即抢占activate的临时节点,代替发生意外的nameNode继续对外提供服务,从而保证了整个HDFS集群处在正常工作状态。

二、主备数据同步

想要备nameNode接替主nameNode工作,那么必须保证备nameNode和主nameNode拥有相同的内存数据。
主nameNode主要有以下数据需要进行频繁同步:edits log(日志)、block列表信息以及DataNode心跳检测
2.1首先说日志的同步:
同步edits log数据是借助第三方JNN( Journal Nodes )提供的服务。客户端对主nameNode操作,主nameNode将edits log写到JNN集群,备nameNode从JNN集群上读取数据,同步内存数据。可是主nameNode发生意外,导致JNN集群上各服务器上的数据不一致怎么办呢?JNN集群最少有三台服务器,一旦JNN服务器上的数据不一致,立即进行投票选举,通过过半机制保证数据的一致性(即以多数为准),舍掉与多数不一致的数据,然后在将数据同步给舍掉数据的服务器,保证了数据的一致性。
2.2、介绍一下JNN
JNN的过半机制:
如果主nameNode向三台JNN写数据,只要保证过半JNN写成功,就返回成功, JNN根据过半机制,进行数据在三台JNN上同步。
最终一致性:最终三台JNN上的edits信息是一致的。
JNN上的edits只能有一台nameNode写信息,防止脑裂。
2.3、block列表的同步:
DataNode主动向各台nameNode发送block列表信息和心跳。从而保证了主备之间block的一致性。
2.4、合并文件
原来HDFS上的secondarynameNode的合并fsimages(镜像)与edits(日志) 文件的工作,现在交给备nameNode进行,备用nameNode一小时合并一次并推送给主nameNode,在不满一小时的情况下,如果edits文件的操作达到100w,也要进行合并。

三、自动切换nameNode

主nameNode和备nameNode的切换时自动切换的,通过zookeeper集群来完成!

首先添加zookeeper集群,在每个nameNode上运行一个zkfc进程(zkfc是zookeeper的客户端)。zkfc要和zookeeper集群保持长连接和心跳。

在集群启动的时候,两个NameNode都处于standby状态, 两个nameNode的各自的zkfc要向zookeeper集群抢占创建一个临时节点,该临时节点保存了主nameNode的信息,哪个zkfc创建成功,则哪个zkfc所在主机上的nameNode为主nameNode。

nameNode上的zkfc要监控主nameNode创建的临时节点,一旦主nameNode出现故障,zkfc将删除该临时节点(实际上是因为主nameNode上的zkfc不能和zookeeper集群保持心跳连接,临时节点消失),临时节点消失,则备nameNode上的zkfc要向zookeeper集群抢占创建临时节点,如果创建成功,备nameNode升级为主nameNode。
在备份nameNode升级为主nameNode之前,要和原来的nameNode通信,确保原来的nameNode已经不能提供服务。如果原来的nameNode是由于网络延迟等原因导致的临时节点消失(也就是说还能提供服务),则杀死原来的nameNode。

最后我想说的是,这服务器之间的竞争太他妈激烈了!!!!!

猜你喜欢

转载自blog.csdn.net/weixin_43462670/article/details/89172603
今日推荐