标签：
为什么会出现Hadoop2？
Hadoop1的问题
- hdfs的namenode和mapreduce的jobtracker都是单点。
- namenode所在的服务器的内存不够用时，那么集群就不能工作了。
- mapreduce集群的资源利用率比较低。
Hadoop1和Hadoop2对比
MapReduce 资源管理和数据处理
YARN 资源管理
Hadoop的重大改进:HA和Federation
为什么需要HA和Federation？
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等等。
2. 集群容量和集群性能
单NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。同时，所有的元数据信息的读取和操作都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。Hadoop 2.0里的HDFS Federation就是为了解决这两个问题而开发的。
Hadoop的HA--->解决单点问题
Hadoop的Federation 解决 namenode所在的服务器的内存不够用时，那么集群就不能工作了。问题
federation的含义是NameNode不同享，DataNode共享。
这个图过于简明，许多设计上的考虑并不那么直观，我们稍微总结一下
多个NN共用一个集群里DN上的存储资源，每个NN都可以单独对外提供服务
每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储
DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况
如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录
这样设计的好处大致有：
改动最小，向前兼容
现有的NN无需任何配置改动.
如果现有的客户端只连某台NN的话，代码和配置也无需改动。
分离命名空间管理和块存储管理
提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池
统一的块存储管理保证了资源利用率
可以只通过防火墙配置达到一定的文件访问隔离，而无需使用复杂的Kerberos认证
客户端挂载表
通过路径自动对应NN
使Federation的配置改动对应用透明
HA的自动failover
在这个图里，我们可以看出HA的大致架构，其设计上的考虑包括：
利用共享存储来在两个NN间同步edits信息。
以前的HDFS是share nothing but NN，现在NN又share storage，这样其实是转移了单点故障的位置，但中高端的存储设备内部都有各种RAID以及冗余硬件包括电源以及网卡等，比服务器的可靠性还是略有提高。通过NN内部每次元数据变动后的flush操作，加上NFS的close-to-open，数据的一致性得到了保证。社区现在也试图把元数据存储放到BookKeeper上，以去除对共享存储的依赖，Cloudera也提供了Quorum Journal Manager的实现和代码，这篇中文的blog有详尽分析：基于QJM/Qurom Journal Manager/Paxos的HDFS HA原理及代码分析
DataNode(以下简称DN)同时向两个NN汇报块信息。
这是让Standby NN保持集群最新状态的必需步骤，不赘述。
用于监视和控制NN进程的FailoverController进程
显然，我们不能在NN进程内进行心跳等信息同步，最简单的原因，一次FullGC就可以让NN挂起十几分钟，所以，必须要有一个独立的短小精悍的watchdog来专门负责监控。这也是一个松耦合的设计，便于扩展或更改，目前版本里是用ZooKeeper(以下简称ZK)来做同步锁，但用户可以方便的把这个ZooKeeper FailoverController(以下简称ZKFC)替换为其他的HA方案或leader选举方案。
隔离(Fencing))，防止脑裂)，就是保证在任何时候只有一个主NN，包括三个方面：
共享存储fencing，确保只有一个NN可以写入edits。
客户端fencing，确保只有一个NN可以响应客户端的请求。
DataNode fencing，确保只有一个NN可以向DN下发命令，譬如删除块，复制块，等等。
Hadoop yarn平台
Hadoop2.0
标签：
原文地址：http://www.cnblogs.com/thinkpad/p/5049434.html
