2.Hadoop的HA运作机制：

　　：正式引入HA机制是从hadoop2.0开始，之前的版本中没有HA机制，

　　：Hadoop-HA集群运作机制介绍：所谓HA，即高可用（7*24小时不中断服务），实现高可用最关键的是消除单点故障

　　：Hadoop-HA严格来说应该分成各个组件的HA机制——HDFS的HA、YARN的HA

2.HDFS的HA机制详解：

　　1.可否通过keepalive来进行NameNode的高可用？不可以，因为NameNode上有大量的元数据状态信息需要维护

　　2.解决方法：

　　　　需要两个NameNode，一个对外工作(active)，一个后补(standby)，这就涉及到元数据同步的问题。可以

将edits保存到第三方，standy的NameNode即可收到edits，从而保持元数据的更新。为了系统的稳定，第三方的

组件最好也实现高可用。叫做qjournal，基于ZooKeeper实现的分布式系统，功能是进行edits日志管理。这样提

高了可靠性和可用性，但是牺牲了一部分数据一致性

　　如果active宕机了，standby立即可以切换到active状态并对外提供服务；需要一个状态管理功能模块。每个

NameNode中有个程序ZKFC(zkfailover Controller),基于ZooKeeper做状态切换,ZKFC通过RPC的接口调用NameNode，

然后就可以确认NameNode的状态。一旦active上面的ZKFC发现active挂掉了，它向ZooKeeper发送状态变化信息,

standby的ZKFC监听到节点变化后，通知NameNode切换到Active状态，随后在ZooKeeper上建立状态锁。通知切换之

前为了保证之前的NameNode一定被隔离，ZKFC会直接调用kill -9杀掉之前的NameNode进程,如果等一段时间没有响

应，会调用用户脚本来进行操作，用户脚本返回0表示隔离成功。

　　宕机的active重启后，ZKFC会检测到状态锁的存在，让其处于standby状态。此时不需要SecondaryNameNode了，

交给standby的NameNode负责

总结：

　　HDFS的HA机制通过双namenode消除单点故障

　　双namenode协调工作的要点：

　　A、元数据管理方式需要改变：内存中各自保存一份元数据，Edits日志只能有一份，只有Active状态的namenode节点可

以做写操作，两个namenode都可以读取edits，共享的edits放在一个共享存储中管理（qjournal和NFS两个主流实现）

　　B、需要一个状态管理功能模块：实现了一个zkfailover，常驻在每一个namenode所在的节点，每一个zkfailover负责监

控自己所在namenode节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain

split现象的发生