在熟悉Hadoop2架构的过程耽误了太长时间，在搭建环境过程遇到一些问题，这些问题一直卡在那儿，不得以解决，耽误了时间。最后，千寻万寻，把问题解决，多谢在过程提供帮助的大侠。在《Hadoop2.5.2+HA+Zookeeper3.4.6配置过程详解》这篇文章中，我也会把自己遇到的问题给列出来，帮助后来者进一步的学习。
这篇文章结合自己实际测试过程，花费太多心血整理。
前言
本文主要通过对hadoop2.5.2集群配置的过程加以梳理，所有的步骤都是通过自己实际测试。文档的结构也是根据自己的实际情况而定，同时也会加入自己在实际过程遇到的问题。搭建环境过程不重要，重要点在于搭建过程中遇到的问题，解决问题的过程。
可能自己遇到的问题在一些由经验的老者手上都不是问题，但是这些问题着实让自己耽误了很长时间，最后问题解决也是费了太大心血。也通过这篇文档，表现出来，算是总结，为后者提供意见。
Hadoop2.5.2体系结构
要想理解本节内容，首先需要了解hadoop1的体系结构。这里不过多的介绍基于hadoop1的体系架构，早在之前，曾搭建hadoop1.2.1伪分布式集群，详细请看hadoop学习（一）hadoop-1.2.1伪分布式配置及遇到的问题。这里主要介绍hadoop2的体系架构。
hadoop1的核心组成是两部分，即HDFS和MapReduce。在hadoop2中变为HDFS和Yarn。
新的HDFS中的NameNode不再是只有一个了，可以有多个（目前只支持2个）。每一个都有相同的职能。
这两个NameNode的地位如何：一个是active状态的，一个是standby状态的。当 集群运行时，只有active状态的NameNode是正常工作的，standby状态的NameNode是处于待命状态的，时刻同步active状态 NameNode的数据。一旦active状态的NameNode不能工作，通过手工或者自动切换，standby状态的NameNode就可以转变为 active状态的，就可以继续工作了。这就是高可靠。
当NameNode发生故障时，他们的数据如何保持一致：在这里，2个NameNode的数据其实是实时共享的。新HDFS采用了一种共享机制，JournalNode集群或者NFS进行共享。NFS是操作系统层面的，JournalNode是hadoop层面的，我们这里使用JournalNode集群进行数据共享。
如何实现NameNode的自动切换：这就需要使用ZooKeeper集群进行选择了。HDFS集群中的两个NameNode都在ZooKeeper中注册，当active状态的NameNode出故障时，ZooKeeper能检测到这种情况，它就会自动把standby状态的NameNode切换为active状态。
HDFS Federation（HDFS联盟）：联盟的出现是有原因的。我们知道 NameNode是核心节点，维护着整个HDFS中的元数据信息，那么其容量是有限的，受制于服务器的内存空间。当NameNode服务器的内存装不下数据后，那么HDFS集群就装不下数据了，寿命也就到头了。因此其扩展性是受限的。HDFS联盟指的是有多个HDFS集群同时工作，那么其容量理论上就不受限了，夸张点说就是无限扩展。你可以理解成，一个总集群中，可以虚拟出两个或两个以上的单独的小集群，各个小集群之间数据是实时共享的。因为hadoop集群中已经不在单独存在namenode和datanode的概念。当一个其中一个小集群出故障，可以启动另一个小集群中的namenode节点，继续工作。因为数据是实时共享，即使namenode或datanode一起死掉，也不会影响整个集群的正常工作。
Ubuntu14.04下Hadoop2.4.1单机/伪分布式安装配置教程
CentOS安装和配置Hadoop2.2.0
Ubuntu 12.10 +Hadoop 1.2.1版本集群配置
集群节点任务安排：
这点很重要，我们事先一定要先理解，节点之间任务是如何安排的。如果事先不理解为什么是这样，后面还会遇到更多的问题。这就需要，理解journalnode、zookeeper、datanode、namenode之间关系。自己也是在这上面耽误了很长时间，希望读者这点多注意下。
6台主机。
Journalnode和zookeeper保持奇数点，这点大家要有个概念，最少不少于3个节点。这里暂不讲解。