HDFS - NameNode的高可用

高可用

咱们已经知道了,读取文件、上传文件,都须要通过NameNode,若是NameNode宕机了,那客户端就不知道往哪里读写数据,整个集群就不可用了。
image.png
Hadoop的高可用是经过zookeeper来实现的,Hadoop - 集群安装(高可用),这篇文章也提到了zookeeper的做用,实际上对于大数据的各个组件来讲,不少高可用都是经过zookeeper来作的,咱们下面看看zookeeper是若是实现Hadoop的高可用。在zookeeper中实现master选举的,能够看以前的文章zookeeper之master选举,这里不作细节补充。
高可用通常都是经过冗余的方式,部署多个节点,其中一个做为活动的节点,对外提供服务,剩余的节点做为处于待机状态,当活动节点不能够的时候,顶替成为活动节点。
在高可用的Hadoop中,NameNode的节点数量是2个,而且每一个NameNode都有zkfc,用于和zookeeper进行通信。
image.png
当其中一个NameNode成功的在zookeeper建立一个节点后,他就成了active节点,另一个就是standby节点。active节点对外提供服务,standby节点监听zookeeper的节点,当发现active节点不能够的时候,就去zookeeper上建立节点,变成active节点。
image.png
DataNode须要定时的给NameNode发送心跳,NameNode就会在内存中记录每一个DataNode最后发送心跳的时间,做为DataNode存活的依据,那此时是有两个NameNode的,若是仅仅把心跳发送到active节点上面,那故障转移的时候,新的active是不知道哪些DataNode是存活的,为了快速的实现故障转移,因此DataNode发送心跳的时候,就会获取到两个NameNode的地址和端口,一块儿发送本身的心跳信息。
image.png
NameNode内存中除了保存DataNode的心跳信息,还保存了元数据信息。为了让两个NameNode的元数据也同步,每次元数据有变动的时候,active节点也会把数据发送到journalnode集群,standby节点就会按期的从journalnode集群读取元数据信息。
image.png
为了保证NameNode的高可用,HDFS引入了zookeeper和journalnode,若是这两个不是高可用的,那也会影响到NameNode的高可用,因此这两个也要是高可用的。node

联邦集群

高可用的NameNode也是有他的瓶颈,好比全部的访问都要通过active节点的NameNode,高可用的NameNode并无减小active节点的压力,另一个瓶颈就是元数据的管理,元数据会一直增加,NameNode的内存总有被消耗完的一天,而且一直加内存会致使每次加载元数据过多让启动变得异常慢,而且full gc的时间也很长。为了解决这两个问题,HDFS推出了联邦集群。
既然一个NameNode有瓶颈,那就多几个NameNode来分单压力,如图下所示,有三组的NameNode,每组的NameNode都有active节点和standby节点。他们和zookeeper以及journalnode的关系跟高可用同样。
image.png
那这些NameNode是怎么管理元数据和DataNode的呢?联邦集群里引入了块池的概念,好比咱们有三组的NameNode,那就有三个块池,每一个DataNode就会划分红多个逻辑概念的块。
好比下图,假设每一个DataNode分为三块,每一个块都有对应的块池,第一组的NameNode往块池1读写数据,并保存对应的元数据信息。第二组的NameNode往块池2读写数据,并保存对应的元数据信息。第三组的NameNode往块池3读写数据,并保存对应的元数据信息。假设元数据原先为600G,那此时每一个NameNode只要管理200G的元数据就行了。另外在读写上,也下降为原来的三分之一,大大减小了NameNode的压力。
image.pngsegmentfault

相关文章
相关标签/搜索