HDFS HA和Federation安装部署方法

HDFS HA和Federation安装部署方法

相比于Hadoop1.0，Hadoop 2.0中的HDFS增加了两个重大特性，HA和Federaion。HA即为High Availability，用于解决NameNode单点故障问题，该特性通过热备的方式为主NameNode提供一个备用者，一旦主NameNode出现故障，可以迅速切换至备NameNode，从而实现不间断对外提供服务。Federation即为“联邦”，该特性允许一个HDFS集群中存在多个NameNode同时对外提供服务，这些NameNode分管一部分目录（水平切分），彼此之间相互隔离，但共享底层的DataNode存储资源。

在一个典型的HDFSHA场景中，通常由两个NameNode组成，一个处于active状态，另一个处于standby状态。Active NameNode对外提供服务，比如处理来自客户端的RPC请求，而Standby NameNode则不对外提供服务，仅同步active namenode的状态，以便能够在它失败时快速进行切换。

为了能够实时同步Active和Standby两个NameNode的元数据信息（实际上editlog），需提供一个共享存储系统，可以是NFS、QJM（Quorum Journal Manager）或者Bookeeper，Active Namenode将数据写入共享存储系统，而Standby监听该系统，一旦发现有新数据写入，则读取这些数据，并加载到自己内存中，以保证自己内存状态与Active NameNode保持基本一致，如此这般，在紧急情况下standby便可快速切为active namenode。

解析Hadoop 2.3.0版本的新特性

2014年2月20日，Hadoop 2.3.0版本发布，这是apache 在2014年发布的第一个Hadoop版本，揭开了Hadoop 2014发展的序幕。

该版本引入了很多大家期待已久的特性，包括HDFS 的异构层次化存储架构、DataNode Cache，YARN的单点故障解决方案，以及MapReduce的自动化部署等。本文尝试为大家解析这些特性，并给出一些资料供大家深入了解。

HDFS新特性。 2.3.0中引入了两个大的HDFS特性，分别是异构层次化存储架构和DataNode Cache。首先是异构层次化存储架构，在之前的版本，HDFS默认DataNode上所有的存储介质是磁盘，即用户所有数据存储在磁盘上，不管是热数据还是冷数据。但随着近几年存储介质的高速发展，SSD、Flash等新型介质日益成熟，HDFS开始尝试支持异构介质，即同一个Hadoop集群中可以同时存在多种存储介质，用户可根据需要将不同类型的数据存放到不同介质中，比如热点数据存到SSD中，海量的网页数据放到磁盘中。异构层次化存储架构的引入，使得HDFS应用范围更广。第二个特性是DataNode Cache。在旧版本中，HDFS DataNode并未考虑数据缓存，毕竟HDFS定位是一个分布式磁盘存储系统，但随着HDFS之上计算框架多样化的出现，比如流式计算框架Storm，内存计算框架Spark、DAG计算框架Tez等，Hadoop不再仅仅把自己局限在离线处理和分析上，而是能够同时支持离线分析和在线处理，为此，为了能够更好地支持在线处理，降低在线应用的延迟，提高性能，DataNode Cache出现了（值得一提的是，Spark生态系统中的Tachyon存储系统，便是一个构建在HDFS之上的内存系统）。这两个功能都是Hadoop全功能型系统发展的必然产物，HDFS从此不再局限于存储一些离线的批处理数据，也开始尝试支持存储在线数据。这两个功能的设计文档可参考：

https://issues.apache.org/jira/browse/HDFS-2832

https://issues.apache.org/jira/browse/HDFS-4949

需要注意的是，目前这两个特性正处于初期发展阶段，尽管愿景很美好，但目前仅仅实现了最基本的功能，很多功能尚未实现，比如异构层次化存储架构中，想让一个block的三个副本，一个存储在SSD上，另外两个存储在磁盘上。

YARN新特性。YARN目前存在最大的问题是ResourceManager单点故障，该问题是目前最急需解决的遗留问题之一，若不解决，YARN作为资源管理系统就无法承载更多类型的应用。在2.3.0版本中，该问题基本得到了解决，解决方案类似于NameNode HA，是通过Zookeeper实现的。但还不推荐大家使用该版本中的HA方案，而是建议在下一个版本2.4.0中使用。除了HA外，还有两个非常重要的功能将在下一个版本中发布，分别是Generic Application Timeline和Generic Application Timeline Log。第一个特性是Generic Application Timeline，该特性提供了一个共享存储模块，供YARN之上的应用程序存储一些自己的数据，比如运行事件、运行日志等；第二个特性则解决了YARN之上应用程序历史日志管理问题，目前仅有MapReduce可以查看和管理history log，其他应用程序，比如Spark等，不能查看，需要由各个框架/应用程序自行解决该问题，为了防止重复造轮子，YARN干脆提供了一个通用的历史日志管理模块。这两个功能的设计文档可参考：

https://issues.apache.org/jira/browse/YARN-1530

https://issues.apache.org/jira/browse/YARN-321

MapReduce新特性。在Hadoop 2.0中，MapReduce jar包是同YARN和HDFS jar包打包在一起的，部署Hadoop时会一同被分发到各个节点上的，这实际上违背了YARN的设计初衷。YARN是一个资源管理系统，其上面所有应用程序不需要事先部署到各个节点上，只需在客户端存在一份jar包，然后由YARN自动分发到各个节点上即可，为此，Hadoop 2.3.0对此进行了修正。值得一提的是，Spark和Storm等程序不存在这个问题，这使得同一集群中可以运行不同版本的Spark和Storm实例。具体可参考：

https://issues.apache.org/jira/browse/MAPREDUCE-4421