HDFS - NameNode的高可用

高可用

我们已经知道了，读取文件、上传文件，都需要经过NameNode，如果NameNode宕机了，那客户端就不知道往哪里读写数据，整个集群就不可用了。

Hadoop的高可用是通过zookeeper来实现的，Hadoop - 集群安装（高可用），这篇文章也提到了zookeeper的作用，实际上对于大数据的各个组件来说，很多高可用都是通过zookeeper来做的，我们下面看看zookeeper是如果实现Hadoop的高可用。在zookeeper中实现master选举的，可以看之前的文章zookeeper之master选举，这里不做细节补充。
高可用一般都是通过冗余的方式，部署多个节点，其中一个作为活动的节点，对外提供服务，剩余的节点作为处于待机状态，当活动节点不可以的时候，顶替成为活动节点。
在高可用的Hadoop中，NameNode的节点数量是2个，并且每个NameNode都有zkfc，用于和zookeeper进行通讯。

当其中一个NameNode成功的在zookeeper创建一个节点后，他就成了active节点，另外一个就是standby节点。active节点对外提供服务，standby节点监听zookeeper的节点，当发现active节点不可以的时候，就去zookeeper上创建节点，变成active节点。

DataNode需要定时的给NameNode发送心跳，NameNode就会在内存中记录每个DataNode最后发送心跳的时间，作为DataNode存活的依据，那此时是有两个NameNode的，如果仅仅把心跳发送到active节点上面，那故障转移的时候，新的active是不知道哪些DataNode是存活的，为了快速的实现故障转移，所以DataNode发送心跳的时候，就会获取到两个NameNode的地址和端口，一起发送自己的心跳信息。

NameNode内存中除了保存DataNode的心跳信息，还保存了元数据信息。为了让两个NameNode的元数据也同步，每次元数据有变更的时候，active节点也会把数据发送到journalnode集群，standby节点就会定期的从journalnode集群读取元数据信息。

为了保证NameNode的高可用，HDFS引入了zookeeper和journalnode，如果这两个不是高可用的，那也会影响到NameNode的高可用，所以这两个也要是高可用的。

联邦集群

高可用的NameNode也是有他的瓶颈，比如所有的访问都要经过active节点的NameNode，高可用的NameNode并没有减少active节点的压力，另外一个瓶颈就是元数据的管理，元数据会一直增长，NameNode的内存总有被消耗完的一天，并且一直加内存会导致每次加载元数据过多让启动变得异常慢，并且full gc的时间也很长。为了解决这两个问题，HDFS推出了联邦集群。
既然一个NameNode有瓶颈，那就多几个NameNode来分单压力，如图下所示，有三组的NameNode，每组的NameNode都有active节点和standby节点。他们和zookeeper以及journalnode的关系跟高可用一样。

那这些NameNode是怎么管理元数据和DataNode的呢？联邦集群里引入了块池的概念，比如我们有三组的NameNode，那就有三个块池，每个DataNode就会划分成多个逻辑概念的块。
比如下图，假设每个DataNode分为三块，每个块都有对应的块池，第一组的NameNode往块池1读写数据，并保存对应的元数据信息。第二组的NameNode往块池2读写数据，并保存对应的元数据信息。第三组的NameNode往块池3读写数据，并保存对应的元数据信息。假设元数据原先为600G，那此时每个NameNode只要管理200G的元数据就好了。另外在读写上，也降低为原来的三分之一，大大减少了NameNode的压力。