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。

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