配置hadoop集群是怎么配置的

在过去，大数据处理主要是采用标准化的刀片式服务器和存储区域网络（SAN）来满足网格和处理密集型工作负载。然而随着数据量和用户数的大幅增长，基础设施的需求已经发生变化，硬件厂商必须建立创新体系，来满足大数据对包括存储刀片，SAS（串行连接SCSI）开关，外部SATA阵列和更大容量的机架单元的需求。即寻求一种新的方法来存储和处理复杂的数据，Hadoop正是基于这样的目的应运而生的。Hadoop的数据在集群上均衡分布，并通过复制副本来确保数据的可靠性和容错性。因为数据和对数据处理的操作都是分布在服务器上，处理指令就可以直接地发送到存储数据的机器。这样一个集群的每个服务器器上都需要存储和处理数据，因此必须对Hadoop集群的每个节点进行配置，以满足数据存储和处理要求。

Hadoop框架中最核心的设计是为海量数据提供存储的HDFS和对数据进行计算的MapReduce。MapReduce的作业主要包括从磁盘或从网络读取数据，即IO密集工作，或者是计算数据，即CPU密集工作。Hadoop集群的整体性能取决于CPU、内存、网络以及存储之间的性能平衡。因此运营团队在选择机器配置时要针对不同的工作节点选择合适硬件类型。一个基本的Hadoop集群中的节点主要有：Namenode负责协调集群中的数据存储，DataNode存储被拆分的数据块，Jobtracker协调数据计算任务，最后的节点类型是Secondarynamenode，帮助NameNode收集文件系统运行的状态信息。

在集群中，大部分的机器设备是作为Datanode和TaskTracker工作的。Datanode/TaskTracker的硬件规格可以采用以下方案：

4个磁盘驱动器（单盘1-2T），支持JBOD

2个4核CPU,至少2-25GHz

16-24GB内存

千兆以太网

Namenode提供整个HDFS文件系统的namespace管理，块管理等所有服务,因此需要更多的RAM，与集群中的数据块数量相对应，并且需要优化RAM的内存通道带宽，采用双通道或三通道以上内存。硬件规格可以采用以下方案：

8-12个磁盘驱动器（单盘1-2T）

2个4核/8核CPU

16-72GB内存

千兆/万兆以太网

Secondarynamenode在小型集群中可以和Namenode共用一台机器，较大的群集可以采用与Namenode相同的硬件。考虑到关键节点的容错性，建议客户购买加固的服务器来运行的Namenodes和Jobtrackers，配有冗余电源和企业级RAID磁盘。最好是有一个备用机，当 namenode或jobtracker 其中之一突然发生故障时可以替代使用。

目前市场上的硬件平台满足Datanode/TaskTracker节点配置需求的很多，，据了解深耕网络安全硬件平台多年的立华科技瞄准了Hadoop的发展前景，适时推出了专门针对NameNode的设备----双路至强处理器搭载12块硬盘的FX-3411，将计算与存储完美融合，四通道内存的最大容量可达到256GB，完全满足NameNode对于一个大的内存模型和沉重的参考数据缓存组合的需求。

同时在网络方面，FX-3411支持的2个PCI-E8的网络扩展，网络吞吐达到80Gbps，更是远远满足节点对千兆以太网或万兆以太网的需求。此外针对Datanode/TaskTracker等节点的配置需求，立华科技不仅推出了可支持单路至强E38核处理器和4块硬盘的标准品FX-3210，还有可以全面客制化的解决方案，以满足客户的不同需求。

Hadoop集群往往需要运行几十，几百或上千个节点，构建匹配其工作负载的硬件，可以为一个运营团队节省可观的成本，因此，需要精心的策划和慎重的选择。

Docker最核心的特性之一，就是能够将任何应用包括Hadoop打包到Docker镜像中。这篇教程介绍了利用Docker在单机上快速搭 建多节点 Hadoop集群的详细步骤。作者在发现目前的Hadoop on Docker项目所存在的问题之后，开发了接近最小化的Hadoop镜像，并且支持快速搭建任意节点数的Hadoop集群。

GitHub: kiwanlau/hadoop-cluster-docker

直接用机器搭建Hadoop集群是一个相当痛苦的过程，尤其对初学者来说。他们还没开始跑wordcount，可能就被这个问题折腾的体无完肤了。而且也不是每个人都有好几台机器对吧。你可以尝试用多个虚拟机搭建，前提是你有个性能杠杠的机器。

我的目标是将Hadoop集群运行在Docker容器中，使Hadoop开发者能够快速便捷地在本机搭建多节点的Hadoop集群。其实这个想法已经有 了不少实现，但是都不是很理想，他们或者镜像太大，或者使用太慢，或者使用了第三方工具使得使用起来过于复杂。下表为一些已知的Hadoop on Docker项目以及其存在的问题。

更快更方便地改变Hadoop集群节点数目

另外，alvinhenrick/hadoop-mutinode项目增加节点时需要手动修改Hadoop配置文件然后重新构建hadoop- nn-dn 镜像,然后修改容器启动脚本，才能实现增加节点的功能。而我通过shell脚本实现自动话，不到1分钟可以重新构建hadoop-master镜像，然后 立即运行!本项目默认启动3个节点的Hadoop集群，支持任意节点数的Hadoop集群。

另外，启动Hadoop，运行wordcount以及重新构建镜像都采用了shell脚本实现自动化。这样使得整个项目的使用以及开发都变得非常方便快捷。

开发测试环境

操作系统：ubuntu 1404 和 ubuntu 1204

内核版本: 3130-32-generic

Docker版本：150 和162

小伙伴们，硬盘不够，内存不够，尤其是内核版本过低会导致运行失败。

切换到Hadoop解压目录的etc/hadoop/目录下，编辑hadoop-envsh，修改如下内容：

该文件是Hadoop的核心配置文件，目的是配置HDFS地址、端口号以及临时文件目录。

该文件MapReduce的核心文件，用于指定MapReduce运行时框架。在etc/hadoop/目录没有该文件，需要将mapred-sitexmltemplate复制并重命名为mapred-sitexml。

该文件YARN的核心文件，需要指定YARN集群的管理者。

该文件记录Hadoop集群所有从节点(HDFSde DataNode和YARN的NodeManager所在主机)的主机名，用来配合一键启动脚本启动集群从节点(保证关联节点配置了SSH免密登录)。打开slaves文件，先删除里面的内容(默认localhost)，配置如下内容

完成Hadoop集群主节点hadoop01的配置后，还需要将系统环境配置文件、JDK安装目录和Hadoop安装目录分发到其他子节点hadoop02和hadoop03上，具体指令：

  scp /etc/profile hadoop02:/etc/profile

  scp /etc/profile hadoop03:/etc/profile

  scp -r /export/ hadoop02:/

  scp -r /export/ hadoop03:/

完成后，在hadoop02和hadoop03节点刷新配置文件：

  source /etc/profile

初次启动HDFS集群时，必须对主节点进行格式化处理。注意：格式化指令只需在Hadoop集群初次启动前执行即可。指令：

hdfs namenode –format

或

hadoop namenode -format

出现“successfully formatted"字样表示格式化成功。

针对Hadoop集群的启动，需要启动内部包含的HDFS集群和YARN集群两个集群框架。

启动：

（1）start-dfssh  #启动所有HDFS服务进程

（2）start-yarnsh  #启动所有YARN服务进程

或者：

start-allsh直接启动整个Hadoop集群服务

关闭则直接将上述指令中的start换成stop即可。

在整个Hadoop集群服务启动完成后，可以在各自机器上通过jps指令查看各节点的服务进程启动情况。

集群启动成功。

　　本文将逐步介绍这些部分的安装和配置：

•网络体系结构

•操作系统

•硬件要求

•Hadoop软件安装/设置

网络架构

根据我们目前能够拿到的文档，可以认为云内的节点越在物理上接近，越能获得更好的性能。根据经验，网络延时越小，性能越好。

为了减少背景流量，我们为这个云创建了一个虚拟专用网。另外，还为应用服务器们创建了一个子网，作为访问云的入口点。

这个虚拟专用网的预计时延大约是1-2毫秒。这样一来，物理临近性就不再是一个问题，我们应该通过环境测试来验证这一点。

建议的网络架构：

•专用TOR(Top of Rack)交换机

•使用专用核心交换刀片或交换机

•确保应用服务器“靠近”Hadoop

•考虑使用以太网绑定

　　操作系统

我们选择Linux作为操作系统。Linux有许多不同的发行版，包括Ubuntu、RedHat和CentOS等，无论选择哪一个都可以。基于支持和许可费用的考虑，我们最终选择了CentOS 57。最好是定制一个CentOS的映像，把那些需要的软件都预装进去，这样所有的机器可以包含相同的软件和工具，这是一个很好的做法。

根据Cloudera的建议，OS层应该采用以下设置：

•文件系统

Ext3文件系统

取消atime

不要使用逻辑卷管理

•利用alternatives来管理链接

•使用配置管理系统(Yum、Permission、sudoers等)

•减少内核交换

•撤销一般用户访问这些云计算机的权限

•不要使用虚拟化

•至少需要以下Linux命令：

/etc/alternatives

ln、chmod、chown、chgrp、mount、umount、kill、rm、yum、mkdir

硬件要求

由于Hadoop集群中只有两种节点(Namenode/Jobtracker和Datanode/Tasktracker)，因此集群内的硬件配置不要超过两种或三种。

　　硬件建议：

•Namenode/Jobtracker：1Gb/s以太网口x2、16GB内存、4个CPU、100GB磁盘

•Datanode：1Gb/s以太网口x2、8GB内存、4个CPU、多个磁盘，总容量500GB以上

实际的硬件配置可以与我们建议的配置不同，这取决于你们需要存储和处理的数据量。但我们强烈建议不要在集群中混用不同的硬件配置，以免那些较弱的机器成为系统的瓶颈。

Hadoop的机架感知

Hadoop有一个“机架感知”特性。管理员可以手工定义每个slave数据节点的机架号。为什么要做这么麻烦的事情有两个原因：防止数据丢失和提高网络性能。

　　为了防止数据丢失，Hadoop会将每个数据块复制到多个机器上。想象一下，如果某个数据块的所有拷贝都在同一个机架的不同机器上，而这个机架刚好发生故障了(交换机坏了，或者电源掉了)，这得有多悲剧为了防止出现这种情况，必须要有一个人来记住所有数据节点在网络中的位置，并且用这些知识来确定——把数据的所有拷贝们放在哪些节点上才是最明智的。这个“人”就是Name Node。

另外还有一个假设，即相比不同机架间的机器，同一个机架的机器之间有着更大的带宽和更小的延时。这是因为，机架交换机的上行带宽一般都小于下行带宽。而且(+本站微信networkworldweixin)，机架内的延时一般也小于跨机架的延时(但也不绝对)。

机架感知的缺点则是，我们需要手工为每个数据节点设置机架号，还要不断地更新这些信息，保证它们是正确的。要是机架交换机们能够自动向Namenode提供本机架的数据节点列表，那就太棒了。

客户要求要回收一批hadoop集群的一批服务器，万幸namenode和resourcemanager服务没有安装在这批服务器上，但不巧的是3个journalnode节点都在这批服务器上，所以暂时先增加3个journalnode节点，等到回收服务器的时候，再把原来的journalnode节点下线，记录一下操作

1修改hdfs-sitexml配置文件

原配置为：

修改为：

2分发hdfs-sitexml文件到各节点

3将原journalnode上的edits文件scp到新的journalnode节点

从hdfs-sitexml文件中的dfsjournalnodeeditsdir配置项得到edits文件存储路径，scp到新节点的相同路径，注意权限和属主要相同，可以用scp -rp来复制

4新journalnode节点启动journalnode进程

jps检查是否启动成功，如果失败就去看$HADOOP_HOME/logs下的journalnode相关的日志，讲道理应该没什么问题

5把standby(nn2)节点的namenode重启一下

6切换standby节点为active

7重启standby(nn1)节点的namenode

操作同5，完成后web界面应该可以看到NameNode Journal Status的journalnode已扩展完成

最好是两个做成HA

关于硬盘:

6T的数据容量,看你副本数量设置是多少,一般默认为3,那么仅这些就需要18T硬盘,稍微大一点20T吧;这仅仅是HDFS存储;(这里我说的是一个月的,你数据保存几个月,就乘几倍)

如果你集群上面要跑计算,MR计算出来的数据要保存HDFS的,所以,还是要根据你的结果数据来做判断,大小就看你计算任务了

一般是这样计算硬盘大小

(原始数据+中间数据+结果数据)副本数量=总硬盘大小

关于内存:

namenode不用说了,主要就是用内存保存block和node之间对应关系的,也是要根据数据大小计算的,6T/Block大小(默认为128M)=有多少block-->M个

一个block占多少内存: 保守地设置每一百万数据块需要1000MB内存

namenode总内存(兆M)=M1000MB/100万

datanode的内存: 一般问题不大,一般都是用于mr的计算,这个东西根据你性能的需要设置

关于多少台机器

根据Task任务的数量和你的性能指标来做决定

一个Block对应一个Mapper任务,上面算出来M个Block了,mapper任务也是那么多

实际测试一下,一定数据量在x台机器上运行时间,根据你的指标去评定要多少台机器

hadoop集群的性能和节点个数近似成正向关系