Hadoop 2.0 中 NameNode/ResourceManager HA 总结

本文主要是介绍Hadoop 2.0 中 NameNode/ResourceManager HA 总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本文部分转自 董的博客《Hadoop 2.0中单点故障解决方案总结》

---

一. 为什么需要 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 总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---