00:00
好,刚才呢,我们是搭建并启动了手动模式的一个HDFS高可用集群。很明显,最后我们提出了一个很重要的点,在我们没有其他进程参与的情况下,那么我们name note跟内note之间通信,它必须要所有人全部能联系上,才能将其中某一个节点提升为active。啊,那这个我们手动故障转移的,类似于这样的方式,其实就不叫高可用了,因为你随便就算现在我有三个name node,随便挂了其中一台,那集群也是没有办法工作了是不是。对吧,因为我要跟所有的节点进行一个通信啊,你挂了我就没办法提升为active啊,所以它是有问题的,那这样就引出了我们下面一个知识点叫自动模式啊,并不需要去手动,那其实这里边儿最核心的是解决的刚才我们最后那个问题。
01:04
啊,如何确认?当我要提升某一个节点为active的时候,我如何确认另外的节点?它不是active。对吧,一个很简单的方式,就是我们之前看到手动方式当中的,我们当前这个never note跟另外一个never note主动去连接一下。如果。能连上,你说自己是stand,那我当然可以提升为active。关键的问题在于,如果另外一个竞争挂掉了,你必然联系不上,那么联系不上能确定一定是挂掉了吗?这个就不能了,对吧?所以我们接下来看一下自动故障转移的工作机制,实际上它里边增加了to keep来帮助我们做刚才我们所不能完成的这个事情。啊,其实我们就引入了一个叫。它保存一些信息,可以监控我们内note是否是活着的啊呃,保存我们整个一个信息,通信信息,那么接下来还有一个进程叫ZKFC,它是用来控制什么呢?翻over controller,监控我们节点上的一个内容。
02:18
是否真正挂掉了,同时如果我监控到挂掉了是一个假死状态,那我再次发送一个K命令,真正的把你干掉,防止脑裂情况的一个产生,OK,那接下来呢,我们通过一个PPT了解一下整个的过程。好,我打开这个PPT给大家一块来看一下。首先。我们有多台,那note以两个为例对吧?好,那内存当中的一些原数据ID f image,这是我们对应的信息啊,那此时呢,有一个是active,一个是stand啊,那毋庸置疑肯定是这样子的,不可能两个都是active对吧?好,那么此时呢,我们需要由journal load来管理我们的is文件,它用来同步对吧?呃,同时呢,需要引入我们的。
03:11
ZK。啊,作为我们的服务啊,整个监控的一个工具啊,当然我们可以可以看到它到底在其中参与了什么样的一个内容,呃,那此时比方说。我们I如果挂掉了对吧,那此时呢,有另外一个进程叫CKFC来对于我们当前它所在节点上的namenode做监控,也就是未来我们启动namenode节点的。内note进程的节点都需要启动一个CKFC的进程啊,它是负责用来监控我们内note是否是存活状态的啊,那此时呢,比如说active active这台机电挂掉了,它有可能是一个假死状态,因为不太确定,不太确定是真的挂掉了,还是我当前这台机器跟这台机器联系不上。
04:10
对吧,好,那我认为它是一个假死状态,那接下来呢,由ZKFC监测到当前no的已经挂掉。啊,已经挂掉,挂掉好以后他就会通知另外name node上的一个ZKFC。啊,那么此时呢,防止你是甲挂掉,它会发送命令强行杀死我们,另外节点上的那的哎,确定杀死以后。在通知当前。内部弄的。去干什么事啊,启动进程啊,当然在这个过程当中,我们可以设计的更为复杂一点,因为防止这个开发命令干不掉,我们在用户自定一个脚本,调用SSH,再进行补刀啊,防止K失败,对吧,我再次进行补刀,让你撤离死透啊,彻离死透呢就是。
05:09
一个点防止脑裂。啊,防止脑裂,因为如果你没有死透,那么两个IP对于我们data not而言就疯了,两个老大到底该听谁的对吧?所以基本上核心的内容是在于,注意我们再看一遍啊,最核心的内容在于,哎,我们监测到itif这个节点挂掉了,我们目前认为它是一个假死状态。那么此时。当前I give namenode所在节点的ZKFC就会检测到namenoe挂掉,它会通知到另外一个CKFC,那另外的CFC呢,会发送命令强行的让干掉ne nod啊,之后呢,就可以通知我们nevernoe启动了,就可以做这个事情,但是防止这一次没有真正的干掉我们的进程,可以添加用户自定义的程序脚本。
06:10
对吧,调用SSH去补刀啊,补完刀之后呢,我们通过返回值去确认啊,之后呢,最终再激活当前这台服务器上的能note成为I,好,这个就是整个自动的一个过程,所以呢,需要ZK以及ZKFC进程的一个参与。啊好,这是我们所看到它的一个自动故障转移的一个运行机制啊,不需要手动去做这个事儿了。
我来说两句