详解hadoop之三：hadoop高可靠（HA）

hadoop1.x中的namenode和secondary namenode 

在hadoop1.x中，hdfs集群的namenode存在单点故障，一旦namenode出现故障，整个集群将不可用
secondary namenode并没有提供故障转移的能力，集群的可用性受到影响
secondary namenode只是周期性的把edit logs文件更新到fsimage，namenode在重启的时候会读取新的fsimage文件，以减少启动时间
namenode 
namenode主要用来保存hdfs的元数据信息，比如命名空间信息，块信息等。当它运行的时候，这些信息是保存在内存中的
这些信息也会持久化到磁盘上一份，集群重启的时候会用到

1. fsimage：是namenode启动时对整个文件系统的快照
2. edit logs：在namenode启动后，对文件系统的改动记录
3. 只有在namenode重启时，namenode才会把edit logs合并到fsimage，在集群中namenode是很少重启的，这样edit logs就会变的很大。

edit logs过大存在两个问题
1.edit logs过大，怎样去管理是一个挑战
2.namenode重启会花费大量时间

为了解决这些问题，引入了secondary namenode

secondary namenode的主要作用就是把edit logs中的内容合并到fsimage，只是namenode的一个助手，是namenode的一个检查节点

hadoop HA 

    hadoop HA是通过配置两个namenode来解决单点故障问题。两个namenode分别是active namenode和standby namenode，standby作为热备份，从而在主namenode发生故障是迅速进行故障转移，两个namenode只能一主一辅

通过使用journal node完成两个namenode的元数据同步，通过使用zookeeper完成namenode的故障转移（自动）

1.共享存储(shared edits)
active namenode处理所有的操作请求（读写），standby namenode只同步状态
datanode会同时向两个namenode发送block报告和心跳
当满足一次checkpoint时，standby namenode进行一次合并操作
active NN执行任何命名空间的修改都会持久化到一半以上的journalnodes上
而Standby NN负责观察edits log的变化，它能够读取从JNs中读取edits信息，并更新其内部的命名空间
一旦Active NN出现故障，Standby NN将会保证从JNs中读出了全部的Edits，然后切换成Active状态
一次checkpoint过程
（1）、配置好HA后，客户端所有的更新操作将会写到JournalNodes节点的共享目录中
（2）、Active Namenode和Standby NameNode从JournalNodes的edits共享目录中同步edits到自己edits目录中；
（3）、Standby NameNode中的StandbyCheckpointer类会定期的检查合并的条件是否成立，如果成立会合并fsimage和edits文件；
（4）、Standby NameNode中的StandbyCheckpointer类合并完之后，将合并之后的fsimage上传到Active NameNode相应目录中；
（5）、Active NameNode接到最新的fsimage文件之后，将旧的fsimage和edits文件清理掉；
（6）、通过上面的几步，fsimage和edits文件就完成了合并，由于HA机制，会使得Standby NameNode和Active NameNode都拥有最新的fsimage和edits文件
（之前Hadoop 1.x的SecondaryNameNode中的fsimage和edits不是最新的）

2.如何防止namenode脑裂（两个namenode都处于active状态）
Journal Node通过epoch数来解决脑裂的问题，称为JournalNode fencing。具体工作原理如下： 
1）当Namenode变成Active状态时，被分配一个整型的epoch数，这个epoch数是独一无二的，并且比之前所有Namenode持有的epoch number都高。
2）当Namenode向Journal Node发送消息的时候，同时也带上了epoch。当Journal Node收到消息时，将收到的epoch数与存储在本地的promised epoch比较，
   如果收到的epoch比自己的大，则使用收到的epoch更新自己本地的epoch数。如果收到的比本地的epoch小，则拒绝请求。
3）edit log必须写入大部分节点才算成功，也就是其epoch要比大多数节点的epoch高。

3.namenode如何通过zookeeper进行自动故障转移
失败检测：每个namenode都会在zookeeper中获取一个持久性session，如果namenode故障，则session过期，使用zk的事件机制通知其他namenode需要故障转移

namenode选举：如果当前active namenode挂了，standby namenode会尝试从ZK获取一个排他锁，获取这个锁就代表他称为下一个activenamenode

而在故障自动转移的处理上，引入了监控Namenode状态的ZookeeperFailController（ZKFC）。
ZKFC一般运行在Namenode的宿主机器上，与Zookeeper集群协作完成故障的自动转移