NameNode HA
（1） 基于NFS共享存储解决方案
（2） 基于Qurom Journal Manager（QJM）解决方案
NameNode Federation
（1） 存在多个NameNode，每个NameNode分管一部分目录
（2） NameNode共用DataNode
一、HDFS的新特性HA
(一) HDFS的HA机制
Hadoop 2.2.0 版本之前，NameNode是HDFS集群的单点故障点，每一个集群只有一个NameNode ，如果这个机器或者进程不可用，整个集群就无法使用，直到重启NameNode或者新重启一个NameNode节点 。
影响HDFS集群不可用主要包括以下两种情况：(1)类似机器跌宕这样的意外情况将导致集群不可用，只有重启NameNode之后才可使用。
(2) 计划内的软件或硬件升级（NameNode节点）将导致集群在短时间范围内不可用。
HDFS的高可用性（HA ,High Availability）就可以解决上述问题，通过提供选择运行在同一集群中的一个热备用的 "主/备"两个冗余NameNode，允许在机器宕机或系统维护的时候，快速转移到另一个NameNode。
(二) 典型的HA集群
一个典型的HA集群，两个单独的机器配置为NameNodes，在任何时候，一个NameNode处于活动状态，另一个处于待机状态，活动的NameNode负责处理集群中所有客户端的操作，待机时仅仅作为一个slave，保持足够的状态，如果有必要提供一个快速的故障转移。
为了保持备用节点与活动节点状态的同步，目前的实现需要两个节点同时访问一个共享存储设备（例如从NASNFS挂载）到一个目录。
当活动节点对命名空间进行任何修改，它将把修改记录写到共享目录下的一个日志文件，备用节点会监听这个目录，当发现更改时，它会把修改内容同步到自己的命名空间。备用节点在故障转移时，它将保证已经读取了所有共享目录内的更改记录，保证在发生故障前的状态与活动节点保持完全一致。
为了提供快速的故障转移，必须保证备用节点有最新的集群中块的位置信息，为了达到这一点，Datanode节点需要配置两个nameNode的位置，同时发送块的位置信息和心跳信息到两个nameNode。
任何时候只有一个namenode处于活动状态，管理员必须为共享存储配置至少一个（fencing“规避”）方法。在宕机期间，如果不能确定之间的活动节点已经放弃活动状态，fencing进程负责中断以前的活动节点编辑存储的共享访问。这可以防止任何进一步的修改命名空间，允许新的活动节点安全地进行故障转移。
(三) HA架构
1、只有一个NameNode是Active的，并且只有这个ActiveNameNode能提供服务，改变NameNode。以后可以考虑让StandbyNameNode提供读服务。
2、提供手动Failover（故障切换），在升级过程中，Failover在NameNode-DataNode之间写不变的情况下才能生效。
3、在之前的NameNode重新恢复之后，不能提供failback。
4、数据一致性比Failover更重要。
5、尽量少用特殊的硬件。
6、HA的设置和Failover都应该保证在两者操作错误或者配置错误的时候，不得导致数据损坏。
7、NameNode的短期垃圾回收不应该触发Failover。
8、DataNode会同时向NameNodeActive和NameNodeStandby汇报块的信息。NameNodeActive和NameNodeStandby通过NFS备份MetaData信息到一个磁盘上面。
简述 Hadoop HA 机制？（面试题）
答题思路从以下四大点，如下：HA 实现的两个核心要点：
（1） 故障转移的实现
（2） 共享存储的实现
Hadoop HA 的两个方面体现：
（3） NameNode HA
（4） ResourceManager HA
（1） 故障转移的实现（也称为NameNode 实现主备切换）
1、HealthMonitor 初始化完成之后会启动内部的线程来定时调用对应 NameNode 的 HAServiceProtocol RPC 接口的方法，对 NameNode 的健康状态进行检测。
2、HealthMonitor 如果检测到 NameNode 的健康状态发生变化，会回调 ZKFailoverController 注册的相应方法进行处理。
3、如果 ZKFailoverController 判断需要进行主备切换，会首先使用 ActiveStandbyElector 来进行自动的主备选举。
4、ActiveStandbyElector 与 Zookeeper 进行交互完成自动的主备选举。
5、ActiveStandbyElector 在主备选举完成后，会回调 ZKFailoverController 的相应方法来通知当前的 NameNode 成为主 NameNode 或备 NameNode。
6、ZKFailoverController 调用对应 NameNode 的 HAServiceProtocol RPC 接口的方法将 NameNode 转换为 Active 状态或 Standby 状态。
（2） 共享存储的实现（也称为基于 QJM 的共享存储系统的数据同步）
基于 QJM 的共享存储系统主要用于保存 EditLog，并不保存 FSImage 文件。 FSImage文件还是在 NameNode 的本地磁盘上。 QJM 共享存储的基本思想来自于 Paxos 算法，采用多个称为 JournalNode 的节点组成的 JournalNode 集群来存储 EditLog。每个 JournalNode 保存同样的 EditLog 副本。每次 NameNode 写 EditLog 的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向 JournalNode 集群之中的每一个 JournalNode 发送写请求，只要大多数 (majority)的 JournalNode 节点返回成功就认为向 JournalNode 集群写入 EditLog 成功。如果有 2N+1 台JournalNode，那么根据大多数的原则，最多可以容忍有 N 台 JournalNode 节点挂掉。
（3） NameNode HA
使用Active NameNode，Standby NameNode 两个节点可以解决单点问题，两个节点通过JounalNode共享状态，通过ZKFC 选举Active ，监控状态，自动备份。
1）Active NameNode
接受client的RPC请求并处理，同时写自己的Editlog和共享存储上的Editlog，接收DataNode的Block report, block location updates和heartbeat。
2）Standby NameNode
同样会接到来自DataNode的Block report, block location updates和heartbeat，同时会从共享存储的Editlog上读取并执行这些log操作，保持自己NameNode中的元数据（Namespcae information + Block locations map）和Active NameNode中的元数据是同步的。所以说Standby模式的NameNode是一个热备（Hot Standby NameNode），一旦切换成Active模式，马上就可以提供NameNode服务。
3）JounalNode
用于Active NameNode ， Standby NameNode 同步数据，本身由一组JounnalNode节点组成，该组节点奇数个。
4）ZKFC
监控NameNode进程，自动备份。
（4） ResourceManager HA
由一对Active，Standby结点构成，通过RMStateStore存储内部数据和主要应用的数据及标记。目前支持的可替代的RMStateStore实现有：基于内存的MemoryRMStateStore，基于文件系统的FileSystemRMStateStore，及基于zookeeper的ZKRMStateStore。 ResourceManager HA的架构模式同NameNode HA的架构模式基本一致，数据共享由RMStateStore，而ZKFC成为 ResourceManager进程的一个服务，非独立存在。
二、HDFS的新特性Federation
HDFS Federation使用了多个独立的Namenode/namespace来使得HDFS的命名服务能够水平扩展。在HDFS Federation中的Namenode之间是联盟关系，他们之间相互独立且不需要相互协调。HDFS Federation中的Namenode提供了提供了命名空间和块管理功能。HDFS Federation中的datanode被所有的Namenode用作公共存储块的地方。每一个datanode都会向所在集群中所有的Namenode注册，并且会周期性的发送心跳和块信息报告，同时处理来自Namenode的指令。
Federation HDFS与当前HDFS的比较
当前HDFS只有一个命名空间（Namespace），它使用全部的块。而Federation HDFS中有多个独立的命名空间（Namespace），并且每一个命名空间使用一个块池（block pool）。
当前HDFS中只有一组块。而Federation HDFS中有多组独立的块。块池（block pool）就是属于同一个命名空间的一组块。
当前HDFS由一个Namenode和一组datanode组成。而Federation HDFS由多个Namenode和一组datanode，每一个datanode会为多个块池（block pool）存储块。
1.Block Pool(块池)
所谓Block pool(块池)就是属于单个命名空间的一组block(块)。每一个datanode为所有的block pool存储块。Datanode是一个物理概念，而block pool是一个重新将block划分的逻辑概念。同一个datanode中可以存着属于多个block pool的多个块。Block pool允许一个命名空间在不通知其他命名空间的情况下为一个新的block创建Block ID。同时，一个Namenode失效不会影响其下的datanode为其他Namenode的服务。当datanode与Namenode建立联系并开始会话后自动建立Block pool。每个block都有一个唯一的标识，这个标识我们称之为扩展的块ID（Extended Block ID）= BlockID+BlockID。这个扩展的块ID在HDFS集群之间都是唯一的，这为以后集群归并创造了条件。
Datanode中的数据结构都通过块池ID（BlockPoolID）索引，即datanode中的BlockMap，storage等都通过BPID索引。在HDFS中，所有的更新、回滚都是以Namenode和BlockPool为单元发生的。即同一HDFS Federation中不同的Namenode/BlockPool之间没有什么关系。Hadoop V0.23版本中Block Pool的管理功能依然放在了Namenode中，将来的版本中会将Block Pool的管理功能移动的新的功能节点中。
2.Datanode的改进
在datanode中，对应于每个Namnode都有一条相应的线程。每个datanode会去每一个Namenode注册，并且周期性的给所有的Namenode发送心跳及datanode的使用报告。Datanode还会给Namenode发送其所在的block pool的block report（块报告）。由于有多个Namenode同时存在，因此任何一个Namenode都可以随时动态加入、删除和更新。
3.Federation中的其他方面的改进
提供了工具，对于Namenode的初始化和退役的监控和管理。允许在datanode级别或者block pool级别的负载均衡。Datanode的后台守护进程，为Federation所做的磁盘和目录扫描。提供了显示Namenode的Block pool的使用状态的Web UI。还提供了对全部集群存储使用状态的UI展示。在Web UI中列出了所有的Namenode及其细节，如Namenode-BlockPoolID和存储的使用状态，失去联系的、活的和死的块信息。还有前往各个Namenode Web UI的链接。Datanode退役状态的展示。
4.多命名空间的管理问题
在一个集群中需要唯一的命名空间还是多个命名空间，核心问题命名空间中数据的共享和访问的问题。使用全局唯一的命名空间是解决数据共享和访问的一种方法。在多命名空间下，我们还可以使用Client Side Mount Table方式做到数据共享和访问。
5.Namespace Volume（命名空间卷）
一个Namespace和它的Block Pool合在一起称作Namespace Volume。Namespace Volume是一个独立完整的管理单元。当一个Namenode/Namespace被删除，与之相对应的Block Pool也也被删除。在升级时每一个Namespace Volume也会整体作为一个单元。
6.ClusterID
在HDFS Federation中添加了Cluster ID用来区分集群中的每个节点。当格式化一个Namenode时，这个ClusterID会自动生成或者手动提供。在格式化同一集群中其他Namenode时会用到这个ClusterID。
7.HDFS Federation对老版本的HDFS是兼容的
这种兼容性可以使得已有的Namenode配置不需要任何改变继续工作。
三、HDFS的新特性快照
在2.x终于实现了快照。设置一个目录为可快照：
hdfs dfsadmin -allowSnapshot <path>
取消目录可快照：
hdfs dfsadmin -disallowSnapshot <path>
生成快照：
hdfs dfs -createSnapshot <path> [<snapshotName>]
删除快照：
hdfs dfs -deleteSnapshot <path> <snapshotName>
快照位置
可快照目录下的snapshot子目录
列出所有可快照目录：
hdfs lsSnapshottableDir
比较快照之间的差异：
hdfs snapshotDiff <path> <fromSnapshot> <toSnapshot>