1.Hadoop2.0产生背景
早期的hadoop版本，NN(namenode)是HDFS集群的单点故障点，每一个集群只有一个NN,如果这个机器或进程不可用，整个集群就无法 使用。为了解决这个问题，出现了一堆针对HDFS HA的解决方案（ 如：Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等 ）; 在HA具体实现方法不同的情况下，HA框架的流程是一致的, 不一致的就是如何存储和 管理日志。在Active NN和Standby NN之间要有个共享的存储日志的地方，Active NN把EditLog写到这个共享的存储日志的地方， Standby NN去读取日志然后执行，这样Active和Standby NN内存中的HDFS元数据保持着同步。一旦发生主从切换Standby NN可以尽快接 管Active NN的工作.
以上内容摘自培训班老师文档
2.Hadoop1.0与Hadoop2.0区别
SecondaryNameNode 主要是在Hadoop1.x中存在，而在2.x中是在没有配置高可用的时候会存在。
3.HDFS 2.x：解决HDFS 1.0中单点故障和内存受限问题
- 解决单点故障
HDFS HA：通过主备NameNode解决
如果主NameNode发生故障，则切换到备NameNode上
- 解决内存受限问题
HDFS Federation(联邦)
水平扩展，支持多个NameNode；
每个NameNode分管一部分目录；
所有NameNode共享所有DataNode存储资源
- 2.x仅是架构上发生了变化，使用方式不变，对HDFS使用者透明，HDFS 1.x中的命令和API仍可以使用
4.HDFS 2.0 联邦制（Federation）
通过多个namenode/namespace把元数据的存储和管理分散到多个节点中，使到namenode/namespace可以通过增加机器来进行水平扩展。
能把单个namenode的负载分散到多个节点中，在HDFS数据规模较大的时候不会也降低HDFS的性能。可以通过多个namespace来隔离不同类型的应用，把不同类型应用的HDFS元数据的存储和管理分派到不同的namenode中。
上图摘自官网（http://hadoop.apache.org/docs/r2.7.4/hadoop-project-dist/hadoop-hdfs/Federation.html）
5.HDFS HA
5.1HA的作用
- 主备NameNode
- 解决单点故障
1.主NameNode对外提供服务，备NameNode同步主NameNode元数据，以待切换
2.所有DataNode同时向两个NameNode汇报数据块信息
- 两种切换选择
1.手动切换：通过命令实现主备之间的切换，可以用HDFS升级等场合
2.自动切换：基于Zookeeper实现
- 基于Zookeeper自动切换方案
1.ZooKeeper Failover Controller：监控NameNode健康状态，
2.并向Zookeeper注册NameNode
3.NameNode挂掉后，ZKFC为NameNode竞争锁，获得ZKFC 锁的NameNode变为active
5.2 HA原理
需要做HDFS HA的话，首先需要保证namenode中的fsimage和edits文件一致，需要产生的时候（格式化的时候）就保持一致。
fsImage保证一致做法：需要在一台NameNode上生成后，拷贝到另外的NameNode上。
如何保证edits文件在所有NameNode一致？因为edits在HDFS文件发生变化时，edits文件就会发生变化，故需要借助第三方处理。
利用NFS,是FreeBSD支持的文件系统中的一种，它允许网络中的计算机之间通过TCP/IP网络共享资源，但是此种方式并不是真正意义上的高可用，在资源共享主机宕机后，就不可服务了。
采用QJM（Quorum Journal Manager）的方式进行高可用：所有的edits文件交由JN管理，即使NameNode挂了也没事。
