先上图
ha模式
在hdfs1.x的时候,主要组件有namenode、secondnode、datanode,但是正如我们知道的,namenode的稳定性决定了整个系统的稳定性,这是存在的一大问题,所以在2.x版本中添加了如下如见
之前的一个namenode成了两个,但是这两个namenode被赋予了一个状态,active/standby,意思很明显,一主一备,也就是说,在2.x版本中,也只能有一个namenode,如果有两个,则会出现split brain现象,现在来具体说受2.x的各个组件及它们的作用
namenode(Active) :
这个节点也就是主节点,跟1.x中的namenode的功能是一样的
namenode(Standby):
备用节点,为何叫备用?能成为备用,必须具备什么条件?
那就是,需要这个备用节点在主节点不可用的时候,能够马上代替主节点工作,也就是,备用节点必须具备主节点的所有数据。所以,每个dataNode在报告块信息的时候,会同时向主节点和备用节点报告,如此,便保证了主备两个节点的块信息是一致的,但是,我们想想,在namenode上面难道只有块信息?不止,还有其他元数据,比如块的大小,偏移量,MD5验证信息等,我们知道,hdfs客户端只会与一个节点进行沟通,那就是主节点,也就是说,每个块的上传信息,只有主节点上面有,那这些数据备用节点如何得到呢?那就出来了这个服务器JN
同时呢,在1.x版本中我们知道,有一个secondnode,去哪里了呢,基于内存存储的namenode难道不怕掉电吗,当然怕,所以这个功能还是存在的,现在这个角色的任务,现在交给了这个备用节点,所以,备用节点,还有一大功能,就是负责日志文件与镜像文件的整合工作
JN(journal name):
这个节点主要负责就是用了主节点和备用节点的数据的同步工作,如何同步?
主节点在接收客户端的任务后,会生成一个日志文件,在日志文件每次更新的时候主节点会将这个日志文件写入到JN中,备用节点则负责去JN中将日志文件接收下来,并且自己执行一遍,以达到与主节点状态一直的目的
但是,为什么会有三台呢?
其实在最初的时候,确实只有一天,但是,发现,如果这台负责通过工作的节点挂掉了怎么办?
所以,有了如今的3台,形成一个集群,如果一台机器挂了,另外一台接替工作
那为什么一定是3台呢,不能是4台吗?
当然可以,但是,在集群高可用的概念中,有一种思想,“过半可用”,也就是说,整个集群,当一半的节点失效的时候,整个集群也就瘫痪了,如果有4台,瘫痪的概率是50%,如果是3台呢,必须挂掉2台,整个集群才算瘫痪,也是就是瘫痪概率33.3%,所以,在集群的搭建原则中,一般搭建台数为奇数
好了,现在如果主节点坏了,能够用备用节点替换了。那么问题来了,由谁去启动切换呢?当然是你啦!还要我给你去切换啊,但是这样切换似乎不太现实,谁知道他什么时候崩啊!总不能搬个凳子坐那看着吧,还下不下班啦!
所以这个时候,我们就需要了解一个东西了,zookeeper,我们知道(管你知不知道),zookeeper组件在集群中应用很广泛,因为它具有监控通知功能。如何监控?如何通知?
zookeeper:
首先,我们的主节点和备用节点,必须都去向zookeeper进行注册,注册能干嘛?首先呢,谁注册得早,谁就是主节点,另外一个就是备用节点,其次,在主备进行了注册后,zookeeper将会在主备节点上分别启动一个FailoverController进程,简称zkfc,这个进程的目的就是监控主备的健康状况,每隔一定的时间,会向zookeeper发送心跳,如果主节点挂掉了,那么这个心跳也就消失了,zookeeper察觉到这个异常后,会马上通知备用节点,让备用节点上位,接替主节点的工作。如果主节点被救回来了呢?就回来也就是当个备用了,咋的,回来了就想上位啊?这点与zookeeper集群有些不同(稍微拓展下),三个zookeeper共同合作,其中有一个loader,其余两个flower,在它们之间也是有一些竞选机制的,这里面有一个比较简单的竞选的机制,那就是根据myid,我们在部署zookeeper就设置了这个myid,这个id的作用就是与竞选有关,数字越大,在集群启动的时候,越容易当loader。
整个过程就是这样,如有叙述有误,欢迎指点!