5，Hadoop2.0 HA
Hadoop2.0产生的原因
HDFS存在的两个问题：
1，NameNode单点故障，难以应用于在线场景
2，NameNode压力过大，且内存受限，影响扩展性。
Hadoop 2.0产生背景
Hadoop 1.0中HDFS和MapReduce在高可用、扩展性等方面存在问题
HDFS存在的问题
NameNode单点故障，难以应用于在线场景 HA
NameNode压力过大，且内存受限，影响系统扩展性 Federation
MapReduce存在的问题
JobTracker访问压力大，影响系统扩展性
难以支持除MapReduce之外的计算框架，比如Spark、Storm等
Hadoop 2.x由HDFS、MapReduce和YARN三个分支构成；
HDFS：NN Federation（联邦）、HA；
2.X:只支持2个节点 HA，3.0实现了一主多从
MapReduce：运行在YARN上的MR；
离线计算，基于磁盘I/O计算
YARN：资源管理系统
HDFS 2.x
解决HDFS 1.0中单点故障和内存受限问题。
解决单点故障
HDFS HA：通过主备NameNode解决
如果主NameNode发生故障，则切换到备NameNode上
解决内存受限问题
HDFS Federation(联邦)
水平扩展，支持多个NameNode；
（2）每个NameNode分管一部分目录；
（1）所有NameNode共享所有DataNode存储资源
2.x仅是架构上发生了变化，使用方式不变
对HDFS使用者透明
HDFS 1.x中的命令和API仍可以使用
HA情况：
在1.x中的时候一个叫NameNode一个叫SecondaryNameNode，SecondaryNameNode没有对外提供服务的能力，只是合成edits log和Fsimage。
在2.x中的时候，一个叫active NameNode 一个叫standby NameNode，一主和一备。这两个的配置必须一模一样，谁是主谁是备已经不那么重要了，但是只能有一个主。如果active挂掉了，那么standby的NameNode的状态可以被人为手动的提升成active去提供服务。
为了便于讲解清楚我个人将NameNode中元数据分为两类：
- 静态元数据（相对静态，，会做持久化）比如目录树结构，路径，文件名文件大小，持有者，偏移量等与客户端增删改交互的一些信息.
- 动态元数据（与DataNode交互的一些信息,不会做持久化）集群启动时NameNode与DataNode通信时做心跳DataNode汇报上来的。
做HA高可用意为这其中一台NameNode坏了另外一台NameNode可以接手服务。那么两台NameNode中元数据应该尽量一模一样，静态元数据是来自客户端的增删改操作记录的信息，动态元数据来自DataNode的汇报。
动态元数据如何保持一致：
如上图下面的两个绿色箭头所示，动态元数据可以由DataNode同时向两台NameNode汇报，但是由于客户端只于active的NameNode保持通信，静态元数据standby这台NameNode应该如何同步过来呢?
静态元数据如何保持一致：
引入一个新概念：NFS （NetWork File System）网络文件系统,但是NFS是单点的，因此
如上图所示用一个JN（journalnode）集群来实现两个NameNode之间的静态元数据的同步。两个NameNode都指向JN集群中的fsimage和edits log文件目录，但是在某一时刻，应该是active的NameNode写入，standby的NameNode读出。
至此两个NameNode中的元数据就保持了一致。任意一方挂了，另一方切换状态即可提供服务。
自动化HA：将这种主备切换的事情交给计算机做，原则：当想去解决一个问题的时候不要再引入一个新的问题。比如此时就不能将这个主备切换的问题交给一台服务器控制，因为一台服务器也容易有单点故障的可能。不能为了解决这个问题而引入一个新的问题，因此采用的是集群技术三个结点或者更多结点。Zookeeper分布式协调服务来解决自动化切换（与keepalive类似，但是有差异）。
如上图，两个NameNode所在的服务器中分别有一个控制器，控制器会精准的判断NameNode的存活。集群关掉，同一时刻开启两个NameNode，同时两个控制器就也启动起来了，控制器首先分别与所在结点的NameNode通信判断NameNode是否存活。当两者都判断存活时，由于一个集群只能有一个active，在某一个结点下二者竞争看哪个能在ZK上优先创建一个结点，那么这个NameNode就是active。
HDFS 2.0 HA
主备NameNode
解决单点故障（属性，位置）
主NameNode对外提供服务，备NameNode同步主NameNode元数据，以待切换
所有DataNode同时向两个NameNode汇报数据块信息（位置）
JNN:集群（属性）
standby：备，完成了edits.log文件的合并产生新的image，推送回ANN
两种切换选择
手动切换：通过命令实现主备之间的切换，可以用HDFS升级等场合
自动切换：基于Zookeeper实现
基于Zookeeper自动切换方案
ZooKeeper Failover Controller：监控NameNode健康状态，
并向Zookeeper注册NameNode
NameNode挂掉后，ZKFC为NameNode竞争锁，获得ZKFC 锁的NameNode变为active
HDFS 2.x Federation
通过多个namenode/namespace把元数据的存储和管理分散到多个节点中，使到namenode/namespace可以通过增加机器来进行水平扩展。
能把单个namenode的负载分散到多个节点中，在HDFS数据规模较大的时候不会也降低HDFS的性能。可以通过多个namespace来隔离不同类型的应用，把不同类型应用的HDFS元数据的存储和管理分派到不同的namenode中。