本文主要是介绍Hadoop 2.0 中 NameNode/ResourceManager HA 总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本文部分转自 董的博客《Hadoop 2.0中单点故障解决方案总结》
- 一 为什么需要 HA 和 Federation
- 1 单点故障
- 2 集群容量和集群性能
- 二 Hadoop 20 三个系统简介
- 1 HDFS 基础架构
- 2 YARN 基础架构
- 3 MapReduce
- 三 Hadoop HA 架构
- 1 HDFS 的 HA 架构
- 2 YARN 的 HA 架构
- 3 Hadoop HA 解决方案架构
- 4 构成 Hadoop HA 的组件
- 5 Hadoop HA 需要考虑的问题
- 6 Hadoop HA 小结
一. 为什么需要 HA 和 Federation
1.1 单点故障
在 Hadoop 2.0 之前，也有若干技术试图解决单点故障的问题，我们在这里做个简短的总结
Secondary NameNode
它不是 HA，它只是阶段性的合并 edits 和 fsimage，以缩短集群启动的时间。当 NameNode (以下简称NN )失效的时候，Secondary NN 并无法立刻提供服务，Secondary NN 甚至无法保证数据完整性：如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。Backup NameNode (HADOOP-4539)
它在内存中复制了 NN 的当前状态，算是 Warm Standby，可也就仅限于此，并没有 failover 等。它同样是阶段性的做 checkpoint，也无法保证数据完整性。手动把 name.dir 指向 NFS
这是安全的 Cold Standby，可以保证元数据不丢失，但集群的恢复则完全靠手动。Facebook AvatarNode
Facebook 有强大的运维做后盾，所以 Avatarnode 只是 Hot Standby，并没有自动切换，当主 NN 失效的时候，需要管理员确认，然后手动把对外提供服务的虚拟 IP 映射到 Standby NN，这样做的好处是确保不会发生脑裂的场景。其某些设计思想和 Hadoop 2.0 里的 HA 非常相似，从时间上来看，Hadoop 2.0 应该是借鉴了 Facebook 做法。
还有若干解决方案，基本都是依赖外部的HA机制，譬如 DRBD，Linux HA，VMware 的 FT 等等。
1.2 集群容量和集群性能
单 NN 的架构使得 HDFS 在集群扩展性和性能上都有潜在的问题：
NN 进程使用的内存可能会达到上百G
常用的估算公式为 1G 对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。所有的元数据信息的读取和操作都需要与 NN 进行通信
譬如客户端的 addBlock、getBlockLocations，还有 DataNode 的 blockRecieved、sendHeartbeat、blockReport。
当集群大到一定程度后，NN 成为了性能的瓶颈。 Hadoop 2.0 里的 HDFS Federation 就是为了解决这两个问题而开发的。
二. Hadoop 2.0 三个系统简介
1. Hadoop 1.0 内核主要由两个分支组成：MapReduce 和 HDFS
众所周知，这两个系统的设计缺陷是单点故障，即 MR 的 JobTracker 和 HDFS 的 NameNode 两个核心服务均存在单点问题，该问题在很长时间内没有解决，这使得 Hadoop 在相当长时间内仅适合离线存储和离线计算。但这些问题在 Hadoop 2.0 中得到了非常完整的解决。
2. Hadoop 2.0 内核由三个分支组成，分别是 HDFS、MapReduce 和 YARN
而 Hadoop 生态系统中的其他系统，比如
这篇关于Hadoop 2.0 中 NameNode/ResourceManager HA 总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
