Hadoop相关的面试(Namenode的HA实现策略)

什么是NameNode 的HA机制,在早期的Hadoop1.x中,网满都知道对外提供的的主要服务是Namenide提供,早期的Hadoop中并没有实现Namenode的高可用策略,即Namenode的Ha机制,当Namenode所在的机器宕机,整个Hadoop应用将面临奔溃问题,由此在Hadoop2.x中出现Namenode的Ha机制 ,主要实现方式有2种

         1>第一种实现方式基于zk的选举方式实现

                                      实现思想|:2个Namenode分别独立运行在2个物理节点上,对外提供服务的为主Namenode,即为Active  Namenode,处于热备状态的为Standby  Namenode  ,当Active  Namenode所在的机器宕机之后,Standby具备什么样的条件才能接受之前Active  Namenode的工作呢?我主要总结2点

                                                                  a:Standby Namenode拥有之前Active namenode的对外提供的所有服务信息,这就需要ZK维护一组守护进程journal node,,处于工作状态的Active  node需要将自己对外提供的所有服务信息写在一半以上的journode node的目录里(这些信息被记为editlog) 处于热备状态的 Standby namenode会随时监听journalode的工作目录,只要有所更新改变,热备状态下的Standby  node会读取这些信息。并更新自己内部的名命空间,此时Standy namenodeActive  namenode都拥有对外提供的服务信息

                                                                b:所有的Datanode都要向主Namenode和热备Namenode进行心跳报告,使得2个namenode都了解datanode的健康状态以及数据存放在哪个Datanode上.

      总上所述,基于zk实现的Ha的机制,具备以上条件,就是一个真正意义上的HA

       2>第二种实现方式,基于facebook的Avator  node实现 

                                       实现思想:基于这种方式是需要进行人工的切换来实现,Avator node是对namenode的进行的封装,处于工作状态的是primary avator,处于热备状态的是standby  avator,其中primary avator相当于Active node,standby  avator是对namenode和secondary node进行的封装,2者共享同一个editlog工作目录,使得2个namenode都拥有相同的对外提供服且datanode都向2个封装的namenode报告心跳报告,当primary avator所在的机器挂掉之后,管理人员可以手动切换standby  avator对外提供服务

              总结:基于Ha的实现2种机制,满足的条件的是相同的,且zk是最佳选择,因为不需要管理人员的干涉,志需要zk去监听namenode的健康状态,基于后者需要管理人员的干涉,会消费一定的时间开销。所以基于zk是最佳的选择,你觉的呢?欢迎留言,说说你的想法,也是我学习大数据的必须条件,谢谢

      

猜你喜欢

转载自blog.csdn.net/w5201314ws6123/article/details/87886640